Re: systat total freeze
Hi, frantisek holop min...@obiit.org wrote: | hi there, [.] | could the reason be, that after the update both | libkvm.so.13.0 and libkvm.so.13.1 were still under /usr/lib? The dynamic linker will use the first library it encounters to resolve the symbols (which can be used for nice tricks via some LD_PRELOAD environment, if supported by the link mechanism). ldd(1) shows up which library is linked into a program (or other dynamic library): ?0%0[steffen@obsdc steffen]$ ldd /usr/bin/systat /usr/bin/systat: StartEnd Type Open Ref GrpRef Name 0040 00824000 exe 10 0 /usr/bin/systat 000200a0c000 000200e65000 rlib 01 0 /usr/lib/libcurses.so.12.1 00020ccf8000 00020d12 rlib 01 0 /usr/lib/libm.so.7.0 000200602000 000200a0c000 rlib 01 0 /usr/lib/libkvm.so.13.1 00020c812000 00020ccf8000 rlib 01 0 /usr/lib/libc.so.64.0 00020c40 00020c40 rtld 01 0 /usr/libexec/ld.so So the answer to the question above is no. However, file descriptor reference counting changed recently and if an old libkvm would work with a new kernel then this could surely result in such behaviour (let me quote this as i don't know the real codeflow, please). According to my plus log all that work has been done rather atomically on 2012-05-01, though. | -f | -- | death is proven to be 99.9% fatal to all laboratory rats. I think i belong to the other 0.1%. Thanks --steffen Forza Figa!
Re: File descriptor - name?
Alan Corey ab...@devio.us wrote: | Is there a way to get the name of a file that's open when all you've | got is a file descriptor? | | I'm working on porting something, that I didn't write. with directories | full of source. I'm seeing a problem with an ioctl being the wrong type, | but I'm looking at the code where it happens, I can't see what the file | descriptor passed in is pointing to. Seems like there should be a way. | |Alan | I guess fstat(1) is your friend. --steffen Forza Figa!
Re: undeadly (window managers)
Marc wrote: the reason why i like it is precisely because it's simple and doesn't come with tons of features that change all of the time, it's the same look feel on all systems I use, and has been like that for years. That is true for me, too. I don't use any pointing devices for normal workflow at all, only if i have to enter web-browser, PDF-viewer or if i go audacity, so i'm thankful this is so easily possible with ahwm. And i require my ALT-TAB with it's *natural* flow. (IMHO.) (To be honest - on this MacBook i sometimes enjoy the touchpad: gestures are fat on the code side, but fingertipping is a sensual experience for sure.. Must be a bit of the usual 1st world megalomania - *everything*, and at your fingertip..) Anyway, i was happy that i've found ahwm, as i had kinda frustrating experiences using fvwm*, icewm and the others i tried. And it has a real documentation, that was not self-evident at that time. And it worked the way it should right away. (And when there's nothing, there's nothing you can run from.) It would be a pity if such a good piece of software would get lost. I remember reading an article in the german computer magazine c't around year 2000 (something) about a (Mac) text editor named Pepper, and it was a rather enthusiastic report. Then, once i got this MacBook in 2009, i searched the internet - and it was *all gone*! No executable, no code, nowhere. Amit wrote: Yes, I concur with this sentiment. Having tried many WMs, and doing repetitive wiping of installs/port building that you eventually want stability and not go hunting why this or that broke. It just diverts your time away from your planned work for that day. So I now use the default fvwm like Marc says he does, but I am looking for a very fast compiled lightweight WM, and will try out the alternatives :-) Having had no contact to port stuff yet, i'll try to provide the ahwm package as fast as possible, for you to try ,- I looked for a nice stub template and found one in jwm, so maybe it'll do without reading all the port documentation beforehand. (cough.) Brett wrote: Joe's Window Manager is fast to compile. I've been using for a few months and have not noticed any bugs. The config file is in xml and easy to set up, and very flexible. Combined with dmenu you can setup a system for fast workflow. It is stacked, not tiling, though, so maybe some programmers might not like that aspect. 1.6 MB screenshot. XML configuration. Hey, Joe. Oh! That's jwm! Well. --steffen Forza Figa!
Re: undeadly
Hi all you messy-int-typedef-mix rejectors,
Jeremy O'Brien wrote [2012-04-25 13:56+0200]:
On Wed, Apr 25, 2012 at 01:21:06PM +0200, Gilles Chehade wrote:
On Wed, Apr 25, 2012 at 07:10:32AM -0400, Jeremy O'Brien wrote:
On Wed, Apr 25, 2012 at 12:04:27PM +0200, mxb wrote:
On 04/25/2012 11:52 AM, Mihai Popescu wrote:
[reducing like grazy, very unpolite]
Nice article about Paris.
I think it is Window Manager and grouping.
Forgot the name of this minimalistic WM. Anyone to point this out?
P.S.
I see at least two WM in use on those photos. One is from the base.
//maxim
First laptop has ion3, editor is emacs with custom emacs.conf:
https://www.poolp.org/~gilles/emacs/emacs.conf
Also, how I managed to appear on a picture while only attending 3/4 hours
is an achievement in itself ;-p
Thanks for the input. I'm also very nosy when it comes to the
(windowing/editing) environments that people work/code in. Always
looking for new ideas.
if you like then you should really give ahwm a try.
I'm using it since 2002 (almost eight years on FreeBSD, and since
about 4 months again on OpenBSD in addition).
It's a real nifty thing and has an even smaller memory footprint
than cwm, while being much more sweet, e.g., each desktop can have
different window decoration colors (e.g. root-logins ALL RED).
You can also send windows to specific workspaces automatically
through their given name, as in
# .xinitrc
rxvt-unicode -title Ed -e vim
# .ahwmrc
WindowName Ed {
DefaultWorkspace = 1;
#Sticky = True;
#Omnipresent = True
}
I think cwm doesn't do that (at least yet).
Read the .rc, it contains almost the entire docu (functions,
selectors, options; do bindings, defines - whatever)
But now the *absolute hammer*!
The guy who wrote that grazy thing back in 2002 has just (!)
modified his webpage and now states something like
Please note: this page, and this code, haven't been updated in
ten years. This is of historical value only.
IT'S NOT!? I'M USING IT DAILY!
Please do not hesitate to contact me
Why should i?
to report bugs
Why should i??
or request new features
Why should i, dammit???
Sat Feb 9 19:49:37 CST 2002
Released version 0.90. This is the initial beta release of AHWM.
It may contain bugs.
Fri Apr 20 02:12:35 PDT 2012
Did not release any new version in the preceeding ten years.
Updated this page to make it clear that updates are unlikely.
Ha! You don't say.
Just because you don't touch your did-once-for-good piece of
software means that it's historical.
Maybe you see it as an OpenBSD package before 5.2 is released.
Has a nice rather-BSD license, has it.
Thanks for your understanding.
P.S.: Forget your cat - my wild one is much more beautiful.
--steffen
Forza Figa!
Re: Shuttle XS35 v2 - One key going loco
Opera wrote [2012-03-30 12:58+0200]: Using the same keyboard where I first saw the bug but connected to a plain old PC. I use hexdump like this: # hexdump -C tap the problem key, then hit return and then Cntrol-D With numlock off I see: ^[[3~ 1b 5b 33 7e 0a 0005 With numlock on: . 2e 0a 0002 Using the same keyboard with a ps2-USB adaptor I see the same result as the numlock off test above whether numlock is on or off. This is what I see on the Shuttle also but it has no ps2 sockets so on it I'm stuck with no working dot key on the numpad and of course old habits die hard so I mess up lots of ip addresses. Is there something in wsconsctl or such that would let me patch it? I've been hunting through various related man pages but I have not hit on a hint so far. Hey, b-by! Just recently i've posted a patch to tech@ that let's you examine the scancode of a key via wsconsctl!!! Then you can use basic wsconsctl features to set the key to whatever you want, now that you can identify it!! By the way - Marco Peereboom has posted a great ksh(1) to tech@ on 2011-09-06 that let you do graceful multi-character-sequence key binding, which may also be of interest to you. Was for me. And YOU ARE THE FIRST Windows NT user i know of who cares about keyboard scancodes! This is just a FANTASTIC EXPERIENCE for me. THANK YOU (P.S.: there is a X program which gives you even more info, so that you can adjust your .xmodmaprc or so.) --steffen Forza Figa!
Re: Is nginx to complement or replace apache?
Theo de Raadt wrote [2012-03-28 22:44+0200]: If software cannot cope intelligently with soft resource limits, then such software is probably broken. Otherwise, let's just remove the entire resource limit subsystem, ok? I found out that i miss some kind of physical keyword. The impossibility to compile insn-attrtab in my VM was caused by insufficient memory, and gcc(1) being unable to detect that it effectively entered an endless loop. Once i've lowered the softlimit i got a clear 'virtual memory exhausted' message. So some kind of automatic adjustment of the limits to physically present mem (+swap) would have helped a bad admin here. Maybe i find time next week to write a small MAX_RETRY patch for gcc. --steffen Forza Figa!
Re: ksh's HISTFILE
Hi,
Claus Assmann wrote [2012-03-14 03:05+0100]:
Maybe try something like this?
HISTFILE=${HOME%/}/.ksh_hist.$$
for what's it worth, i do use the following in my multi-shell
(ksh(1), bash(1), FreeBSD sh(1)) .shrc:
export TTY=$(/usr/bin/tty | /usr/bin/sed -e 's/.\{1,\}\/\(.\{1,\}\)$/\1/')
export HISTFILESIZE=4221
if [ ${SHELL} != ${SHELL%%bash} ]; then
export HISTCONTROL=ignoreboth
export HISTFILE=$HOME/traffic/.bash_hist_$TTY
shopt -s expand_aliases
elif [ ${SHELL} != ${SHELL%%ksh} ]; then
export HISTFILE=$HOME/traffic/.ksh_hist_$TTY
set -o emacs
set +o emacs-usemeta
fi
(OpenBSD sed(1) supports -E now, so those old regexes have been
definitely outdated in the meanwhile.)
And for ksh(1) i'm finally about to try out that textfile-based
history patch that Marco Peereboom has posted to tech@B on
2011-09-01. 'Am currently fixing mysterious whitespace after
i had to apply the patch with -l. So much whitespace. Puuh.
That was tested extensively by a lot of people that hang around
the lists, Amit, LEVAI Daniel, and more. (And works for me sofar.)
Aaeeh - easier to grep/sed/cat whatever on a text-based file, hah??
What a pity that this is unused!
ACH! Not to talk about my own (alloc) patch. (sob.)
Is it monday lately? (sob.) Oh, wednesday. Well, then..
--steffen
Forza figa!
Re: My OpenBSD 5.0 installation experience (long rant)
Henning Brauer wrote [2012-03-09 20:51+0100]: i hope obama never tries to scroll up. that red shiny button... Sorry, but that knocked me out. Good night. --steffen
Re: Trusting the Installation
Rudolf Leitgeb wrote [2012-03-05 13:51+0100]: Look where almost all desktop and laptop CPUs come from. And where these devices plus their peripherals are made. Oh yes! You really just can't trust America. Really. --steffen
Re: Unbound in base
Henning Brauer wrote [2012-02-14 13:52+0100]: anything depending on PYTHON MY WOMAN! (gimme a break) Aeh. Man. will never make it into base anyway. If it were true! --steffen
Re: Long delay updating xenocara source tree?
Stuart Henderson wrote [2012-02-10 01:01+0100]: On 2012-02-09, Steffen Daode Nurpmeso sdao...@googlemail.com wrote: On the long run cvs(1) will die, and be replaced by Schily SCCS oh please don't, even as a joke. It's not that bad! It's from 1972, and only good things can come from 1972. And my daily dose of Hypericum; highly recommendet. we will need a bulk order if we have to use SCCS ;) Somehow the lights have to become brighter! --steffen
Re: Long delay updating xenocara source tree?
1. On the long run cvs(1) will die, and be replaced by Schily SCCS (oh god, why does v6 not have any branch name info, too??), which will rule the world. Without having the need to use GNU autoconf at all, so that software will compile with make(1) not gmake(1). Make bootstrapping easy. Freedom! Peace!! Love!!! Yup. 2. I like my patch. And my daily dose of Hypericum; highly recommendet. Jan Stary wrote [2012-02-09 13:16+0100]: [.] Actually, cvs(1) says: [.] This is not true for cvs(1) on MacOS X (Snow Leopard), btw. And heaven knows if a Linux system does have any manpages at all! Right?? (TinyCore definitely has none.) Yes, but it will also change the content of CVS/Root in directories that existed before. Huh? But that's right, push the people to it! The current FAQ does not massage CVS/Root related brain cells! I think this is blind typing without understanding I quote myself (quotes removed from sites though, so it may not be remembered 100 percent correctly): I use version control daily, but i don't want to think about it. (It was due to our massive internal hg(1)/git(1) war, and my favorite hg(1) - the user interface is so much better and easier to understand - 'lost due to .. Python and the .. backend.) That is to say: i agree with you. I am psychologically experienced. Can someone with internal knowledge of cvs shed some light on this please? Thank you for your time Jan --steffen
Re: Long delay updating xenocara source tree?
there aren't all that many repositories the size of ours out there. My upload-traffic problem never occurred with binutils, which is also an *incredible* large repository, especially if you up -d. 10% there and my monthly traffic would exhaust, and no begging would help. I have no idea, I just observerd the slowdown multiple times. --steffen
Re: Long delay updating xenocara source tree?
Otto Moerbeek wrote [2012-02-03 12:47+0100]: I like to say that long delays I have seen when using cvs had to do with multiple different values of CVS/Root files in my local tree. Those different entries can be created when doing a cvs up -d that creates a new dir. If a cvs -d option is used at the same time, the CVS/Root entry for tht dir wil be different than the other's. The exact cause of the slowdown is not known to me. But when you are switch repositories once in a while it's easy to get this case. I repair this by find . -name Root | xargs rm and using a explicit cvs root. Now this is really another important issue of scattered information, is it, and it's not noted in anoncvs.html! I've slightly modified your command, i think my version is more secure for use on a webpage. -Otto --steffen Index: anoncvs.html === RCS file: /cvs/www/anoncvs.html,v retrieving revision 1.363 diff -a -p -u -r1.363 anoncvs.html --- anoncvs.html24 Jan 2012 09:57:35 - 1.363 +++ anoncvs.html3 Feb 2012 13:33:28 - @@ -542,6 +542,15 @@ add the em-d anon...@anoncvs.ca.openbs # strongcd /usr/src/strong # strongcvs -d anon...@anoncvs.ca.openbsd.org:/cvs -q up -Pd/strong /pre + +p And because cvs(1) stores the name of the server which is in use once +a directory gets created in the file CVS/Root inside this new directory, +it maybe wise to issue a command sequence like the following: +pre + # strongcd /usr/src/strong + # strongfind . -path '*CVS/Root' | xargs rm/strong + # strongcvs -d anon...@anoncvs.ca.openbsd.org:/cvs -q up -Pd/strong +/pre /ul p
Re: Long delay updating xenocara source tree?
Henning Brauer wrote: there aren't all that many repositories the size of ours out there. That's true. But no Henning, i don't believe it's that; you know, it's just that i don't have anything to say, because i have no knowledge about the internals of cvs(1). I always thought of this as some kind of misbehaviour in between OpenCVS and GNU cvs, because i would think of cvs(1) as something like this: cvs up . | read CVS/Entries | for those files with diff. timestamps, checksum file | send list [+ checksums] to server | server compare revision/timestamp/[checksum] - client unmodified: send diff (expected final checksum?) - client modified: send full file (if size treshold), otherwise do blockwise checksumming etc. (i.e. rsync-like) [I don't really believe cvs(1) does the latter though.] | integrate diffs / replace locally modified files Wether cvs(1) does do some rsync-like block-checksumming for locally modified files or not, uploading 10% of the repositories size or more before any data is sent from the server just can't be correct anyhow. Even more for my usage case because there were no locally modified files at all. And also the problem goes away if you do specify files directly, as with a file glob, so it makes a difference wether you say $ cvs -fz9 up -PAC . or $ cvs -fz9 up -PAC *.* I don't remember wether i've used -d or not. So for me this turned out as either look into the code, instrument some functions and try to fix it or turn over to cvsync. And GNU cvs is hard to look at, with a lot of comments which refer to some (numeric or so) error reports. But it would surely be interesting to know what is going wrong. --steffen
Re: Long delay updating xenocara source tree?
Hi Amit, Amit Kulkarni wrote [2012-02-01 00:57+0100]: this motivated me to use cvsync from anoncvs and use a CVSROOT=/home/amit/MYLOCALREPO to update from cvs. Much much faster and while initial checkout from cvsync takes 5-10 hrs Yes, that's a real pity. I think it would be great if tarballs would be offered for those, too. I.e. this is *all* of OpenBSD (src, xenocara and www, the latter however refuses papers/, slides/ and songs/ because i also have a checkout of the Steelix translation project), as has been burned onto my last full-backup DVD: $ ls -latr -rw-r--r-- 1 steffen wheel 516407350 26 Jan 15:41 cvsync_openbsd.tbz I think plain gzip wouldn't be that much larger. And hey, it's worth noting that this is smaller than .git/objects/pack of src.git alone! the subsequent updates are lightning quick. Yes. And how easy it now is to do 'cvs up -PAC' to overwrite my messy patches. --amit Ciao, --steffen
Re: Long delay updating xenocara source tree?
Hey, Dave Anderson wrote [2012-01-28 15:13+0100]: [.] I haven't yet had a chance to look into how cvs works beyond reading the man page, faq, etc. Also true for me. I've run into this problem perhaps a dozen times over the past several months [.] I've noted a lot of upload network traffic when doing 'cvs up' on OpenBSD repos; i.e., before anything else happened about ~70 MB (www) and ~150 MB (src) *upstream* traffic were produced, and it took more than an hour before the download of data began (src). I never had similar problems with anoncvs.mindrot.org, nor cvs.savannah.gnu.org and *.cvs.sourceforge.net etc. If you're doing your updates in such a regular manner, i think your best bet is cvsync(1), even if that means additional local storage - but it is *far* more efficient in both, time and traffic. (Not to talk about the possibility to do 'cvs log' and the like locally, without internet connection; if that's an issue.) Pears similar ciao, --steffen
Re: Keyboard mapping
Hi,
Simon Perreault wrote [2012-01-23 21:44+0100]:
/etc/kbdtype contains cf. I tried playing with kbd and wsconsctl.
I'm not an expert, but i'll append something for you to play with
even more. Maybe it'll help you.
Otherwise wait for the answer of someone who actually is an
expert.
Everything seems normal except the above mentioned keys that do
nothing.
If the program you are working with is eight bit clean (ksh(1)
doesn't work, csh(1) does), maybe it's the mapping.
AFAIK there is no way, neither in base nor in packages, to print
out the actually used scancodes of the keyboards' keys.
After i've messed up another keyboard-related question last week
or so (;) i've sat down and wrote a small thing which prints out
the currently used ones, so that it's possible to compare them
with the output of
$ sudo wsconsctl keyboard.map
Note that this is intermediate version, don't type too fast
(ridiculous buffer handling) etc., but i haven't had time to
polish it. But it works.
IMHO a subset of that should be part of wsconsctl(8), btw.
Hope that helps,
good night and ciao,
--steffen
-- 8 --
/* wscons_scankey, a yet not finished showkey-thing.
* Compile:
* $ gcc -W -Wall -pedantic -ansi -o wscons_scankey wscons_scankey.c
* Use (not on pseudo-terminal):
* $ ./wscons_scankey [krtv] # default = k
*/
#include err.h
#include errno.h
#include signal.h
#include stdio.h
#include stdlib.h
#include termios.h
#include unistd.h
#include sys/ioctl.h
#include sys/time.h
#include dev/wscons/wsconsio.h
static struct termios tios_orig, tios_raw;
static int no_raw;
static void onsig(int sig);
static void rawinit(void), rawon(void), rawoff(void);
static void
onsig(int sig)
{
rawoff();
exit(! (sig == SIGALRM));
}
static void
rawinit(void)
{
if (tcgetattr(STDIN_FILENO, tios_orig) 0)
err(3, Can't query terminal attributes);
tios_raw = tios_orig;
(void)cfmakeraw(tios_raw);
return;
}
static void
rawon(void)
{
auto int arg = WSKBD_RAW;
if (tcsetattr(STDIN_FILENO, TCSANOW, tios_raw) 0)
err(3, Can't set terminal attributes);
if (! no_raw ioctl(STDIN_FILENO, WSKBDIO_SETMODE, arg) 0) {
int x = errno;
(void)tcsetattr(STDIN_FILENO, TCSANOW, tios_orig);
errno = x;
err(3, Can't put keyboard in raw mode (
needs the WSDISPLAY_COMPAT_RAWKBD kernel option));
}
return;
}
static void
rawoff(void)
{
auto int arg = WSKBD_TRANSLATED;
if (! no_raw)
(void)ioctl(STDIN_FILENO, WSKBDIO_SETMODE, arg);
(void)tcsetattr(STDIN_FILENO, TCSANOW, tios_orig);
return;
}
int
main(int argc, char **argv)
{
enum { MODE_KEYCODE, MODE_RAW, MODE_VALUE } mode = MODE_KEYCODE;
ssize_t br, i;
auto struct sigaction sa;
auto struct itimerval it;
auto char buf[64];
if (argc 1)
switch (**++argv) {
case 'k':
mode = MODE_KEYCODE;
break;
case 't':
no_raw = 1;
/* FALLTHRU */
case 'r':
mode = MODE_RAW;
break;
case 'v':
mode = MODE_VALUE;
no_raw = 1;
break;
default:
mode = -1;
break;
}
if ((int)mode 0)
errx(1, Usage: wscons_showkey [krtv]
(keycode, raw, termios-raw, value));
if (!isatty(STDIN_FILENO))
err(1, STDIN is not a terminal);
rawinit();
sa.sa_handler = onsig;
sa.sa_flags = 0;
(void)sigfillset(sa.sa_mask);
for (i = 0; i _NSIG; ++i)
if (sigaction((int)i + 1, sa, NULL) 0 i == SIGALRM)
err(2, Can't install SIGALRM signal handler);
printf( You may now use the keyboard;\n
After five seconds of inactivity the program terminates\n);
for (;;) {
it.it_value.tv_sec = 5;
it.it_value.tv_usec = 0;
it.it_interval.tv_sec = it.it_interval.tv_usec = 0;
if (setitimer(ITIMER_REAL, it, NULL) 0)
err(2, Can't install wakeup timer);
rawon();
br = read(STDIN_FILENO, buf, sizeof buf - 1);
rawoff();
if (br = 0)
break;
/* src/sys/dev/wscons/wsksymdef.h */
switch (mode) {
case MODE_KEYCODE: {
unsigned int rc, c;
const char *meta;
for (i = 0; i br; ++i) {
rc
Re: Static or dynamic code analysis software
Chris Smith wrote [2012-01-16 13:21+0100]:
Are there any dynamic or static C code analysis tools available for
OpenBSD? [swoosh]
You may try llvm from packages, it aims to have a good analyzer.
lint(1) is in base.
I'd still like to be able to check that I've not made any
hideous cock-ups in my code.
You may do manual code adjustments, as in
ret
fun(args)
{
var;
nyd_enter;
[non_crashing_]asserts[_jumps];
[nyd wherever]
jleave:
nyd_leave;
return;
}
and then define the nyd_* series to something useful (not-yet-dead
peeps or collection of profiling info, as desired).
This works for many years quite well for me (userland).
A few minutes of poking around the Internet returned nothing useful
unfortunately.
Well, if you're running Xorg(1), xeyes(1) may help you to do the
job if you're happily distracted (due to whatever reasons).
Best Regards,
Otherwise the usual rules may help you:
- make functions as small as possible (much less than a screenful
of lines),
- place useful comments in the code,
- implement tests for all possible and impossible usage cases
(easily possible with non-crashing assertions)
- ask yourself with all possible seriousness why you can't wait
for C 2015 which will finally introduce a garbage collector,
instead of manually fooling around with memory pointers today!
Until then malloc(3) and its MALLOC_OPTIONS may help you a bit,
too.
- And always revisit your code some time after you have forgotten
what it is for; may you never have the material pressure to
release it at an earlier time.
Chris Smith
May the juice be with you.
--steffen
Re: Longsoon/Godson MIPS boxes, where to buy?
Richard Thornton wrote [2011-12-30 14:25+0100]: what's your damage? The damage of Fritz WChler is that he doesn't read books. I'm currently reading Richtisch beese MC$uler (Hessische Satiren) Reallybad Jaws (Satires from Hesse) a retrospective of humour from my little homeland :), and one of the stories therein is Heinrich Hoffmann - HandbCchlein fCr WChler - 'Little [or: Petty] Handbook' for Agitators The same author also wrote The Story of Little Suck-a-Thumb. You get the idea ... Fritz - stop your handwork, read this first. Bye! beside that. --steffen
Re: Where to buy Lemote FuLoong MIPS boxes?
Gregory Edigarov wrote [2011-12-19 11:30+0100]: Taiga and Niva is two different models, just for the record... You cannot hide Austria only because the boys (B;BurschenB+) are not qualified for Ukraine/Poland 2012! What if England had not been able to qualify? Would you pretend not to know --- *England*? --steffen
Re: Where to buy Lemote FuLoong MIPS boxes?
Welly, welly, welly, welly, welly, welly, well! I dunno, but maybe Fritz simply misunderstood A Clockwork Orange - completely, that is? The same actor also played in Caligula. That one is much much better for your handwork, Fritz! And couldn't some cute Austrian restart selling OpenBSD in Austria, now that Fritz no longer uses an austrian remailer?? I feel so uncomfortable - as if Lada would no longer produce Nivas! (Taiga in Austria, right?) Nice weekend beside all that. --steffen
cvs is the project's VCS (Was: Re: Updating plus.html)
Stuart Henderson wrote [2011-11-07 9:47:53+0100]: the three public cvs-git imports of OpenBSD are separate efforts I desperately searched for some OpenBSD git(1) repository and couldn't find one, but remembered one post of yours and so i ended up at anoncvs.estpak.ee, having no problem ever since. I don't even like that program at all (yeah, *only* because i have been toggled off the git mailing list, hm), i like the concept, which git also implements, and in C. I do (and even regular OpenBSD developers seem to) work with git locally; being able to use topic branches, stashing data away, cherry-picking changesets from different topics, being able to look at some history without an internet connection) etc. - these are tasks i've dreamed of in the past, maybe even wet. Etc. etc. etc. That is to say, to end this lengthy thing, i would have appreciated it if i would have found some URL to a trusted git clone on the official OpenBSD homepage at that time. Even if there would have been a note that the project itself has chosen to use cvs(1) and that git clones are unofficial. --steffen
Re: cvs is the project's VCS (Was: Re: Updating plus.html)
Philip Guenther wrote [2011-11-07 19:03+0100]: On Mon, Nov 7, 2011 at 5:37 PM, Steffen Daode Nurpmeso sdao...@googlemail.com wrote: ... That is to say, to end this lengthy thing, i would have appreciated it if i would have found some URL to a trusted git clone on the official OpenBSD homepage at that time. Even if there would have been a note that the project itself has chosen to use cvs(1) and that git clones are unofficial. Here's a link to something that the project doesn't control, doesn't use, and doesn't monitor. AFAIK this is a chain of trust anyway. Or are there any bots around that check the actual content of the mirrors? And here we (me, that is) talk of a service that is provided by a trusted mirror, FTP and AnonCVS. But wait - it seems to be located in the U.S.A... You're right!!! Right, because no one will complain to the project when that's out of date or backdoored. It's right there on your webpage! Anything unofficial is strictly between you and the entity providing it, so why would you trust that more than the result of a google search? In support.html i read The following individuals and organizations have indicated that they are able to provide support as indicated. However, the OpenBSD Project does not necessarily endorse any of these. Please contact each site directly. ..murmur.. (And the entry there which claims to be in my hometown actually moved to Ginsheim-Gustavsburg, the phone number seems to be completely out-of-date, at least if i compare support.html with his own webpage. No joke! Will mail him after this here.) Philip Guenther steffen (Trying to be [me], though deaf)
Re: cvs is the project's VCS (Was: Re: Updating plus.html)
I have a mail of someone who is actively fought by the henchmen of No. 43! Theo de Raadt wrote [2011-11-07 18:52+0100]: Even if there would have been a note that the project itself has chosen to use cvs(1) and that git clones are unofficial. wow, that's backwards. History is very important. if anything is official, we mention it. if anything is not unofficial, we don't mention it. With time, dedication and a whole lotta love CVS sure will do fine. Even though i'm deaf most of the time, i've noted that git (i really doesn't like it, maybe libgit2 will someday even do transport and garbage-collection, and then) comes up once in a while, also on tech. Time will surely bring a lot of OpenBSD Mercurial and git full-history clones on the various large (free) hosters. In the first world internet is cheap today, and a background rlog which takes a week doesn't hurt (one may think). Would i like an official git repo? Yes, i would. And that's it for me on this now, really. Thanks for listening and good night, steffen
Re: Updating plus.html
Hi all,
i still have some doubts about that github thing.
Or, to be more exactly, i just don't know.
But it turns out that the two repos only have three heads in common:
BOOTBLOCKS, BRIAN and graichen (from the 19-hundreds).
On Fri, Nov 4, 2011 at 12:45 AM, Brett brett.ma...@gmx.com wrote:
Later on I guess I will get around to doing it via github.
Amit Kulkarni wrote:
When you do git pull of github.com/openbsd it will give you some
errors
Hm.
git ls-remote git://anoncvs.estpak.ee/openbsd-src |
perl -e 'while (STDIN) { chomp; ($hash,$ref) = split; \
print$ref $hash\n; }' |
sort EE_REV; wc -l EE_REV
131
git ls-remote git://github.com/openbsd/src.git |
perl -e 'while (STDIN) { chomp; ($hash,$ref) = split; \
print$ref $hash\n; }' |
sort HO_REV; wc -l HO_REV
131
cat EE_REV HO_REV |B sort |B uniq | wc -l
259
Hm.
It was no secure transport in either case.
--steffen
Re: Updating plus.html
I would say, you follow the github.com/openbsd repo, and do a git log.
Just a question: i'm personally tracking
git://anoncvs.estpak.ee/openbsd-{src,xenocara}, a link which was
introduced by Stuart Henderson in a message some months ago.
Is that github.com repo (beside the fact that it also offers www)
in any way special, or was it just that you had it at hand?
Thanks.
--steffen
Re: Updating plus.html
Ciao, Ingo Schwarze wrote [2011-11-02 15:58+0100]: When Nicolas did it and i saw what he said regarding mandoc(1), i sometimes went Huh? Which change is that referring to? or a few times even What? I never did that... - even though Nicolas certainly used care and spent considerable effort, even though mandoc is certainly a relatively easy part of the system, and even though my commit messages tend to be more verbose than those of some other developers. Translating your messages was the hardest part of 49.html. Really. Completely clear and transparent in english, but curiously compacted. (You may have some fun at the end of the week - just in case you'll look at the translation, then.) Amit Kulkarni wrote on Wed, Nov 02, 2011 at 09:18:55AM -0500: Yeah, its a lot of work... found out the hard way. It was a huge time sucker. I didn't realize the problem of this thread at all sofar. But if it would be ok to have someone work on that once a week, then i would offer myself for this, too. (Nothing what Ingo Schwarze said about required knowledge is true for me though. I'm only a userland-library programmer. :)) Due to the expected time that is required (i spent almost five days of free time on 49.html), i really would appreciate to be part of a team. I.e., maintaining plus.html without doing at least a shallow message/manual(/code) audit doesn't seem to be useful to me. And we're talking about some 300 commits per month, of which the most have to be included (it seems). This file was *actively maintained* by a *single* person in the past! I didn't know that! Wow!! I guess i thought that this file is produced automatically, maybe by magic cvs(1) commit-message-tags or the like. Well, i hope i don't promise too much and too fast.. What do you think? Thanks and good night, --steffen
Re: Patch for dhclient.8 and dhclient.c
Jason McIntyre j...@cava.myzen.co.uk wrote [2011-10-22 16:24+0200]: i will look at it. but i'm pretty sure we won;t want that. jmc Thanks for looking at *that* anyway! It was the wrong source diff from somewhere in between. I can't comment on 'egress' otherwise. ifconfig.8 talks about default route(s), and get_ifname() fails if more than one interface is in that group. This is why i asked: it all may end up as if anyone uses a network layout which does not fit in this scheme, something is horribly wrong. I'm not an administrator, but pretty local in all aspects. --steffen
Re: Patch for dhclient.8 and dhclient.c
Argh! - besides everything what jmc@ said, it should have been
the following diff *for sure*:
diff --git a/sbin/dhclient/dhclient.8 b/sbin/dhclient/dhclient.8
index 9d77c7e..b6094c1 100644
--- a/sbin/dhclient/dhclient.8
+++ b/sbin/dhclient/dhclient.8
@@ -57,6 +57,16 @@ The name of the network interface that
.Nm
should attempt to
configure must be specified on the command line.
+If the given name starts with the character
+.Cm = ,
+then
+.Nm
+will treat the remaining characters as the name of a group defined by
+.Xr ifconfig 8 ,
+and try to use the interface which is marked in that group.
+See
+.Xr ifconfig 8
+for more on groups.
.Pp
The options are as follows:
.Bl -tag -width -p port
@@ -169,7 +179,8 @@ database of acquired leases
.Xr dhclient-script 8 ,
.Xr dhcp 8 ,
.Xr dhcpd 8 ,
-.Xr dhcrelay 8
+.Xr dhcrelay 8 ,
+.Xr ifconfig 8
.Sh AUTHORS
.An -nosplit
.Nm
diff --git a/sbin/dhclient/dhclient.c b/sbin/dhclient/dhclient.c
index 8d35021..3fb1bf7 100644
--- a/sbin/dhclient/dhclient.c
+++ b/sbin/dhclient/dhclient.c
@@ -2073,41 +2073,57 @@ fork_privchld(int fd, int fd2)
void
get_ifname(char *ifname, char *arg)
{
+#ifdef SMALL
+ if (strlcpy(ifi-name, arg, IFNAMSIZ) = IFNAMSIZ)
+ error(Interface name too long);
+#else
struct ifgroupreq ifgr;
struct ifg_req *ifg;
+ char *group;
int s, len;
- if (!strcmp(arg, egress)) {
- s = socket(AF_INET, SOCK_DGRAM, 0);
- if (s == -1)
- error(socket error);
- bzero(ifgr, sizeof(ifgr));
- strlcpy(ifgr.ifgr_name, egress, sizeof(ifgr.ifgr_name));
- if (ioctl(s, SIOCGIFGMEMB, (caddr_t)ifgr) == -1) {
- if (errno == ENOENT)
- error(no interface in group egress found);
- error(ioctl SIOCGIFGMEMB: %m);
- }
- len = ifgr.ifgr_len;
- if ((ifgr.ifgr_groups = calloc(1, len)) == NULL)
- error(get_ifname);
- if (ioctl(s, SIOCGIFGMEMB, (caddr_t)ifgr) == -1)
- error(ioctl SIOCGIFGMEMB: %m);
-
- arg = NULL;
- for (ifg = ifgr.ifgr_groups;
- ifg len = sizeof(struct ifg_req); ifg++) {
- len -= sizeof(struct ifg_req);
- if (arg)
- error(too many interfaces in group egress);
- arg = ifg-ifgrq_member;
- }
-
+ if (*arg == '=')
+ ++arg;
+ /* 'egress' for compatibility */
+ else if (strcmp(arg, egress)) {
if (strlcpy(ifi-name, arg, IFNAMSIZ) = IFNAMSIZ)
- error(Interface name too long: %m);
+ error(Interface name too long);
+ return;
+ }
- free(ifgr.ifgr_groups);
- close(s);
- } else if (strlcpy(ifi-name, arg, IFNAMSIZ) = IFNAMSIZ)
+ /* Try deduce interface from if */
+ group = arg;
+
+ s = socket(AF_INET, SOCK_DGRAM, 0);
+ if (s == -1)
+ error(socket error);
+ bzero(ifgr, sizeof(ifgr));
+
+ if (strlcpy(ifgr.ifgr_name, group, IFNAMSIZ) = IFNAMSIZ)
error(Interface name too long);
+
+ if (ioctl(s, SIOCGIFGMEMB, (caddr_t)ifgr) == -1) {
+ if (errno == ENOENT)
+ error(no interface in group %s found, group);
+ error(ioctl SIOCGIFGMEMB: %m);
+ }
+ len = ifgr.ifgr_len;
+ if ((ifgr.ifgr_groups = calloc(1, len)) == NULL)
+ error(get_ifname);
+ if (ioctl(s, SIOCGIFGMEMB, (caddr_t)ifgr) == -1)
+ error(ioctl SIOCGIFGMEMB: %m);
+
+ arg = NULL;
+ for (ifg = ifgr.ifgr_groups;
+ ifg len = sizeof(struct ifg_req); ifg++) {
+ len -= sizeof(struct ifg_req);
+ if (arg)
+ error(too many interfaces in group %s, group);
+ arg = ifg-ifgrq_member;
+ }
+ (void)strlcpy(ifi-name, arg, IFNAMSIZ);
+
+ free(ifgr.ifgr_groups);
+ close(s);
+#endif /* SMALL */
}
Patch for dhclient.8 and dhclient.c
Ciao, 49.html states: dhclient(8) now accepts 'egress' as an interface name, meaning whichever interface is marked as being in the 'egress' group. but the manual page doesn't mention it. Also it seems to me that dhclient.c:get_ifname() uses an error() call with a %m format without any errno around. (Nice fat %m.) (Since the data was filled in from the kernel, it even seems to be sufficient to replace the entire conditional with (void)strlcpy(ifi-name, arg, IFNAMSIZ);) Btw., ifconfig(8) doesn't state at all that there is a limit imposed on the length of groupnames. And ifconfig.c even restricts availability of groups to #ifndef SMALL but neither does ifconfig.8 state that nor does dhclient.c do any such check; it surely will get ENOSYS or something in the end though.. --steffen diff --git a/sbin/dhclient/dhclient.8 b/sbin/dhclient/dhclient.8 index 9d77c7e..3694ff1 100644 --- a/sbin/dhclient/dhclient.8 +++ b/sbin/dhclient/dhclient.8 @@ -57,6 +57,14 @@ The name of the network interface that .Nm should attempt to configure must be specified on the command line. +The special name +.Ar egress +will be automatically expanded to the interface which is assigned to the +.Em egress +group. +See +.Xr ifconfig 8 +for more about groups. .Pp The options are as follows: .Bl -tag -width -p port @@ -169,7 +177,8 @@ database of acquired leases .Xr dhclient-script 8 , .Xr dhcp 8 , .Xr dhcpd 8 , -.Xr dhcrelay 8 +.Xr dhcrelay 8 , +.Xr ifconfig 8 .Sh AUTHORS .An -nosplit .Nm diff --git a/sbin/dhclient/dhclient.c b/sbin/dhclient/dhclient.c index 8d35021..1c6ac40 100644 --- a/sbin/dhclient/dhclient.c +++ b/sbin/dhclient/dhclient.c @@ -2104,7 +2104,7 @@ get_ifname(char *ifname, char *arg) } if (strlcpy(ifi-name, arg, IFNAMSIZ) = IFNAMSIZ) - error(Interface name too long: %m); + error(Interface name too long); free(ifgr.ifgr_groups); close(s);
Re: Patch for dhclient.8 and dhclient.c
Hello again,
ok and while i did the patches i'm replying to, i did't
understand: the code seems to be a real nifty automatic deduction
of configuration data which is made available somewhere else
(ifconfig(8)).
It may be stupid, useless etc.
The appended diff implements a '=GROUPNAME' command line argument
syntax, and thus allows to freely specify groups.
What do you think of that?
--steffen
diff --git a/sbin/dhclient/dhclient.8 b/sbin/dhclient/dhclient.8
index 9d77c7e..b6094c1 100644
--- a/sbin/dhclient/dhclient.8
+++ b/sbin/dhclient/dhclient.8
@@ -57,6 +57,16 @@ The name of the network interface that
.Nm
should attempt to
configure must be specified on the command line.
+If the given name starts with the character
+.Cm = ,
+then
+.Nm
+will treat the remaining characters as the name of a group defined by
+.Xr ifconfig 8 ,
+and try to use the interface which is marked in that group.
+See
+.Xr ifconfig 8
+for more on groups.
.Pp
The options are as follows:
.Bl -tag -width -p port
@@ -169,7 +179,8 @@ database of acquired leases
.Xr dhclient-script 8 ,
.Xr dhcp 8 ,
.Xr dhcpd 8 ,
-.Xr dhcrelay 8
+.Xr dhcrelay 8 ,
+.Xr ifconfig 8
.Sh AUTHORS
.An -nosplit
.Nm
diff --git a/sbin/dhclient/dhclient.c b/sbin/dhclient/dhclient.c
index 8d35021..fa0cbef 100644
--- a/sbin/dhclient/dhclient.c
+++ b/sbin/dhclient/dhclient.c
@@ -2077,37 +2077,47 @@ get_ifname(char *ifname, char *arg)
struct ifg_req *ifg;
int s, len;
- if (!strcmp(arg, egress)) {
- s = socket(AF_INET, SOCK_DGRAM, 0);
- if (s == -1)
- error(socket error);
- bzero(ifgr, sizeof(ifgr));
- strlcpy(ifgr.ifgr_name, egress, sizeof(ifgr.ifgr_name));
- if (ioctl(s, SIOCGIFGMEMB, (caddr_t)ifgr) == -1) {
- if (errno == ENOENT)
- error(no interface in group egress found);
- error(ioctl SIOCGIFGMEMB: %m);
- }
- len = ifgr.ifgr_len;
- if ((ifgr.ifgr_groups = calloc(1, len)) == NULL)
- error(get_ifname);
- if (ioctl(s, SIOCGIFGMEMB, (caddr_t)ifgr) == -1)
- error(ioctl SIOCGIFGMEMB: %m);
-
- arg = NULL;
- for (ifg = ifgr.ifgr_groups;
- ifg len = sizeof(struct ifg_req); ifg++) {
- len -= sizeof(struct ifg_req);
- if (arg)
- error(too many interfaces in group egress);
- arg = ifg-ifgrq_member;
- }
-
+ s = (*arg == '=');
+ if (s)
+ ++arg;
+ /* 'egress' for compatibility with 4.9 */
+ else if (strcmp(arg, egress)) {
if (strlcpy(ifi-name, arg, IFNAMSIZ) = IFNAMSIZ)
- error(Interface name too long: %m);
+ error(Interface name too long);
+ return (0);
+ }
+
+ /* Try deduce interface from if */
+ s = socket(AF_INET, SOCK_DGRAM, 0);
+ if (s == -1)
+ error(socket error);
+ bzero(ifgr, sizeof(ifgr));
- free(ifgr.ifgr_groups);
- close(s);
- } else if (strlcpy(ifi-name, arg, IFNAMSIZ) = IFNAMSIZ)
+ if (strlcpy(ifgr.ifgr_name, arg, IFNAMSIZ) = IFNAMSIZ)
error(Interface name too long);
+
+ if (ioctl(s, SIOCGIFGMEMB, (caddr_t)ifgr) == -1) {
+ if (errno == ENOENT)
+ error(no interface in group %s found, arg);
+ error(ioctl SIOCGIFGMEMB: %m);
+ }
+ len = ifgr.ifgr_len;
+ if ((ifgr.ifgr_groups = calloc(1, len)) == NULL)
+ error(get_ifname);
+ if (ioctl(s, SIOCGIFGMEMB, (caddr_t)ifgr) == -1)
+ error(ioctl SIOCGIFGMEMB: %m);
+
+ arg = NULL;
+ for (ifg = ifgr.ifgr_groups;
+ ifg len = sizeof(struct ifg_req); ifg++) {
+ len -= sizeof(struct ifg_req);
+ if (arg)
+ error(too many interfaces in group %s, arg);
+ arg = ifg-ifgrq_member;
+ }
+
+ (void)strlcpy(ifi-name, arg, IFNAMSIZ);
+
+ free(ifgr.ifgr_groups);
+ close(s);
}
share/man/man4/em.4
Ciao, i've found a mismatch in between 49.html and the mentioned man(1) (82583V). 'Coming from nowhere, should be verified by someone who knows. --steffen diff --git a/share/man/man4/em.4 b/share/man/man4/em.4 index 2b0fa5c..8d4aac6 100644 --- a/share/man/man4/em.4 +++ b/share/man/man4/em.4 @@ -43,8 +43,9 @@ driver provides support for PCI, PCI-X and PCI Express Gigabit Ethernet adapters based on the Intel 82540EM, 82540EP, 82541EI, 82541ER, 82541GI, 82541PI, 82542, 82543GC, 82544EI, 82544GC, 82545EM, 82545GM, 82546EB, 82546GB, 82547EI, 82547GI, 82562V, 82563EB, 82564EB, 82566DC, 82566DM, 82571EB, 82571GB, 82572EI, 82572GI, -82573E, 82573L, 82573V, 82574L, 82575EB, 82575GB, 82576EB Ethernet controller -chips and the embedded chips found on EP80579 platform, including the following: +82573E, 82573L, 82573V, 82574L, 82575EB, 82575GB, 82576EB, 82583V +Ethernet controller chips and the embedded chips found on EP80579 platform, +including the following: .Pp .Bl -item -offset indent -compact .It
Commit log messages
Hello, thanks go indeed to you. And i'm a bit ashamed right now. That Daode has been given to me somewhen, it belongs to my philosophy, but there is *really* no need at all to include it somewhere for *you*. It's also (useless) typing like crazy. So, please, shall i ever be able to provide something useful, don't hesitate to shorten that at will. Thanks. --steffen
Sorry for that noise
Anonymous Remailer (austria) mixmas...@remailer.privacy.at Scheint mir diese armselige Fritz WChler KrC6te zu sein. Schade, das sein Account **nicht** im September expired ist ... (The Fritz WChler account actually expired in september. It really had to create a new one!) Hast es immer noch nC6tig, was! (You poor boy need it pretty urgent, huh?) Deine Springerstiefel sehnen sich nach ZC$rtlichkeit. (Your combat boots are longing for tenderness. [Actually a cite from a song of the german Softpunk-band 'Die Crzte' (The Doctors)].) Wirklich eine Schande, so einem verschissenen Kameradschaft-SCd Heini im Internet zu begegnen. (It's a fucking pain in the ass to meet one of those dumb Nazis in the Internet.) DEUTSCH. (Deutsch!) Was sonst??? (What else.) Kein Wunder, das wir so beliebt sind ... (Good machine. [Seriously?]) Luftwaffe und Kindergarten. ZUM KOTZEN!! (McDonalds.) Oder 88, wir ihr Eierlosen brCllt, wenn ihr in einer Horde auftretet. (Actually 'Heil Hitler!' is forbidden in germany, which is why these kids can't tattoo it on their neck. So they do tattoo '88!', for 'HH!', i.e. the eigth character in the alphabet. You know - it's a thing with those balls.) (Sorry for this shit, but Fritz WChler may continue forever if you say words like 'Wash your mouth'. It has already drunk some beer this morning, as you can see.) --steffen
Re: Dennis Ritchie
== ORIGINAL MESSAGE == To: austin-grou...@opengroup.org Date: Thu, 13 Oct 2011 14:36:26 +0200 Dennis Ritchie, one of the two fathers of UNIX, and the father of C, has passed away today. via Rob Pike - 8:02 PM - Public I just heard that, after a long illness, Dennis Ritchie (dmr) died at home this weekend. I have no more information. I trust there are people here who will appreciate the reach of his contributions and mourn his passing appropriately. He was a quiet and mostly private man, but he was also my friend, colleague, and collaborator, and the world has lost a truly great mind.
Re: My thoughts on OpenBSD - is advocacy working ?
@ Daniel Villarreal yclwebmas...@gmail.com wrote (2011-09-01 17:21+0200): Seeing and hearing that Lamborghini was a pleasant surprise. Lambo is Audi now. I.e. Volkswagen - one generation. OK, two. I'd also be interested in checking out one of the Tesla motor cars. And Tesla is actually a modified Lotus Elise with a fat battery which is worth 20 KM. Isn't it? The nice thing about the Lotus is that it's only 50% of the weight of a Lambo. 'Think even the mentioned Alfa is maybe more lightweight than that. The nice thing about a Caterham is that it's even more lightweight. And i know a dapple-gray mare which is more hot-blooded than all of the mentioned! Trust me. Be thankful that you're not a stallion. --Steffen Ciao, sdaoden(*)(gmail.com) ASCII ribbon campaign ( ) More nuclear fission plants against HTML e-mailXcan serve more coloured and proprietary attachments / \ and sounding animations
Re: OT: Seems OpenBSD isn't absolutely alone in it's quest, atleast on embedded systems.
This really has nothing to do on this list, but here I go...
@ Ariane van der Steldt ari...@stack.nl wrote (2011-06-08 14:00+0200):
I did say that. I said code proof (assisted or manual) is a lot of work.
Yes, we should start over. If we start over we can make it so much
better! We can do this and that and... spend ten times as much time to
reach where we are now.
We're doing that already. And we're much better in it than you.
I don't know what fighting on the same plane means. Can you please
explain?
Bingo.
Huh, point? Where?
Well this monday i really planned to darken down your (all of you)
day, with this:
#include fcntl.h
#include stdio.h
#include stdlib.h
#include unistd.h
#include sys/mman.h
int
main(void)
{
#define ERROR(T,MSG)if (T) { perror(MSG); exit(1); }
void *mp;
ssize_t wb;
off_t off;
char sb[8];
int fd = open(test.dat, O_RDWR | O_CREAT | O_EXCL, 0600);
ERROR(fd 0, open);
off = lseek(fd, (off_t)0xfffdUL, SEEK_SET);
ERROR(off 0, lseek);
wb = write(fd, abcd, 4);
ERROR(wb != 4, write);
/*ERROR(fcntl(fd, F_FULLFSYNC), fcntl(F_FULLFSYNC)); fsync() insuff.
*/
mp = mmap(NULL, 0x10001ULL, PROT_READ, MAP_PRIVATE, fd, 0);
ERROR(mp == NULL, mmap);
sb[0] = *((char*)mp + 0xfffdUL + 0) - '0'; write(1, sb, 1);
sb[0] = *((char*)mp + 0xfffdUL + 1) - '0'; write(1, sb, 1);
sb[0] = *((char*)mp + 0xfffdUL + 2) - '0'; write(1, sb, 1);
sb[0] = *((char*)mp + 0xfffdUL + 3) - '0'; write(1, sb, 1);
write(1, \n, 1);
ERROR(munmap(mp, 0x10001ULL), munmap);
ERROR(close(fd), close);
return 0;
}
running on OS X (it was due to the vmmap thread), and the
expected behaviour should have been
ab
SIGBUS
and then i wanted to talk about that i don't believe that Open
Source software will last over time because you have to walk
yourself instead of being driven in a nice shuttle bus etc. etc.
Even free heroin shipped by SuperBiscuit can't beat that, unless
- maybe - on a perfect day...
(I did not know about the super cheap hotel mail at that time.)
But guess what? Apple fixed the mmap bug on sparse files!
No nore
3. For at least sparse files the VMS of Mac OS X is unable to
create an accessible mmap(2)ing if the size of the mapping is
in the inclusive range
UINT32_MAX+1 .. UINT32_MAX + PAGESIZE (== 4096)
and the file has been written to.
(but maybe still
killed all tests which spent more than about three minutes first,
later i did so whenever 900M was not reached in top(1) output -
it seems to me that Apple's VM is not intelligent enough to
detect that it effectively has entered an endless loop!!!)
I was so disappointed! I maybe roared like a non-useless lion
would. No useful contribution by me in 2011.
--
Ciao, Steffen
sdaoden(*)(gmail.com)
() ascii ribbon campaign - against html e-mail
/\ www.asciiribbon.org - against proprietary attachments
Re: vmmap: bad software everywhere
@ Corey clinge...@gmail.com wrote (2011-06-01 04:39+0200): I mean, come on -- storing data in unused bits in a pointer? Even I know that's a bad idea. But really, there are user-space memory pools which align on 8 or 16 byte boundaries, so here you have at least three perfectly fine bits. That's at least sometimes much much better than growing a structure by that very size for one bit or two. Super object. Washing machine. (Ooh - upper bounds are beyond my scope.) -- Ciao, Steffen sdaoden(*)(gmail.com) () ascii ribbon campaign - against html e-mail /\ www.asciiribbon.org - against proprietary attachments
Re: vmmap: bad software everywhere
@ Otto Moerbeek o...@drijf.net wrote (2011-06-01 14:12+0200): Storing tag bits in the lower bits of a pointer can be ok indeed if you know things about alignment restrictions. Of course it all stands and falls with the quality of the memory allocator! If that sucks your canary's chirp beeps like a mouse in a huge arena! So no - no randomness here. And beside that it tends to get inscrutable when accessing the bits, even if one uses unions to avoid casts. -- Ciao, Steffen sdaoden(*)(gmail.com) () ascii ribbon campaign - against html e-mail /\ www.asciiribbon.org - against proprietary attachments
Re: vmmap: bad software everywhere
@ Alexey Suslikov alexey.susli...@gmail.com wrote (2011-06-01 21:04+0200): Why do they need such a trick instead of simply storing tags in a associative array, where key is a pointer and value is a set of tags (or any other arbitrary data)? Lookup against properly aligned array is relatively fast. Am I missing something? May i answer this. One reason is of course space consumption. If you have 1 objects you need 1 hash nodes and i don't know how many indices the array shall have in this situation. And also, following a pointer chain is poison for CPU cache housekeeping. I.e. in that meaningless example // _area-owner-cbin_table[u.cbin-cbin_index] = u.cbin; you have to wait multiple times for memory to become available. And this is *really* expensive! -- Ciao, Steffen sdaoden(*)(gmail.com) () ascii ribbon campaign - against html e-mail /\ www.asciiribbon.org - against proprietary attachments
Re: Choosing a window manager...
On Tue, 15 Mar 2011 19:50:50 +0100, marc li...@drwx.org wrote: Hi all, Subject: Choosing a window manager... All of you - you are completely misguided. The redmoondian horror misled you to use crude stuff. (Hey, if you're american: crude is *not* a noun here!!!) 'Cause there is one, and only *one* real and functioning window manager on this whole small planet! And it is ahwm. (http://people.cs.uchicago.edu/~ahiorean/ahwm/) Free at last, free at last, oh how i wished i would be free at last. And it is ahwm. -- Steffen sdao...@gmail.com
Re: Wildest Africa Tour
On Thu, Apr 07, 2011 at 12:14:43PM +0200, Tobias Ulmer wrote: Lions are useless: http://www.youtube.com/watch?v=TBpu4DAvwI8 The Gods Must Be Grazy.
