Print

Please login or register.
1 Hour 1 Day 1 Week 1 Month Forever
Login with username, password and session length

[langobard]

I'm new, so I will ask the stupid question (and my searching through these forums hasn't already turned up an answer, I promise I tried to look first):

Is there now or is there planned-for a simplified (for the user) x86 alternate repository for the VL64 series?  The best solution to my problem (I want to run mostly x86 programs, but my box has 8GB of RAM and I am loathe to switch to the x86 version and lose half my investment) I have found so far is this.

What my wild, clueless imagination keeps wanting to make real is some sort of option to set up the x86 libraries and compiler suite to some mount point (\x86bin or something) and then a way to point slapt-get to the x86 repository and the \x86bin and to never interfere with the x64 stuff.

If this is even remotely possible, I am beyond willing to work on this problem with anyone more knowledgeable than me and to dedicate my contribution efforts towards this.  It would certainly (I think?) be valuable and useful for the VL64 line. 

I stumbled across this problem because I am lazy and would rather work really hard to figure something out and make it work and then do minimal work to maintain it after.

If this is a stupid, clueless question, please let me know - and let me know what I can/should be doing instead.

Thanks!

V/R

-Langobard

[uelsk8s]

you can run a 64bit kernel on VL32, maybe that will give you what you want?

[langobard]

you can run a 64bit kernel on VL32, maybe that will give you what you want?

Clarification question: Would that be a less-labor intensive solution with the same results (full RAM utilization/availability, both x86 and x64 programs)?

Clarification statement: I have no idea how to do that, nor precisely what it would mean, but I am willing to learn (and trying to dig up info) about it.

[bigpaws]

The reason for 32bit programs on a 64bit system is that the
program has not been updated to run as 64bit. The design
of multilib was to allow time for all programs to be designed
for 64 bit.

Personally all of my systems are 64 bit and use multilib for a
very few programs. Wine being one of them.

The problem that you may encounter using any multilib setup
is upgrading packages.

In fact you may not 32 bit at all. Depends on what programs you
need.

HTH

Bigpaws

[langobard]

...In fact you may not 32 bit at all. Depends on what programs you
need.

Yup, this has been my assumption.  I am going to need Wine for sure, I was gearing up to be lazy with (and learn to contribute to) PlayOnLinux for most of my holdover x86/Windows requirements.  Now that you mention it though, aside from Wine/POL, I am trying to determine what else I might want and/or need.  You've made me actually think about and revise my position - and look at the x64 repository a second time...

Conclusion: I do not need nearly as much x86 compatibility as I thought - in fact, outside of Wine/POL, I am looking at fewer than a handful of x86 programs for which I have probable (p>.5) use. This thread was useful for changing my position, but probably not of use to anyone else.

Thank you both for your time and responses.

Altered Position: I would like to contribute to VL64 packages/testing/etc.

Clarification Question: Is there a better way to institute multilib than this?

[uelsk8s]

VL is multilib ready.
you can run any 32bit VL program by installing it and copying any libs it needs into /usr/lib/
If you need to compile 32bit programs you will have to add the multilib compiler and glibc

[langobard]

uelsk8s:  Thank you.  I didn't know that (or misunderstood what I had read).  So, for example, if I wanted to install PlayOnLinux (which, iirc, is available in the x86 repo for VL7.0), I would download/install it and everything else it needs to /usr/lib/ ? Or did I misunderstand again, and that will cause errors?

[M0E-lnx]

Why not use a 32-bit lxc container inside your 64-bit OS ? should be able to do what you need there.  I do it very often for other reasons of cou ese, but I think the principle of containers would be helpful here

[langobard]

Why not use a 32-bit lxc container inside your 64-bit OS ?

Mostly because I am green enough not to have even known that was an option.  But if my research (doing it now) follows my guess, then this is basically what I wanted in the first place - a relatively simple way to run 32-bit apps/etc within my x64 machine without dual booting or something similar.  I am applying my google-fu to the information now, but it can't hurt to ask: Do you have any guides/walkthroughs/information for doing so?

Secondary Question: Would it be useful, do you folks think, to have such a documentation specifically for VL64?  Did my original idea (altered to be within an lxc) contain any value? This is partially/potentially ignorance that makes me ask - I don't know enough yet to know if this is superfluous to users in general.

Tertiary Question:  Is lxc worthwhile, for example, for running a game in WINE on VL64? Or are there limitations that would make this inefficient/inadvisable?

As always, thank you for your time and knowledge!

[M0E-lnx]

I have done a lot of work on that front, but I tend to fail at documenting stuff.  The good thing with lxc is that it is self-contained and will not mix the stuff from you 32 bit environment into your 64 bit.  The other good news is that you create the environment with a couple of commands. 

I don't know what version of vl you run, but you will definitely want 7.1 for this, because that's where I have done the work at and the process will be easier there because the platform is ready for it.  You can grab the latest beta I so and install it.

Re: your 2nd question... Documentation is always good and welcome.  I can show you how to do it and you can document it if you want.  When you are done you can contribute your findings with us.

Re: your 3rd question:
The biggest advantage to lxc is that you have next to no overhead at all for your virtualized environment.  So, your games should run good once setup properly.  Take that for what its worth.  I have not done any gaming, so we would have to do the research and break the ground there, but I do think its a viable option, if not your best available for vl.

You are welcome to come by our irc channel and discuss this.  I'm normally on from 8am to 4pm CST

Hth

[langobard]

Color me 100% interested in testing/documenting 32 bit lxc in VL64-7.1 as a simple, viable gaming option.

I am using and abusing roarde's time right now in IRC trying to get my drivers to play nice, and I will document the process afterwards.

[uelsk8s]

uelsk8s:  Thank you.  I didn't know that (or misunderstood what I had read).  So, for example, if I wanted to install PlayOnLinux (which, iirc, is available in the x86 repo for VL7.0), I would download/install it and everything else it needs to /usr/lib/ ? Or did I misunderstand again, and that will cause errors?

that is correct.
just download and run your 32bit app.
you will need to add any libs that it needs though.
if you want to run the same app in 32 and 64bit you will need to explode the 32bit pkg and copy the binaries somewhere that they won't overwrite the others.

[langobard]

just download and run your 32bit app.
you will need to add any libs that it needs though.
if you want to run the same app in 32 and 64bit you will need to explode the 32bit pkg and copy the binaries somewhere that they won't overwrite the others.

Clarification: If I wanted to run Some32BitApp, I would download it from wherever and (assuming I had the right libs/etc), I could run it as normal without breaking anything (unless it shares a name with a 64-bit app)?

Secondary Question:  That being the case, would it be possible/worthwhile to set up some list/repository of apps that do not have an x64 equivalent, but do exist in the 32bit repository for VL?

[uelsk8s]

Clarification: If I wanted to run Some32BitApp, I would download it from wherever and (assuming I had the right libs/etc), I could run it as normal without breaking anything (unless it shares a name with a 64-bit app)?

Yes.

Secondary Question:  That being the case, would it be possible/worthwhile to set up some list/repository of apps that do not have an x64 equivalent, but do exist in the 32bit repository for VL?

Yes.

[langobard]

Seems like a good project to start on (list first) then.  I will do so over the next week or so, digging up what I can.

Clarification: Do the 32-bit apps rely on 32-bit dependencies (in the case where SomeApp requires UsefulApp >=1.4 to be installed, and UsefulApp has both a 32 bit and 64 bit version both named UsefulApp) or can they use the 64-bit dependencies, or is it case-contextual?