Believe me, they crashed often and hard if you wrote for them. Notably, when we got RiscOS3.1 it started going down more:( BASIC you were usually OK with, but with C you could make life hard for the user easily ("no stack for trap handler" anyone?). Even in BASIC, if you had an infinite loop, you had to know how to kill the current task, which wasn't a standard feature... argh...
And if you were writing modules, you could cause BIG trouble fast. There was nothing like the security infrastructure offered by Un*x.
Re:You have glibc 2.1 -- doesn't matter
on
Linux Q3Test 1.07
·
· Score: 1
q3test 1.05 runs fine with glibc 2.1.
OK, well, q3test 1.05 runs fine on my machine, which includes glibc 2.1 (Debian), so that suggests it isn't a problem.
ARM, the company, produces the designs and sells these on to partners who manufacture them and then resell them to customers who put them in machines who tehn resell *them* to end users like us who buy the things.
The Psion 5 uses an ARM design licensed to Cirrus. The StrongARM is actually an ARM clone originally designed by Digital (now manufactured by Intel) which is code-compatible.
(Disclaimer: I work for ARM, but I don't officially speak for them).
I just find it amusing to see the number of people saying the swirl sucks, given that last time the logos were shown on slashdot, it was the one most people seemed to be drooling over:}
Hm. Well, I've discovered that the best thing to do with gnome-session is give it a "--purge-delay=2500" argument. That at least gets everything started...
This is from gnome-core 1.0.5, though- I do remember previous gnome-sessions being *hideously* flaky.
And the whole shebang about trying to start a default window manager sensibly... .
It's my understanding that modules work by having a special allocated ELF section for the parameter data, and an unallocated section for the module description, parameter format description etc. When insmod loads the module, it interprets the parameters according to the description and pokes the vlues into the parameter area, then hands the allocated sections to the kernel. ?
If so, this would mean you can at least retrieve the names and format (string, integer etc.) of the parameters from the.o file.
See the MODULE_PARM, MODULES_DESCRIPTION (?) etc. macros in the kernel source.
You seem to be mixing up library design and language features.
GTK+ *is* OO. And, much to your dismay, it does have a class hierarchy. However, these are not representable is "standard" C, so macreos are used. If you use Objective-C or C++ bindings to the GTK+ libraries, you'll find them more "natural".
(NB, I've only *briefly* looked at the objective-C bindings, but the C++ bindings were quite nice).
If you mean Windows-style MDI interface, where the "internal" window looks like a normal window, but is embedded in an application frame, then I'd say.... NO! DON'T GO THERE!
IMHO, it's a horrible piece of UI, and anyone advocating it should be short. JMHO;)
> I still doubt that I'll be removing my RH 5.2 > anytime soon (well, except to upgrade to 6.0)
You have to *remove* RH 5.2 to upgrade it? That sucks, dude.
SRH
This must be me, it can't be the kernel...
on
Linux 2.2.0pre5
·
· Score: 1
> depmod should show ppp.o depending on bsd_comp.o and ppp_deflate.o
no no no no no no no!
bsd_comp and ppp_deflate depend on ppp, not the other way round!
using aliases is the right way. the kernel doesn't know that ppp-compress-24 is bsd_comp, and doesn't need to!
this approach means that a compression module will only be loaded if it is going to be used: if your ppp peer doesn't support compression, the modules won't be loaded, and everyone's happy, yes?
I should imagine that you can't load ppp_deflate without having ppp already loaded (could be wrong, can't check while at work), so having ppp *depend* on ppp_deflate would obviously be broken...
Slashdot Mirror
Hopefully you point people somewhere off-site for your public key, so that they don't just create an imitation key and sign the MD5 sums with that :|
No, I reckon they perpetrated this hoax to gain publicity :)
but which protocol over Ethernet? You want an entire TCP/IP stack on the card too?
Believe me, they crashed often and hard if you wrote for them. Notably, when we got RiscOS3.1 it started going down more :( BASIC you were usually OK with, but with C you could make life hard for the user easily ("no stack for trap handler" anyone?). Even in BASIC, if you had an infinite loop, you had to know how to kill the current task, which wasn't a standard feature... argh...
And if you were writing modules, you could cause BIG trouble fast. There was nothing like the security infrastructure offered by Un*x.
q3test 1.05 runs fine with glibc 2.1.
OK, well, q3test 1.05 runs fine on my machine, which includes glibc 2.1 (Debian), so that suggests it isn't a problem.
ARM used to stand for *Advanced* RISC Machines (not Acorn), but they've changed the name to just be ARM now.
ARM, the company, produces the designs and sells these on to partners who manufacture them and then resell them to customers who put them in machines who tehn resell *them* to end users like us who buy the things.
The Psion 5 uses an ARM design licensed to Cirrus. The StrongARM is actually an ARM clone originally designed by Digital (now manufactured by Intel) which is code-compatible.
(Disclaimer: I work for ARM, but I don't officially speak for them).
Someone's rev-eng'ed the link protocol and produced a Linux client. Istr they were talking about a kernel module to integrate it, too.
:}).
And, like someone else said, there's p3nfs although that's a bit of a hack (but more portable
Actually, isn't the PCMCI support shared with *BSD kernels as well? Istr that was one reason for it staying as a separate source tree.
I just find it amusing to see the number of people saying the swirl sucks, given that last time the logos were shown on slashdot, it was the one most people seemed to be drooling over :}
ipchains. use and love.
Hm. Well, I've discovered that the best thing to do with gnome-session is give it a "--purge-delay=2500" argument. That at least gets everything started...
This is from gnome-core 1.0.5, though- I do remember previous gnome-sessions being *hideously* flaky.
And the whole shebang about trying to start a default window manager sensibly... .
surely this can already be done to some extent?
.o file.
It's my understanding that modules work by having a special allocated ELF section for the parameter data, and an unallocated section for the module description, parameter format description etc. When insmod loads the module, it interprets the parameters according to the description and pokes the vlues into the parameter area, then hands the allocated sections to the kernel. ?
If so, this would mean you can at least retrieve the names and format (string, integer etc.) of the parameters from the
See the MODULE_PARM, MODULES_DESCRIPTION (?) etc. macros in the kernel source.
You seem to be mixing up library design and language features.
GTK+ *is* OO. And, much to your dismay, it does have a class hierarchy. However, these are not representable is "standard" C, so macreos are used. If you use Objective-C or C++ bindings to the GTK+ libraries, you'll find them more "natural".
(NB, I've only *briefly* looked at the objective-C bindings, but the C++ bindings were quite nice).
If you mean Windows-style MDI interface, where the "internal" window looks like a normal window, but is embedded in an application frame, then I'd say.... NO! DON'T GO THERE!
;)
IMHO, it's a horrible piece of UI, and anyone advocating it should be short. JMHO
> I still doubt that I'll be removing my RH 5.2
> anytime soon (well, except to upgrade to 6.0)
You have to *remove* RH 5.2 to upgrade it? That sucks, dude.
SRH
> depmod should show ppp.o depending on bsd_comp.o and ppp_deflate.o
no no no no no no no!
bsd_comp and ppp_deflate depend on ppp, not the other way round!
using aliases is the right way. the kernel doesn't know that ppp-compress-24 is bsd_comp, and doesn't need to!
this approach means that a compression module will only be loaded if it is going to be used: if your ppp peer doesn't support compression, the modules won't be loaded, and everyone's happy, yes?
I should imagine that you can't load ppp_deflate without having ppp already loaded (could be wrong, can't check while at work), so having ppp *depend* on ppp_deflate would obviously be broken...