Hi Leeeoooo

I understand your point, but let me remind you of this...

A keyed passphrase is necessarily a low entropy passphrase...

Immagine u use a 49 key sequence at boot to enter your passphrase... most naive ppl would think this is a "strong" ( 8x49=392 ) 392 bits passphrase...

Nothing could be more away from reality... this is really a 146 bits passphrase, since every first nibble in each byte of your passphrase is known by the attacker, it is the starting sequence of a key character...

Using a passphrase stored in a Usb allows u to use some sort of "text" in your memory, only of your knowledge, and compute the hash value of it, using a strong ( probably designed by yourself ) hash algorithm that will "map" any binary stream to the set of, say 512 bits streams, a set with 2^512 elements ( a bit big IMAO... )

Clearly, there is the posssibility of generating a collision in yr hash algorithm, but this can be "engineered" to be arbitrarily low.


Such a "message digest" of your memorized text would constitute a high entropy ( "Information-theoretically" speaking ) binary stream, approaching "true" randomness...

... A *REALLY STRONG* passphrase...


I guess AlienBob's approach ( probably combined with "custom" variations of cryptographic primitives ( extended keylength and round-count symmetric encryption, etc )) would constitude a much more reliable approach, IMHO

BRGDS

Alex


PS: The very simple fact that you are the only one to know the text used to generate the passphrase through the message digest computation, allows you to repeat the same steps ang regenearte the passphrase in the USB key, should you ever lose the original...

...leaving you only with the burden of backing up your hdd's content, dd if=/dev/random of=/dev/sda, and regenerating an install of Slackware over an encrypted partition in LVM... 20mn to do this...

The concept, yes, no doubt, but the "look and feel," no.

IMHO, the Multilib (32 bit compatibility) files should be part of the default Slackware64 installation, or at the very least, an option during the installation.
Your preference?

That's a valid point. Sooner or later it's going to happen anyway so that would be an incentive for developers to release applications for 64bit systems. Having said that, I'd like 13.1 to be multilib due to the fact that there are still a few packages that I like that haven't been ported to 64.

It's a bit like with windows/linux: more users choose windows because software developers concentrate on the windows market. Software developers, on the other hand, focus on the windows platform because it's got a much bigger user base.

It is understandable, but unfortunately true. When I'm in one of those "I should just throw in the towel and use m$-winbloat moods" one reason is many Open Source applications are not only written for m$-winbloat first, but often work better than the Linux version.

You may now notice that there is a poll at the top of the thread, this is because of recent administrative changes to certain threads within the Slackware forum.

Thanks XavierP it is good to provide statistical feedback to the superb development team that we have as Slackware users.

samac

Would you please take your US vs EU debate over here please and leave this thread for Slackware discussion only?

http://www.linuxquestions.org/questions/general-10/

0 members found this post helpful.

Hmm.. Seems you are a bit late

The debate ended a full three weeks ago, and it's been almost 2 weeks since there were even posts made to this thread, until today (maybe yesterday); so, I believe it's safe to say the thread is on track now.

Best regards,
Sasha.

my 2 cents is that the cross compiler packages should be offered in extra, but do to all the unforeseen and unfixable compile errors on a multi lib platform, the other packages should not be in extra. I have run into numerous programs that will try and reference the 32bit libs instead of the 64bit during compile. The user generally has to know some obscure CMAKE parameter, or regular make parameter for that matter, or they need to know how to use LD_FLAGS and PKG_CONFIG_DIR just to compile their software. On top of that, most of the SlackBuilds do not contain these fixes for a multilib environment.

Yes, most users only need run-time compatibility to run some closed-source 32-bit binaries (which don't yet come with 64-bit versions). How about just adding two scripts to extra: scripts like convertpkg-compat32 and massconvert32.sh but which also remove all *.a *.la *.o pkgconfig/*.pc files and *.so symbolic links (and executable files now ending to /usr/bin/32). Running those scripts against the 32-bit packages could build packages with separate names, e.g. *-runtimecompat32-*. Then the 32-bit libraries could not be seen at all when configuring and compiling normally (64-bit). No need to provide gcc to compile 32-bit, no need for multilib glibc (convertpkg from 32-bit glibc is enough).

There can still be some special cases where a full 32-bit compiling environment is needed (wine?), but only then the full compat32 support would need to be installed from alien's web site.

GoogleEarth? Adobe Acroread?

Okular is far nicer to use and read from than acroreader.

I think it might benefit Slackware to be multilib, and to have that option is fine. So I think that multilib should be available as /extra but not part of the installation option during initial setup. my

Make it an option on the installer, why not. If anything throw them in /extra.
Pretty simple either way.