Re: [ql-developers] uQLx for Mac OS X!
Quoting "Phoebus R. Dokos" <[EMAIL PROTECTED]>: > a uQLx port for Mac OS-X (with Apple's X11) has been added thanks to the > work of James Weatherley (You rock!) as you already know. > Now it is also available online! Has anyone else had luck getting this to run? On my G4, with 10.2.6, I only get bus errors. Running Apple's X11 public beta 3. I got the exact same thing when I tried building it a while back on my Sparc Slowaris box, so it's strangely comforting in it's familiarity. :) I tried invoking ./qm, and then variations on that like ./qm -o romdir/Min166.rom. It's crashing in strlen(), which is being invoked (eventually) by QMParams() (which is invoked by SetParams()). I could go digging into the code and find why, but thought I'd see if it's just OE first.. Tx, Mark - This mail sent through IMP: http://horde.org/imp/
Re: [ql-developers] Linux v2.4.21 compilation error with gcc v3.1
On Thu, 21 Aug 2003 09:58:01 +0200, Richard Zidlicky wrote: > On Wed, Aug 20, 2003 at 04:24:20PM +0200, Thierry Godefroy wrote: > > Hi, > > > I'm using the full crypto-API (with all the ciphers; AES being a rather > > weaker one than Serpent, for example...). > > Serpent is distributed in the ciphers package of loop-AES. > It is an extra download but no hassle compile. > Btw some recent cryptoanalysis suggests AES is actually less > susceptible to a certain type of attack then Serpent so it > is far from easy which one is weaker. Still no immediate > threat. Actually, this is not quite exact. It is true that more cryptoanalyis was done on Serpent (which algorythm is easier to analyse). But so far more rounds have been broken in AES (Rinjdael) than in Serpent (unless I missed one of the lastest articles about thos algorythms, which is possible). The reason why Rinjdael was choosen as the AES instead of Serpent is unclear and even highly suspicious to me... It is admitedly a little faster than Serpent, but was pointed out as less secure than Serpent too (and as it was not as much crypto-analyzed as Serpent, one may find a shortcut attack on day or another...). My thought is that the NSA is probably quite interested in having an AES algorythm which is not too difficult to break... I personally use Serpent with 256 bits keys for the encrypted partitions on my PCs. It's of course probably too slow for the Q60 though (128 bits keys seem more reasonable for a poor 68060 @ 66MHz to deal with...). > > > What is the advantage of SuperMount over autofs? > > > > It's 100% automatic, doesn't need for any demon, and it doesn't hog the > > processor/drives by checking every few seconds that a new medium was > > inserted... As soon as an access is requested to a supermounted medium, > > then a check for changed/absent medium is made transparently for the user. > > It's the standard 'automounter' for Mandrake and I just love it. :-) > > appart of the extra demon this sound really very much like what autofs > does for me. How does it work to release a medium, eg CD or floppy? With > autofs I have to wait until it timeouts. No wait with SuperMount. It's just like if you were using the medium under DOS/Windoze (Yuck !), or SMSQ/E... It's 100% kernel based and done at the driver level... The problem is that its author doesn't maintain it anymore and all the maintnance is now done by the Mandrake developers, and scattered in numerous patches to each kernel... There are times were you just can't find a proper (set of) patch(es) applying cleanly to a given kernel... Well, I could make one out of Mandrake's patches for Linux-vanilla v2.4.21 and I use it since v2.4.21 is out without a single problem. I'll put the patch on my q60linux website. ;-) > How do you configure it? It's like a filesystem driver. You configure it in fstab, example: /mnt/dos/a /mnt/dos/a supermount fs=vfat,dev=/dev/fd0 0 0 /mnt/cdrom /mnt/cdrom supermount fs=iso9660,dev=/dev/cdrom 0 0 More option can be passed to the underlying driver. A doc short is supplied in the patch and appears in the patched Linux sources tree as: Documentation/filesystems/supermount.txt > > Hmm... Strange... Mandrake's patched version of gcc v3.2.2 doesn't > > got this problem on i586 Linux... Perhaps would it be worth rebuilding > > the Mandrake gcc package for Linux-Q60 ? > > probably not, the problem is m68k specific afaics and Mandrake gets > much less non-x86 testing than RedHat or Debian does. Mandrake doesn't develope at all for the m68k architecture, alas... > I looked deeper into it, it is the assignment to error.all which > barfs the compiler. Translated to RTL this assignment is apparently > too complicated for the register life analysis to grok and it won't > set a REG_DEAD note to error.all where it should.. somewhere the > strict_low_part is in the way. > > As a workaround try to declare >char xerr > assign to xerr and return xerr. I patched the sources and I'm trying to compile them as I write this message... Do you know if the same problem would arise with older gcc version (I was thinking to compile it with gcc-2.95.3...) ? > > If you got a file server (ftp, sftp, web) where to get them, I'd prefer > > that way (faster now that I got an ADSL link ;-)... > > well I didn't get ADSL, the sourceforge site is still available of > course. There are no SRPMS in it though... Or do I look in the wrong place ? Thierry ([EMAIL PROTECTED]).
Re: [ql-developers] Mini Qx0 Linux distro
On Thu, 21 Aug 2003 22:31:45 +0100, Tony Firshman wrote: > Debian is worth getting _just_ for the apt_get etc. > > There were many packages I simply did not install under Redhat 'cos the > dependencies were just too complicated. Dependencies exist in all the Linux distributions and they are a nightmare to solve in all of them. Mandrake tried to solve them by splitting each software into numerous packages (one for the libraries, another for the binaries, another for the headers and devel tools, etc) and making the major number of the version a part of the packages basename. That way you can easily install newer versions of the libraries (keeping the old libs but removing all the old binaries, headers and the like in favour of the newer version ones) without breaking the dependencies of the oldest software installed on your system and without the need for a specific compatibilty package (like when the switch was made from libc5 to glibc: you had to install a libc5-compat package for the old apps to keep working on you glibc-upgraded system). Example: You got 'whatever v1.0' and you want to intall 'whatever v2.0' Under Redhat or debian, you typically got: wathever-1.0.arch.rpm & wathever-devel-1.0.arch.rpm or wathever-1.0.arch.deb & wathever-devel-1.0.arch.deb Under Mandrake you got: wathever-1.0.arch.rpm wathever-devel-1.0.arch.rpm libwhatever1-1.0.arch.rpm whatever-doc-1.0.arch.rpm Now, you want to upgrade to v2.0 but alas 'somethingelse v0.5' depends on the libraries in whatever-1.0... Under Redhat you'll either loose the dependency for 'somethingelse v0.5'if you upgrade (-U) the 'whatever' package, or you'll get conflicts on the packages files if you try to install (-i) instead the new whatever (does trying to keep the old files of the old package). With some luck, Redhat will provide a compatibility package (e.g.: libwhatever-compat), else you're stuck and must solve the conflicts manually... With Mandrake, you just upgrade everything and will get in the end: wathever-2.0.arch.rpm wathever-devel-2.0.arch.rpm libwhatever1-1.0.arch.rpm libwhatever2-2.0.arch.rpm whatever-doc-2.0.arch.rpm The dynamic libraries in libwhatever1 and libwhatever2 having different names (libwhatever.so.1 and libwhatever.so.2), you have no conflict at all and 'somethingelse v0.5' will keep working happily after the upgrade... I'm not sure how Debian works out those dependencies, but I find Mandrake's approach rather elegant. > apt_get is quite brilliant at sorting everything out. There are equivalent tools to app-get for RPMs now (urpmi, grpmi, etc)... Also, did you ever try to -uninstall- a .deb package on a Debian distribution (properly, i.e. getting rid of all the files that were installed by app-get) ? Well... good luck ! Thierry ([EMAIL PROTECTED]).
Re: [ql-developers] Mini Qx0 Linux distro
On Thu, 21 Aug 2003 14:38:48 +0200, Peter Graf wrote: > Hi Thierry, > > nice to see that you are active again! Only half-active, alas... Not yet enough free time to do serious development (i.e. SMSQ/E one)... > I'd like to ask if you are still > absolutely opposed to the idea of Debian based Qx0 Linux? I'm absolutely opposed to loose my (already very sparse) time learning a new system: I'm now quite used to Mandrake/Redhat and can build RPMs pretty much "on the fly" while working at something else (yes, I can multitask too :-P). This doesn't mean you can't build a Debian distribution for the Q60, but this does mean that you should not expect anything coming from me for this distribution. Sorry. Thierry ([EMAIL PROTECTED]).
Re: [ql-developers] Mini Qx0 Linux distro
On Thu, 21 Aug 2003 at 14:38:48, Peter Graf wrote: (ref: <[EMAIL PROTECTED]>) > >Hi Thierry, > >nice to see that you are active again! I'd like to ask if you are still >absolutely opposed to the idea of Debian based Qx0 Linux? Debian is worth getting _just_ for the apt_get etc. There were many packages I simply did not install under Redhat 'cos the dependencies were just too complicated. apt_get is quite brilliant at sorting everything out. I miss 'pico' but simply alias to 'nano' (8-)# -- QBBS (QL fido BBS 2:252/67) +44(0)1442-828255 tony@.co.uk http://www.firshman.co.uk Voice: +44(0)1442-828254 Fax: +44(0)1442-828255 TF Services, 29 Longfield Road, TRING, Herts, HP23 4DG
Re: [ql-developers] Mini Qx0 Linux distro
Hi Thierry, nice to see that you are active again! I'd like to ask if you are still absolutely opposed to the idea of Debian based Qx0 Linux? For a long time I feel the need for a really small Linux distro for Qx0 that is quick to install, and just *works* easily for those Qx0 users who don't have a PC to do what the have no QDOS/SMS software for. I recently found a 50MB Live Linux CD distro for x86 which can also be installed on harddisk. (http://www.damnsmalllinux.org). I have found there is no other distro of that size and quality which has a complete desktop. IMHO the selection of software is absolutely *great* for non-developers. (e.g. Xfbdev, Fluxbox window manager, MP3 and MPEG, FTP client, links-hacked web browser, ABS spreadsheet, Sylpheed email, FLWriter word-processor, Nedit, emacs clone, Xpaint, xzgv, Xpdf, emelFM, VNCviewer, SSH/SCP server and client, PPP, PPPoE, calculator, monkey web server, tcc ANSI C compiler) Unfortunately it is DEB based, and we are on RPM. We are so few Qx0 Linux users so I sure don't want to split manpower into DEB and RPM. But I'm really tempted by the idea of remastering DSL for Qx0... All the best Peter
Re: [ql-developers] Linux v2.4.21 compilation error with gcc v3.1
On Wed, Aug 20, 2003 at 04:24:20PM +0200, Thierry Godefroy wrote:
Hi,
> I'm using the full crypto-API (with all the ciphers; AES being a rather
> weaker one than Serpent, for example...).
Serpent is distributed in the ciphers package of loop-AES.
It is an extra download but no hassle compile.
Btw some recent cryptoanalysis suggests AES is actually less
susceptible to a certain type of attack then Serpent so it
is far from easy which one is weaker. Still no immediate
threat.
> > What is the advantage of SuperMount over autofs?
>
> It's 100% automatic, doesn't need for any demon, and it doesn't hog the
> processor/drives by checking every few seconds that a new medium was
> inserted... As soon as an access is requested to a supermounted medium,
> then a check for changed/absent medium is made transparently for the user.
> It's the standard 'automounter' for Mandrake and I just love it. :-)
appart of the extra demon this sound really very much like what autofs
does for me.
How does it work to release a medium, eg CD or floppy? With autofs I have
to wait until it timeouts.
How do you configure it?
> Hmm... Strange... Mandrake's patched version of gcc v3.2.2 doesn't
> got this problem on i586 Linux... Perhaps would it be worth rebuilding
> the Mandrake gcc package for Linux-Q60 ?
probably not, the problem is m68k specific afaics and Mandrake gets
much less non-x86 testing than RedHat or Debian does.
I looked deeper into it, it is the assignment to error.all which
barfs the compiler. Translated to RTL this assignment is apparently
too complicated for the register life analysis to grok and it won't
set a REG_DEAD note to error.all where it should.. somewhere the
strict_low_part is in the way.
As a workaround try to declare
char xerr
assign to xerr and return xerr.
Also attached minimal testcase if you want to compare various compiler
versions, use "-da" to get dumped all RTL passes.
> If you got a file server (ftp, sftp, web) where to get them, I'd prefer
> that way (faster now that I got an ADSL link ;-)...
well I didn't get ADSL, the sourceforge site is still available of
course.
> Gnome2 is a real nightmare and it sucks big time !!! Man, was I pissed
> off when I installed Mandrake v9.1 to update my good ol' Mdk 7.2 on my
> PCs... This stupid new Gnome is not only utterly broken, but it's a
> Hell to configure (they made the configuration 'simpler' by removing
> most of the options: the net result is that you can't get it to work
> your own way. If the default behaviour is fine with you then it's
> alright, else, you can spend hours trying to figure out what to do
> to obtain what you want !). Plus it eats 24Mb more memory than Cnome
> 1.2 on my PCs and is utterly sloww: it's definitely a no-no for a
> Q60, forget it altogether and stick with Gnome v1.4... or better, use
> a lighter, standalone WM, like Icewm (v1.0.9 available on my website),
> Blackbox or the like...
I like fluxbox a lot, the libs of Gnome2 will be still needed though.
> I never had problems with rpm 4.0 on Mandrake, but they pretty much
> changed everything compared to rpm v3... Even the databases are
> incompatible... Who said "upward compatibility" ? It looks like
> this concept was lost and forgotten a couple of years ago already...
Mandrake seems a bit radical with updates. My problem with rpm-4.1x
on the Q60 is that computation of the signature is sometimes broken,
probably a compiler problem.
Rebuilding the database was a bit of a hassle but no problem, old
packages work fine.
Richard
typedef union {
unsigned all :8;
} x_t;
char test_x (char sv)
{
x_t error;
if (sv)
{
error.all = sv;
}
return error.all;
}
