After some unidentified event the /etc/passwd, /etc/shadow have turned
into block-special files.
I can not simply remove them because of “resource busy”.
The “/bin/chkfsys /dev/hd0t77” saw the filesystem as “busy”.
I stopped /bin/tinit and thus made possible to un-busy the filesystem as
a whole.
But still I can’t remove or un-busy /etc/passwd and /etc/shadow.
Try booting from a QNX 6.3 CD and doing a chkfsys. Be warned though, this can destroy the contents if chkfsys gets confused. Might be safest to image the partition first.
The filesystems are the same. You can manage the QNX4 files from a QNX6
boot.
I did not know that.
But still - I do not have Q6…
And even if I had one - I doubt that QSSL did provide us with a tool
similar to the famous Norton’s DiskEdit.EXE for DOS.
What I see is - “ls -la” shows the first “b” instead of the “-” infront of
the file permissions.
If it would not be a “Zeitnot” here - I’d probably gone studiing the QNX’s
filesystem and edited the relevant raw disk sector manually…
I can’t “zap” those files too.
[offtopic]
I see the two HUGE drawback’s with QSSL - they decided to not provide a
decent compiler by dropping Watcom, and they do not provide no means to
see after the disks - no “speeddisk”, no “diskdoctor”, no “diskeditor”…
[/offtopic]
The filesystems are the same. You can manage the QNX4 files from a
QNX6 boot.
I did not know that.
But still - I do not have Q6…
That’s easy fixed, http://www.qnx.com/products/eval/index.html
And in case you didn’t know, after expiry it’s still completely usable except for a few key compiling/building tools.
I see the two HUGE drawback’s with QSSL - they decided to not provide
a decent compiler by dropping Watcom, and they do not provide no means
to see after the disks - no “speeddisk”, no “diskdoctor”, no
“diskeditor”…
Don’t be so quick to condemn GCC.
chkfsys is their diskdoctor.
zap also exists, the new “user manual” is very good.
spatch is their binary editor, to use it on a partition “spatch /dev/hd0t79” as an example.
Their disc caching sucks so that’s one sore point.
chkfsys is their diskdoctor.
It did not help me with that particular problem…
zap also exists, the new “user manual” is very good. >
Neither /bin/zap was able to zap’em…
spatch is their binary editor, to use it on a partition “spatch
/dev/hd0t79” as an example.
This demands the VERY high level of understanding of the filesystem, I
did not have time to learn it… Now I’ll do…
Tony.
(I’ve re-inited the partition and re-installed QNX4)
[offtopic]
I see the two HUGE drawback’s with QSSL - they decided to not provide a
decent compiler by dropping Watcom,
[/offtopic]
Well, Watcom got aquired, then that company got acquired. The new owners
of Watcom terminated the compiler as a product. They would not sell or
support it any more. Continueing with a dead product just wasn’t an
option.
Also, Watcom was a great compiler for x86, but QNX6 supports PPC,
MIPS, ARM, and SH4 too. Not so hot.
For improved Intel code, we now offer (in partnership with Intel) ICC,
the Intel compiler for x86. This should give excellent x86 code
generation.
On Tue, 26 Apr 2005 21:44:14 +0400, David Gibbs <dagibbs@qnx.com> wrote:
For improved Intel code, we now offer (in partnership with Intel) ICC,
the Intel compiler for x86. This should give excellent x86 code
generation.
Which will never be available for QNX4…
I wish it could be possible to port OpenWatcom to QNX4 - with int64 et al.
On Tue, 26 Apr 2005 21:44:14 +0400, David Gibbs <> dagibbs@qnx.com> > wrote:
For improved Intel code, we now offer (in partnership with Intel) ICC,
the Intel compiler for x86. This should give excellent x86 code
generation.
Which will never be available for QNX4…
I wish it could be possible to port OpenWatcom to QNX4 - with int64 et al.
I wish it could be possible to port OpenWatcom to QNX2 - with int64 et al.
In fact I wish it could be possible to port Visual .Net to Windows 3.1
The keyword is “WAS”, in the far-far 90s … I’ve tested it (OW 1.3) on huge
mathematical operations some time ago, and … it gave me the worstest
results comparing to other compilers (with -Onetrax options), it even slower
than the gcc 2.95.3. So say RIP to watcom …
Sorry couldn’t resists, lol!
I wonder what made you so funny?
Actually, the only thing stops - it’s the unavailability of the
RunTimeLibrary sources. I got OW for windows, brought all the headers and
libs onto windows box - it works for cross-compiling. If QSSL decides to
update Slib32 to include “%ll” support into “printf()|scanf()” - I’d be
relatively happy.
On Wed, 27 Apr 2005 08:51:07 +0400, Mike Gorchak <mike@malva.com.ua> wrote:
I’ve tested it (OW 1.3) on huge mathematical operations some time ago,
and … it gave me the worstest results comparing to other compilers
(with -Onetrax options), it even slower than the gcc 2.95.3. So say RIP
to watcom …
You should have used GMP for that.
GMP v4.1.4 IS fast, v5 is promised to be faster still.
Hello, Tony!
You wrote on Wed, 27 Apr 2005 12:46:57 +0400:
T> On Wed, 27 Apr 2005 08:51:07 +0400, Mike Gorchak <mike@malva.com.ua>
T> wrote:
??>> I’ve tested it (OW 1.3) on huge mathematical operations some time ago,
??>> and … it gave me the worstest results comparing to other compilers
??>> (with -Onetrax options), it even slower than the gcc 2.95.3. So say
??>> RIP to watcom …
T> You should have used GMP for that.
T> GMP v4.1.4 IS fast, v5 is promised to be faster still.
No, it was my own library for elliptic curves cryptography No assembly,
just plain C code, so speed is compiler-only dependant.
On Wed, 27 Apr 2005 15:10:14 +0400, Mike Gorchak <mike@malva.com.ua> wrote:
You should have used GMP for that. GMP v4.1.4 IS fast, v5 is promised
to be faster still.
No, it was my own library for elliptic curves cryptography > > No
assembly, just plain C code, so speed is compiler-only dependant.
So, do you dare to claim your library was better than GMP?
I’m sorry to tell - I do not believe this.
There are tests showing the 2~2.5 times more speed in GMP than in BigNum
(from OpenSSL package) on RSA operations.
Could you re-implement your eliptic-curves crypto using GMP and re-test?
Only then one may tell about the inherent speed of the compiler’s code.
??>>> You should have used GMP for that. GMP v4.1.4 IS fast, v5 is
??>>> promised to be faster still.
??>> No, it was my own library for elliptic curves cryptography No
??>> assembly, just plain C code, so speed is compiler-only dependant.
T> So, do you dare to claim your library was better than GMP?
Of course.
T> I’m sorry to tell - I do not believe this.
It’s your right
T> Could you re-implement your eliptic-curves crypto using GMP and re-test?
Am I look like a moron ? Anyone in their right mind will not infect his
own code with GPL virus.