Re: [9fans] RESOLVED: recoving important header file rudely
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 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 able to handle that. But that's still far in the > future, at this point. I haven't even finished coding the basic string > operations for data in memory, yet. > > -- > +---+ > |E-Mail: smi...@zenzebra.mv.com PGP key ID: BC549F8B| > |Fingerprint: 9329 DB4A 30F5 6EDA D2BA 3489 DAB7 555A BC54 9F8B| > +---+ > >
Re: [9fans] RESOLVED: recoving important header file rudely
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 alternatives because it made understanding the transition from code on the page to code on the machine easier. There were experiments in other languages like Aleph(mentioned earlier) which were deprecated when the effort of maintaining them outweighed their benefits. Likewise Plan 9 doesn't have a real mode 16 bit assembler, all of the real mode code is written as packed macros for the regular assembler. It wasn't worth the effort. Many of the issues you bring up are similar. If the bugs you find keep you from getting productive work done on Plan 9, by all means submit a patch. If you desperately need a high level language to solve your problems, refer to the languages that other people on the list have mentioned and roll your own. If you'd like it to be adopted by the greater Plan 9 community, write in a way that an expert versed in the Plan 9 coding style could easily understand and modify it. Noah On Wed, Feb 2, 2011 at 8:15 PM, wrote: > "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 ever laid eyes on it? > (Rhetorical question, of course.) > >> bugs, iterators and the other crap you mentioned would had obfuscated >> it. > > The "other crap" I mentioned would have made that bug IMPOSSIBLE. > >> Plan 9 is not bug-free, but they easier to find and fix, think about >> that. > > I know you love Plan 9, and I have no desire to disrupt that > relationship. I'm quite infatuated with it, myself. But neither of our > loves' would be very realistic if we didn't admit that Plan 9 is just > full of bugs like this. > > -- > +---+ > |E-Mail: smi...@zenzebra.mv.com PGP key ID: BC549F8B| > |Fingerprint: 9329 DB4A 30F5 6EDA D2BA 3489 DAB7 555A BC54 9F8B| > +---+ > >
Re: [9fans] RESOLVED: recoving important header file rudely
>usually with oversized log files. sam -d, indeed!
Re: [9fans] RESOLVED: recoving important header file rudely
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...@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 to edit 500MB files in ed... >> >> >> >> nor does ed cope with arbitrary length lines. >> > >> > when has editing a 500mb text file ever been a problem? > > it's not a log file if you edit it. ☺ structural regexps are excellent for making sense of some log files...
Re: [9fans] RESOLVED: recoving important header file rudely
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 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 lines. > > > > when has editing a 500mb text file ever been a problem? it's not a log file if you edit it. ☺ - erik
Re: [9fans] RESOLVED: recoving important header file rudely
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. >> > 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 lines. > > when has editing a 500mb text file ever been a problem? > > - erik > >
Re: [9fans] RESOLVED: recoving important header file rudely
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 to edit 500MB files in ed... > > nor does ed cope with arbitrary length lines. when has editing a 500mb text file ever been a problem? - erik
Re: [9fans] RESOLVED: recoving important header file rudely
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 lines.
Re: [9fans] RESOLVED: recoving important header file rudely
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 exceeded. unfortunately string has an clunky interface. s_to_c, etc. and it begets clunky hacks that assume implementation. but i don't think you can do much better with the interface in c. Rune*s don't work very well and they've essentially doubled the functions in the c library. 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. - erik
Re: [9fans] RESOLVED: recoving important header file rudely
> 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.
Re: [9fans] RESOLVED: recoving important header file rudely
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 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 > operations for data in memory, yet. "The standard rule is, when you're in a hole, stop digging; that seems not to apply in software nowadays." -- dexen deVries [[[↓][→]]]
Re: [9fans] RESOLVED: recoving important header file rudely
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 > operations for data in memory, yet. > And you propose finishing this by when? And re-inventing mmap by when? ++L
Re: [9fans] RESOLVED: recoving important header file rudely
> The finished version will support strings backed by file storage and I'm patiently waiting for strings backed by cloud storage.
Re: [9fans] RESOLVED: recoving important header file rudely
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 able to handle that. But that's still far in the future, at this point. I haven't even finished coding the basic string operations for data in memory, yet. -- +---+ |E-Mail: smi...@zenzebra.mv.com PGP key ID: BC549F8B| |Fingerprint: 9329 DB4A 30F5 6EDA D2BA 3489 DAB7 555A BC54 9F8B| +---+
Re: [9fans] RESOLVED: recoving important header file rudely
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 a file with a file name that is 257MB long. What does your stuff do then? ron
Re: [9fans] RESOLVED: recoving important header file rudely
"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 ever laid eyes on it? (Rhetorical question, of course.) > bugs, iterators and the other crap you mentioned would had obfuscated > it. The "other crap" I mentioned would have made that bug IMPOSSIBLE. > Plan 9 is not bug-free, but they easier to find and fix, think about > that. I know you love Plan 9, and I have no desire to disrupt that relationship. I'm quite infatuated with it, myself. But neither of our loves' would be very realistic if we didn't admit that Plan 9 is just full of bugs like this. -- +---+ |E-Mail: smi...@zenzebra.mv.com PGP key ID: BC549F8B| |Fingerprint: 9329 DB4A 30F5 6EDA D2BA 3489 DAB7 555A BC54 9F8B| +---+
Re: [9fans] RESOLVED: recoving important header file rudely
> 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;
>
> if(todir){
> char *s, *elem;
> elem=s=from;
> while(*s++)
> if(s[-1]=='/')
> elem=s;
> sprint(name, "%s/%s", to, elem);
> to=name;
> }
>
>
> The bug in rc's globbing was just a fun "bonus" I discovered while
> trying to clean up after the cp test. :)
>
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
bugs, iterators and the other crap you mentioned would had obfuscated it.
now you found a related bug in rc, if I ever get to write code as beautiful
as rc that will be a day to remember.
Plan 9 is not bug-free, but they easier to find and fix, think about that.
--
Federico G. Benavento
Re: [9fans] RESOLVED: recoving important header file rudely
> > 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 to assume. odd but true fact: not everyone agrees that oo trappings are uniformly a good idea. anyway, oo was know about, just not used. > Yes, but C macros can be used to approximate higher-level language > constructs such as objects, iterators (Java style or Ruby style, though > I'm focusing only on the latter), throw/catch clauses, and so on. s.r.bourne would agree! (c'mon smile.) i'm not convinced that throw/catch is a good idea to emulate. it's very hard to get right. goto is a like a pet bunny; throw is like a pet bunny on the loose. with t-t-teeth. i think you'll have more success with plan 9 if you don't try to pound it into a ruby-sized hole. - erik
Re: [9fans] RESOLVED: recoving important header file rudely
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 find all the things you mentioned unsatisfying in both an esthetic and practical sense, especially when implemented in the manner of C++, particularly the STL. Hence, I am not surprised that nobody in this community has rushed to add them. It's not like people here don't know about them. Rather, it is that those who might have brought those ideas in have likely considered and rejected them. > >> That said, why are you thinking in terms of writing in C anyway? > > Because Plan 9 only has a C compiler? I think you should set your sights higher than the macro approach you propose. At least in my opinion it's a really ugly idea. You could make a lasting contribution by bringing a good modern language to Plan 9. I'll say it again, I don't think a cpp-based approach will be well received in this community, and for good reason. A Go port? Well, that's another story. Or even native Limbo, that one is frequently requested. good luck. ron
Re: [9fans] RESOLVED: recoving important header file rudely
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, come on already, quit teasing me! :) What's the secret reason? > That said, why are you thinking in terms of writing in C anyway? Because Plan 9 only has a C compiler? > I don't see how macro foo is going to make things all that much > better. You're still stuck with C. Yes, but C macros can be used to approximate higher-level language constructs such as objects, iterators (Java style or Ruby style, though I'm focusing only on the latter), throw/catch clauses, and so on. > Actually, Plan 9 kernel is palpably object-oriented in a very real > sense, if you consider the whole. The plan 9 devices and servers are I'll first repeat a previous comment of mine for purposes of disclaimer: I haven't even LOOKED at ANY of the Plan 9 kernel code, yet... Architecturally, the Plan 9 operating system appears to be leading-edge, modern, elegant, and generally kick-ass. How that architecture is IMPLEMENTED, however, is an entirely different story. The wonderfully modern architecture of the OS looks like it's been implemented using wonderfully ancient methods. BTW, I should mention how I impressed I am by the quality of the discussion on this list. There are obviously a lot of smart people on this OS. :) -- +---+ |E-Mail: smi...@zenzebra.mv.com PGP key ID: BC549F8B| |Fingerprint: 9329 DB4A 30F5 6EDA D2BA 3489 DAB7 555A BC54 9F8B| +---+
Re: [9fans] RESOLVED: recoving important header file rudely
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-forward coding, both need to be cleaned up and could be made clearer by utilizing more of the Go standard library) It's in many ways the perfect language for this sort of thing. It's almost like its creators had some sort of expertise in this area :)
Re: [9fans] RESOLVED: recoving important header file rudely
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 think. That said, why are you thinking in terms of writing in C anyway? If you're going to put a lot of work out, why not use a modern language in which strings are actually a first class object, that has garbage collection, and so on? I don't see how macro foo is going to make things all that much better. You're still stuck with C. > > It's probably worth noting that higher-level code abstractions are > probably more useful in userspace code than in the kernel. This is > partly for reasons of performance, and partly because the kernel is so > much closer to the hardware. The Linux kernel, for example, is still > largely written in old UNIX-style C. It wasn't even until series 2.5 or > so that the Linux kernel became palpably object-oriented. Actually, Plan 9 kernel is palpably object-oriented in a very real sense, if you consider the whole. The plan 9 devices and servers are all accessed via a common interface, and kernel and user objects can be interchanged -- consider that one can put a custom IP stack in place just by mounting on /net. I've worked with "object oriented" operating systems written in C++ that were far less object oriented than Plan 9. Over the years I've come to believe that whether a system is object-oriented does not always depend on the language it is written in. In fact given some of the C++ code I've had to work with I almost wonder if it's not an inverse relationship ... thanks ron p.s. If you're going to rewrite /bin, maybe it's time to look at Go?
Re: [9fans] RESOLVED: recoving important header file rudely
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
> better. If you look a bit more at it I think you'll see what's going
> on.
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;
if(todir){
char *s, *elem;
elem=s=from;
while(*s++)
if(s[-1]=='/')
elem=s;
sprint(name, "%s/%s", to, elem);
to=name;
}
The bug in rc's globbing was just a fun "bonus" I discovered while
trying to clean up after the cp test. :)
> but I have to wonder if you've been inside glibc lately. I don't think
Agreed. glibc has become quite ugly.
> There are other, very good paradigms that the code does use, such as
> lock-free threads.
Threads are one great paradigm that Plan 9 adopted. Native UTF-8 is
another. 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. All of these
programming techniques can free the programmer from having to think
about byte-level boundary conditions and focus on the higher-level
operation of the code. Having to tend to such details over and over
again leads to lots of missed boundary conditions (like in cp.c and
plan9.c), application instability, and security vulnerabilities
(remember the factotum exploit?)
It's probably worth noting that higher-level code abstractions are
probably more useful in userspace code than in the kernel. This is
partly for reasons of performance, and partly because the kernel is so
much closer to the hardware. The Linux kernel, for example, is still
largely written in old UNIX-style C. It wasn't even until series 2.5 or
so that the Linux kernel became palpably object-oriented.
> The common problem is that people come to Plan 9 and view it through
> the prism of their experiences with other systems such as Linux.
Yes, I am familiar with the notion that the Plan 9 way is very different
from other ways, such as the Linux way. One of the things that I enjoy
about Plan 9 is that it makes me feel naive again. :)
--
+---+
|E-Mail: smi...@zenzebra.mv.com PGP key ID: BC549F8B|
|Fingerprint: 9329 DB4A 30F5 6EDA D2BA 3489 DAB7 555A BC54 9F8B|
+---+
Re: [9fans] RESOLVED: recoving important header file rudely
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, I came to understand
> why the system was so buggy. The core applications appear to be written
> in a style of C programming reminiscent of the dawn of UNIX. While the
> operating system architecture is BEAUTIFULLY designed (with the
> exception, perhaps of that fossil/conf gotcha!), the C code used to
> implement it doesn't seem to take advantage of any of the programming
> paradigms that have emerged in the intervening 30 years...
>
What hasn't plan 9 adopted that would make it a better system? OOP? Plan 9
adopted (afaik) things like concurrency before other mainstream systems.
Plan 9's namespaces are still unique to the system, and the way most things
are represented as a fileserver is something very unique to plan 9/inferno.
What programming paradigms do you think plan 9 shoul
take advantage of?
> Getting Plan 9 code to crash is almost too easy:
>
> 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 abc*
> # watch the rio window go bye bye!
>
Yes, plan 9's file name length can be a bit 'short' in some cases. The
example you gave is a bit extreme, as fgb showed. When and why would you
need a filename/path that long?
Re: [9fans] RESOLVED: recoving important header file rudely
>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'll certainly also need ... something must be done! (and that's certainly a lot of something.)
Re: [9fans] RESOLVED: recoving important header file rudely
> 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 abc*
> # watch the rio window go bye bye!
it used to be that path elements on the file server were limited
to 26 non-space characters. if you're running ken, that limit
is typically 56 characters. but fileservers (e.g. ramfs) are free
to choose any limit they wish.
i think fgb's fix is a good band-aid. but we need to
be flexible and handle arbitrary sized file names.
i'm applying this. i goto Again because i don't want
to break the rest of the glob.
; diffy -c plan9.c
/n/dump/2011/0201/sys/src/cmd/rc/plan9.c:443,448 - plan9.c:443,449
int
Readdir(int f, void *p, int onlydirs)
{
+ char *s;
int n;
if(f<0 || f>=NFD)
/n/dump/2011/0201/sys/src/cmd/rc/plan9.c:465,472 - plan9.c:466,478
}
if(dir[f].i == dir[f].n)
return 0;
- strcpy(p, dir[f].dbuf[dir[f].i].name);
+ s = dir[f].dbuf[dir[f].i].name;
dir[f].i++;
+ if(strlen(s) >= NDIR){
+ pfmt(err, "rc: file name too long: %s\n", s);
+ goto Again;
+ }
+ strcpy(p, s);
return 1;
}
- erik
Re: [9fans] RESOLVED: recoving important header file rudely
> 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 supporting utf16, then i'm going to disagree. tcs handles utf16 just fine so the rest of the system can use utf-8, as god intended. - erik
Re: [9fans] RESOLVED: recoving important header file rudely
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;
< }
< strcpy(p, s);
---
> strcpy(p, dir[f].dbuf[dir[f].i].name);
lotte% mkdir trashdir && cd trashdir && mkdir x
lotte% touch `{i=0; while (test $i -lt 128) { echo -n
abcdefghijklmnop; i=`{echo $i+1|hoc} } }
lotte% cp abc* abc* x
file name too long:
abcdefghijklmnopabcdefghijklmnopabcdefghijklmnopabcdefghijklmnopabcdefghijklmnopabcdefghijklmnopabcdefghijklmnopabcdefghijklmnopabcdefghijklmnopabcdefghijklmnopabcdefghijklmnopabcdefghijklmnopabcdefghijklmnopabcdefghijklmnopabcdefghijklmnopabcdefghijklmnopabcdefghijklmnopabcdefghijklmnopabcdefghijklmnopabcdefghijklmnopabcdefghijklmnopabcdefghijklmnopabcdefghijklmnopabcdefghijklmnopabcdefghijklmnopabcdefghijklmnopabcdefghijklmnopabcdefghijklmnopabcdefghijklmnopabcdefghijklmnopabcdefghijklmnopabcdefghijklmnopabcdefghijklmnopabcdefghijklmnopabcdefghijklmnopabcdefghijklmnopabcdefghijklmnopabcdefghijklmnopabcdefghijklmnopabcdefghijklmnopabcdefghijklmnopabcdefghijklmnopabcdefghijklmnopabcdefghijklmnopabcdefghijklmnopabcdefghijklmnopabcdefghijklmnopabcdefghijklmnopabcdefghijklmnopabcdefghijklmnopabcdefghijklmnopabcdefghijklmnopabcdefghijklmnopabcdefghijklmnopabcdefghijklmnopabcdefghijklmnopabcdefghijklmnopabcdefghijklmnopabcdefghijklmnopabcdefghijklmnopabcdefghijklmnopabcdefghijklmnopabcdefghijklmnopabcdefghijklmnopabcdefghijklmnopabcdefghijklmnopabcdefghijklmnopabcdefghijklmnopabcdefghijklmnopabcdefghijklmnopabcdefghijklmnopabcdefghijklmnopabcdefghijklmnopabcdefghijklmnopabcdefghijklmnopabcdefghijklmnopabcdefghijklmnopabcdefghijklmnopabcdefghijklmnopabcdefghijklmnopabcdefghijklmnopabcdefghijklmnopabcdefghijklmnopabcdefghijklmnopabcdefghijklmnopabcdefghijklmnopabcdefghijklmnopabcdefghijklmnopabcdefghijklmnopabcdefghijklmnopabcdefghijklmnopabcdefghijklmnopabcdefghijklmnopabcdefghijklmnopabcdefghijklmnopabcdefghijklmnopabcdefghijklmnopabcdefghijklmnopabcdefghijklmnopabcdefghijklmnopabcdefghijklmnopabcdefghijklmnopabcdefghijklmnopabcdefghijklmnopabcdefghijklmnopabcdefghijklmnopabcdefghijklmnopabcdefghijklmnopabcdefghijklmnopabcdefghijklmnopabcdefghijklmnopabcdefghijklmnopabcdefghijklmnopabcdefghijklmnopabcdefghijklmnopabcdefghijklmnopabcdefghijklmnopabcdefghijklmnopabcdefghijklmnopabcdefghijklmnopabcdefghijklmnopabcdefghijklmnopabcdefghijklmnopabcdefghijklmnopabcdefghijklmnopabcdefghijklmnopabcdefghijklmnopabcdefghijklmnop
file name too long:
abcdefghijklmnopabcdefghijklmnopabcdefghijklmnopabcdefghijklmnopabcdefghijklmnopabcdefghijklmnopabcdefghijklmnopabcdefghijklmnopabcdefghijklmnopabcdefghijklmnopabcdefghijklmnopabcdefghijklmnopabcdefghijklmnopabcdefghijklmnopabcdefghijklmnopabcdefghijklmnopabcdefghijklmnopabcdefghijklmnopabcdefghijklmnopabcdefghijklmnopabcdefghijklmnopabcdefghijklmnopabcdefghijklmnopabcdefghijklmnopabcdefghijklmnopabcdefghijklmnopabcdefghijklmnopabcdefghijklmnopabcdefghijklmnopabcdefghijklmnopabcdefghijklmnopabcdefghijklmnopabcdefghijklmnopabcdefghijklmnopabcdefghijklmnopabcdefghijklmnopabcdefghijklmnopabcdefghijklmnopabcdefghijklmnopabcdefghijklmnopabcdefghijklmnopabcdefghijklmnopabcdefghijklmnopabcdefghijklmnopabcdefghijklmnopabcdefghijklmnopabcdefghijklmnopabcdefghijklmnopabcdefghijklmnopabcdefghijklmnopabcdefghijklmnopabcdefghijklmnopabcdefghijklmnopabcdefghijklmnopabcdefghijklmnopabcdefghijklmnopabcdefghijklmnopabcdefghijklmnopabcdefghijklmnopabcdefghijklmnopabcdefghijklmnopabcdefghijklmnopabcdefghijklmnopabcdefghijklmnopabcdefghijklmnopabcdefghijklmnopabcdefghijklmnopabcdefghijklmnopabcdefghijklmnopabcdefghijklmnopabcdefghijklmnopabcdefghijklmnopabcdefghijklmnopabcdefghijklmnopabcdefghijklmnopabcdefghijklmnopabcdefghijklmnopabcdefghijklmnopabcdefghijklmnopabcdefghijklmnopabcdefghijklmnopabcdefghijklmnopabcdefghijklmnopabcdefghijklmnopabcdefghijklmnopabcdefghijklmnopabcdefghijklmnopabcdefghijklmnopabcdefghijklmnopabcdefghijklmnopabcdefghijklmnopabcdefghijklmnopabcdefghijklmnopabcdefghijklmnopabcdefghijklmnopabcdefghijklmnopabcdefghijklmnopabcdefghijklmnopabcdefghijklmnopabcdefghijklmnopabcdefghijklmnopabcdefghijklmnopabcdefghijklmnopabcdefghijklmnopabcdefghijklmnopabcdefghijklmnopabcdefghijklmnopabcdefghijklmnopabcdefghijklmnopabcdefghijklmnopabcdefghijklmnopabcdefghijklmnopabcdefghijklmnopabcdefghijklmnopabcdefghijklmnopabcdefghijklmnopabcdefghijklmnopabcdefghijklmnopabcdefghijklmnopabcdefghijklmnopabcdefghijklmnopabcdefghijklmnopabcdefghijklmnopabcdefghijklmnopabcdefghijklmnopabcdefghijklmnopabcdefghijklmnopabcdefghijklmnop
cp: can't stat abc*: 'abc*' file does not exist
cp: can't stat abc*: 'abc*' file does not exist
lotte% rm abc*
file name too long:
abcdefghijklmnopabcdefghijklmnopabcdefghijklmnopabcdefghijklmnopabcdefghijklmnopabcdefghijklmnopabcdefghijklmnopabcdefghijklmnopabcdefghijklmnopabcdefghijklmnopabcdefghijklmnopabcdefghijklm
Re: [9fans] RESOLVED: recoving important header file rudely
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 the first time it hung. Since then, I've browsed
> some of the OS source code and, having done that, I came to understand
> why the system was so buggy. The core applications appear to be written
> in a style of C programming reminiscent of the dawn of UNIX. While the
> operating system architecture is BEAUTIFULLY designed (with the
> exception, perhaps of that fossil/conf gotcha!), the C code used to
> implement it doesn't seem to take advantage of any of the programming
> paradigms that have emerged in the intervening 30 years...
It would help the conversation if you described what these
new paradigms are. For instance, Plan 9 does not have any
code that's built upon any sort of functional programming
language. But again, that's not necessary. What practices
has everyone here missed, which would turn Plan 9 code
into gold? The argument seems a bit pretentious.
> Getting Plan 9 code to crash is almost too easy:
>
> 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 abc*
> # watch the rio window go bye bye!
Sorry, this does not crash any Plan 9 code on my system.
How much data globbing should handle is a matter of practicality.
When rc dies, the rio window closes.
ak
Re: [9fans] RESOLVED: recoving important header file rudely
> 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 abc*
> # watch the rio window go bye bye!
>
> 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, etc. I already have some working code, but it's still very
> experimental.
>
I don't see how C macros would improve rc's globbing code, which
thinks that there won't be files with names that long.
--
Federico G. Benavento
Re: [9fans] RESOLVED: recoving important header file rudely
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 offend. I actually haven't even looked at the kernel > code, yet. I was referring to the bits under /sys/src/cmd/. > No offense taken, sacred cows are usually very thin because they are sacred :-) > > _my_ suggestion to you is that you port the code to GCC and do what > > you like with it there. > > You mean port the userspace to GCC? Or the kernel? Wouldn't that kind > of defeat the intent behind Plan 9's redesigned toolchain? Is gcc even > supported enough on Plan 9 for serious work? The docs I've read seem to > suggest that gcc is kind of "glued onto the side of" Plan 9 proper. > The kernel code, so you can have your paradigms where I assumed you would miss them the most. No one cares about user space applications: they work, why change them? That way lies a proliferation of incompatible versions. And plan9port provides most of the Plan 9 userspace under a plethora of platforms, so that job is already done. As for GCC, it's like Linux, you know where to get it. It doesn't fit very well within Plan 9 (I have a sort-of-working version I keep as a monument), so my idea was to encourage you to turn the Plan 9 platform into something that ought to match your religious beliefs more closely. There is merit to having Plan 9 supported as a GCC application, but no one here has the necessary faith in GCC to invest in doing it. > > Chances are that the the changes you want to introduce are going to be > > incompatible in some or other manner; > > 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. As long as you don't try to treat them as text strings, I don't see why you should encounter any problems. And I fail to see how you would do any better on any other platform, without resorting to a completely new string type. And in that vein, do you want to compare Plan 9's support for UTF-8 to other platforms' support for internationalisation? ++L
Re: [9fans] RESOLVED: recoving important header file rudely
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 bits under /sys/src/cmd/. > _my_ suggestion to you is that you port the code to GCC and do what > you like with it there. You mean port the userspace to GCC? Or the kernel? Wouldn't that kind of defeat the intent behind Plan 9's redesigned toolchain? Is gcc even supported enough on Plan 9 for serious work? The docs I've read seem to suggest that gcc is kind of "glued onto the side of" Plan 9 proper. > Chances are that the the changes you want to introduce are going to be > incompatible in some or other manner; 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.
Re: [9fans] RESOLVED: recoving important header file rudely
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 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
better. If you look a bit more at it I think you'll see what's going
on.
I'm not totally in agreement with your other comments but to each his
own. Yes, there are some good things that have come along in 30 years,
but I have to wonder if you've been inside glibc lately. I don't think
that the span of time has much if anything to do with code quality.
And many of the "great ideas" of the last 30 years are not, in the
end, so terribly great.
There are other, very good paradigms that the code does use, such as
lock-free threads. The common problem is that people come to Plan 9
and view it through the prism of their experiences with other systems
such as Linux. To paraphrase the old Macintosh programming guides,
"everything you know is wrong". It's really worth taking the time
seeing how these ideas work before wading in with a machete and
changing it all. There's a reason that things are the way they are.
That doesn't mean, btw, always better; but it pays to figure out
what's what first.
> 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, etc. I already have some working code, but it's still very
> experimental.
would be interesting to see it. I propose that you offer up your ideas
of C macros etc. before too much longer.
ron
Re: [9fans] RESOLVED: recoving important header file rudely
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, etc. I already have some working code, but it's still very > experimental. > Beware of macros, they provide a level of indirection that makes the code really hard to read. I personally have grown to dislike them with a passion when I found the ISDN device driver for Linux considerably easier to follow than the FreeBSD one. 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 (some of us may well agree with you, but I'm not amongst those) so _my_ suggestion to you is that you port the code to GCC and do what you like with it there. Chances are that the the changes you want to introduce are going to be incompatible in some or other manner; at least by porting stuff to the most common development base you are targetting an audience that may be interested. ++L
Re: [9fans] RESOLVED: recoving important header file rudely
"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 two lines: fsys main config, fsys main open.
Incidentally, that fossil/conf drove me nuts(!) until I finally
discovered it. I tried switching the drive from /dev/sdC1 to /dev/sdC0.
I couldn't figure out why it kept insisting on mounting /dev/sdC1 when I
changed EVERYTHING in plan9.ini to refer to /dev/sdC0. (Some day, I'll
get around to asking why someone thought that hiding the device name on
the device itself was a good idea. ??)
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, I came to understand
why the system was so buggy. The core applications appear to be written
in a style of C programming reminiscent of the dawn of UNIX. While the
operating system architecture is BEAUTIFULLY designed (with the
exception, perhaps of that fossil/conf gotcha!), the C code used to
implement it doesn't seem to take advantage of any of the programming
paradigms that have emerged in the intervening 30 years...
Getting Plan 9 code to crash is almost too easy:
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 abc*
# watch the rio window go bye bye!
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, etc. I already have some working code, but it's still very
experimental.
--
+---+
|E-Mail: smi...@zenzebra.mv.com PGP key ID: BC549F8B|
|Fingerprint: 9329 DB4A 30F5 6EDA D2BA 3489 DAB7 555A BC54 9F8B|
+---+
Re: [9fans] RESOLVED: recoving important header file rudely
> 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 hang uninterruptably. MMDV (My Mileage Does Vary). 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? try fossil/conf /dev/sd??/fossil | grep snaptime This is an example of ephemerial snapshots enabled: fsys main snaptime -s 15 -a 0400 -t 3600 and disabled: fsys main snaptime -s none -a 0400 -t none -Steve
Re: [9fans] RESOLVED: recoving important header file rudely
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'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 hang uninterruptably. MMDV (My Mileage Does Vary).
Re: [9fans] RESOLVED: recoving important header file rudely
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 times a month. isn't deadlock or a race condition just computer science jargon for ymmv? - erik
Re: [9fans] RESOLVED: recoving important header file rudely
> 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.
Re: [9fans] RESOLVED: recoving important header file rudely clobbered by mk
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
