i sometimes use the following property
term% md5sum /proc/226/text
de057049f60a4b11c7931f83bef55d74/proc/226/text
term% md5sum /bin/cat
de057049f60a4b11c7931f83bef55d74/bin/cat
where `text' is a reference to the whole image
including symbols, not just the text segment
Note also that keeping a customized version of the kernel source locally is
completely unacceptable.
Where's the fun in using an open source OS if you don't customise your own
version?
Hello
this should be in tip of the day :-)
thanks Charles :-)
gabi
On 3/30/06, Charles Forsyth [EMAIL PROTECTED] wrote:
i sometimes use the following property
term% md5sum /proc/226/text
de057049f60a4b11c7931f83bef55d74/proc/226/text
term% md5sum /bin/cat
sorry for the stupid question. i didn't mean to step in that.
- erik
On Wed Mar 29 22:28:01 CST 2006, [EMAIL PROTECTED] wrote:
On Wed Mar 29 20:52:09 EST 2006, [EMAIL PROTECTED] wrote:
do you have some pointers to papers from these guys?
from my uneducated position, it seems to me that
Glenda got downgraded but will still cause mirth and derision.
It's the other side of the island from me.
For my disdain Tux will hit Bondi.
brucee
On 3/30/06, Russ Cox [EMAIL PROTECTED] wrote:
I bet there has never been a storm named Tux.
: Note also that keeping a customized version of the kernel source locally is
: completely unacceptable.
:
Ok . I'll rm -r /sys/src/planb here in that case :-)
I'm sorry.
if we're interested in coming to consensus, i'll pipe up and say i
really like the idea of mtime being proc start time. i've wanted this
many times and only didn't add it because i (foolishly) assumed it'd
be more involved than the apparently-trivial diff. being able to 'ls
-lt /proc' is genuinely
if we're interested in coming to consensus, i'll pipe up and say i
really like the idea of mtime being proc start time. i've wanted this
many times and only didn't add it because i (foolishly) assumed it'd
be more involved than the apparently-trivial diff. being able to 'ls
-lt /proc' is
On 3/30/06, Russ Cox [EMAIL PROTECTED] wrote:
it duplicates information already in the status file,
and it would be the *only* kernel device file in the system
The metadata of each device is not giving any
information if they all have the same mtime.
that didn't use kerndate as the mtime.
On 3/29/06, Ronald G Minnich rminnich@lanl.gov wrote:
[EMAIL PROTECTED] wrote:
mach was developed at cmu and freely available, wasn't it? the documentation
was (tree killers).
best Mach phrase: micro kernel doesn't mean it is small, just that it
does not do much.
from a flame war that
On 3/29/06, [EMAIL PROTECTED] [EMAIL PROTECTED] wrote:
do you have some pointers to papers from these guys?
from my uneducated position, it seems to me that plan9 has a large
percentage of what microkernels claim. one thing one can't
do is write a hardware driver that lives in userspace.
Got a screenshot?
On 3/29/06, erik quanstrom [EMAIL PROTECTED] wrote:
this is what's needed, if you're interested.
; diff -c /n/sources/plan9/sys/src/cmd/rio .
diff -c /n/sources/plan9/sys/src/cmd/rio/wind.c ./wind.c
/n/sources/plan9/sys/src/cmd/rio/wind.c:709,716 - ./wind.c:709,718
I am not sure about this. Static devices having all the
same mtime (kerndate) makes sense to me. Dynamic
devices in which files and directories appear and disappear
as draw or proc not having the mtime set as normal
dir/files doesnt.
In all fairness at least the semantics for files inside
: In the end everything is matter of convenience and taste, but this
: criticism comming from the person that instigated the tar -z
: abomination is harder to take seriously.
I use tar z a lot.
Why don't you write some code and relax?
Sorry to be so rude.
it duplicates information already in the status file,
and it would be the *only* kernel device file in the system
that didn't use kerndate as the mtime. when did the
plan 9 approach become there's more than one way to do it?
hmm I wonder when the kernel was written to the file system
ls -l
It's not useless, and it's the same as essentially every other
device file in the system.
Then perhaps they convey the wrong information.
Note the essentially every other. Not every other.
That means you can't take a devices mtime to be kerndate, which means
making *some* of them
i was about to say that i'd find it useful if the atime of /proc/n
reflected the last run time of a process, to make it easier to find
cpu hogs, but russ's point about ls -lt /proc's uselessness is bang
on.
so, by way of a little script to help with the above problem, which
bugs me every so
i sometimes use the following property
term% md5sum /proc/226/text
de057049f60a4b11c7931f83bef55d74 /proc/226/text
term% md5sum /bin/cat
de057049f60a4b11c7931f83bef55d74 /bin/cat
where `text' is a reference to the whole image
including symbols, not just the text segment
Is
There is also /n/sources/contrib/uriel/scripts/atop, a graphical top
in C by 20h and a version by f2f in perl, the existence of the perl
version pissed me off so much that I had to rewrite it in awk and IIRC
halve the line count in the process. We all love to duplicate work.
Anyway, it is
src(1) is extremely useful.
with names such as
kAudioHardwarePropertyBootChimeVolumeRangeDecibels,
Do you prefer kAHPBCVRD?
i'd prefer:
fprint(ctlfd, volume %d, vol);
clearly you'll be depressed if you ever come to look at OpenUSBDI.
admittedly, their names aren't quite as elaborate, but it's a big interface
to do nothing very much, partly because every action requires several types
and three or four different callback functions, excluding the proxy functions
Good evening.
Am Thu, 30 Mar 2006 18:41:28 +0100 schrieb [EMAIL PROTECTED]:
with names such as
kAudioHardwarePropertyBootChimeVolumeRangeDecibels,
Do you prefer kAHPBCVRD?
i'd prefer:
fprint(ctlfd, volume %d, vol);
ioctl(fd, SETVOLUME, vol); is more comfortable.
ioctl(fd, SETVOLUME, vol); is more comfortable.
ah, but how about
echo volume 50 /dev/audioctl
for understandability?
Sape
ioctl(fd, SETVOLUME, vol); is more comfortable.
no typechecking. no distribution. who defines all those constants?
i could have said:
echo volume 56 /dev/bootchime/ctl
how comfortable is your ioctl then?
ioctl(fd, SETVOLUME, vol); is more comfortable.
of course. then we can fuss trying to have the same value for SETVOLUME on
each system
in a distributed set and re-learn all that The Newcastle Connection and RFS
painfully discovered
about that (but Linux has yet to learn); the interface
Oh really? What if fd is a channel to a device on
a machine with a different byte order or a different
int size? Who does the conversion, how do they know?
It might be comfortable, but so is lounging in a big
enough pile of shite. Smelly, though.
On Thu Mar 30 12:52:02 EST 2006, [EMAIL
I just accidentally logged into my Q term plan 9 as
'leimy
I was logged in as
'leimy
and my rc shells had a cwd of /usr/leimy
I effectively got a read only access login to my home directory.
Seems like a bug, but might be serendipitous.
And if you want to do streams(DMR) you have to decide how large
the thing you're going to send down the wire can be. My versions
of streams only let you send 64 bytes objects. The advancement in evolution
is:
sgetty/getty - ioctl - /dev/eiactl.
Oh really? What if fd is a
i don't see how mach is an improvement over linux. especially
early linux. mach kernels were three times the size of linux
kernels of the day and didn't do anything useful by themselves.
What the ATT lawsuit blocked distribution of was Mach 2.5, which
was BSD Unix with parts of the kernel
you can't just call a function and have it return the value you wanted, you
know. no, no no.
you need to ask someone who promises to progress the action on your request
and get back to you.
the async call/callback stuff is very annoying. many multithreaded
systems in c++ have to resort to
i said:
no typechecking.
and this is the part that really bugs me. endless use of void*; if
you get it wrong, who knows what'll happen. the compiler certainly
can't help.
under the interfaces i was looking at in macos x, most things
are accessed through a trio of calls along the lines of:
ioctl(fd, SETVOLUME, vol); is more comfortable.
ah, but how about
echo volume 50 /dev/audioctl
for understandability?
i would also add:
import -b noisemaker /dev
echo volume 50 /dev/audioctl
please ioctl this!
that was happening inside the remote control which
runs inferno. didn't you see that?
to contribute to this ugly thread, i would say the more comfortable
way is using the hi-fi remote from your favourite armchair.
:-)
gabi
On 3/30/06, Skip Tavakkolian [EMAIL PROTECTED] wrote:
to contribute to this ugly thread, i would say the more comfortable
way is using the hi-fi remote from your favourite armchair.
yes, but what does that do underneath in the digital world?
sadly, it probably resembles the uglier parts of this thread, and is
an order of magnitude (or two) more
Also, ioctl masks the direction of data motion, while read and
write make it was explicit as can be.
-rob
On 3/30/06, Rob Pike [EMAIL PROTECTED] wrote:
Also, ioctl masks the direction of data motion, while read and
write make it was explicit as can be.
-rob
It really does seem that ioctl is just a kitchen sink for operations
on resources in a filesystem that people didn't think could be
ioctl(fd, SETVOLUME, vol); is more comfortable.
I may be wrong, but I think
some sarscasm was indented.
-Steve
On Thu, Mar 30, 2006 at 07:27:32PM +0100, [EMAIL PROTECTED] wrote:
i said:
no typechecking.
and this is the part that really bugs me. endless use of void*; if
you get it wrong, who knows what'll happen. the compiler certainly
can't help.
Has anybody ever thought about extending the
Of course, since it uses utf8 strings as arguments, some people
will want to internationalize them (how dare you force us to use an
english word? We in foobarland don't say volume).
La evidenta respondo estas Esperanto.
Michael Baldwin wrote:
Of course, since it uses utf8 strings as arguments, some people will
want to internationalize them (how dare you force us to use an
english word? We in foobarland don't say volume).
La evidenta respondo estas Esperanto.
Nekredeble! ;) Tiuj ĉi esperantistoj ĉieas!
Andrew Simmons wrote:
La evidenta respondo estas Esperanto.
Please call the hall porter, there appears to be a frog in my bidet???
Haha :) Yes, this is a famous sentence. I cannot image where it did come
from. Ĉu eble iu scias ĉi tie?
smime.p7s
Description: S/MIME Cryptographic
import -b noisemaker /dev
echo volume 50 /dev/audioctl
please ioctl this!
Easy!
kldload noisemaker.ko
noisemakercontrol volume 50
where's the import?
Someone needs to point out to non-plan9 people that the plan9
way is really dynamic linking + object oriented programming
on steroids. But with a different calling convention and
different limitations. Of course, since it uses utf8 strings
as arguments, some people will want to
Sape Mullender wrote:
ioctl(fd, SETVOLUME, vol); is more comfortable.
ah, but how about
echo volume 50 /dev/audioctl
for understandability?
Surely the maximum should be
echo volume 11 /dev/audioctl
Sape
Adrian
Has anybody ever thought about extending the usual file-based interfaces
with a typechecking ?
It did occur to me one could have:
echo 10 oranges /dev/apple-count
echo: write failed: inapropriate fruit
More seriously one of our researchers once asked me why computer
It did occur to me one could have:
echo 10 oranges /dev/apple-count
echo: write failed: inapropriate fruit
This gets a lot harder when the data is just
space-separated decimal numbers. For example,
bind /net/tcp /proc; ps.
Russ
Ian Currie's Newspeak language, for safety-critical programming
did that. Well, to be more precise, it added dimensional analysis
to the type analysis.
Neat.
Don't know anything else that has put it in the language. Anyone?
Martin
On Fri, 31 Mar 2006 02:15:57 +0100 Steve Simon [EMAIL
On 3/30/06, Roman Shaposhnick [EMAIL PROTECTED] wrote:
On Thu, Mar 30, 2006 at 07:27:32PM +0100, [EMAIL PROTECTED] wrote:
(especially with an additional constraint that nobody
reads man pages) ?
Aren't man pages are what you read in between experimentation and
asking for help on IRC?
;)
Depends on how lazy you are. Lazy people read the man page first,
hackerly types experiment, and lazy hackers spend their time on IRC
anyway so it's not much more effort to go on and ask.
;)
Jack Johnson wrote:
On 3/30/06, Roman Shaposhnick [EMAIL PROTECTED] wrote:
On Thu, Mar
echo 'g''day it''s me again' /dev/ctl
brucee
On 3/31/06, Lluís Batlle i Rossell [EMAIL PROTECTED] wrote:
Andrew Simmons wrote:
La evidenta respondo estas Esperanto.
Please call the hall porter, there appears to be a frog in my bidet???
Haha :) Yes, this is a famous sentence. I
51 matches
Mail list logo
