VectorLinux
April 16, 2014, 11:26:23 am *
Welcome, Guest. Please login or register.
Did you miss your activation email?

Login with username, password and session length
News: Visit our home page for VL info. To search the old message board go to http://vectorlinux.com/forum1. The first VL forum is temporarily offline until we can find a host for it. Thanks for your patience.
 
Now powered by KnowledgeDex.
   Home   Help Search Login Register  
Please support VectorLinux!
Pages: [1] 2
  Print  
Author Topic: VL64 x86 Repositories/Slapt  (Read 2178 times)
langobard
Member
*
Posts: 28



« on: January 08, 2014, 11:54:22 am »

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
Logged

“World domination is such an ugly phrase. I prefer to call it world optimisation.” - HPMOR
uelsk8s
Administrator
Vectorian
*****
Posts: 2503



« Reply #1 on: January 08, 2014, 12:09:44 pm »

you can run a 64bit kernel on VL32, maybe that will give you what you want?
Logged
langobard
Member
*
Posts: 28



« Reply #2 on: January 08, 2014, 12:41:43 pm »

Quote from: uelsk8s
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.
Logged

“World domination is such an ugly phrase. I prefer to call it world optimisation.” - HPMOR
bigpaws
Vectorian
****
Posts: 1831


« Reply #3 on: January 08, 2014, 03:38:31 pm »

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
Logged
langobard
Member
*
Posts: 28



« Reply #4 on: January 08, 2014, 04:07:22 pm »

Quote from: bigpaws
...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?
Logged

“World domination is such an ugly phrase. I prefer to call it world optimisation.” - HPMOR
uelsk8s
Administrator
Vectorian
*****
Posts: 2503



« Reply #5 on: January 09, 2014, 09:29:50 am »

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
Logged
langobard
Member
*
Posts: 28



« Reply #6 on: January 09, 2014, 09:40:48 am »

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?
Logged

“World domination is such an ugly phrase. I prefer to call it world optimisation.” - HPMOR
M0E-lnx
Administrator
Vectorian
*****
Posts: 3134



« Reply #7 on: January 09, 2014, 10:41:46 am »

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
Logged

langobard
Member
*
Posts: 28



« Reply #8 on: January 09, 2014, 11:05:29 am »

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!
Logged

“World domination is such an ugly phrase. I prefer to call it world optimisation.” - HPMOR
M0E-lnx
Administrator
Vectorian
*****
Posts: 3134



« Reply #9 on: January 09, 2014, 06:45:19 pm »

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
Logged

langobard
Member
*
Posts: 28



« Reply #10 on: January 09, 2014, 07:25:56 pm »

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.
Logged

“World domination is such an ugly phrase. I prefer to call it world optimisation.” - HPMOR
uelsk8s
Administrator
Vectorian
*****
Posts: 2503



« Reply #11 on: January 10, 2014, 11:12:24 am »

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.
Logged
langobard
Member
*
Posts: 28



« Reply #12 on: January 10, 2014, 02:28:15 pm »

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?
Logged

“World domination is such an ugly phrase. I prefer to call it world optimisation.” - HPMOR
uelsk8s
Administrator
Vectorian
*****
Posts: 2503



« Reply #13 on: January 11, 2014, 10:06:47 pm »

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.
Quote
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.

Logged
langobard
Member
*
Posts: 28



« Reply #14 on: January 12, 2014, 08:13:16 am »

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?
« Last Edit: January 12, 2014, 08:15:18 am by langobard » Logged

“World domination is such an ugly phrase. I prefer to call it world optimisation.” - HPMOR
Pages: [1] 2
  Print  
 
Jump to:  

Powered by MySQL Powered by PHP Powered by SMF 1.1.19 | SMF © 2013, Simple Machines Valid XHTML 1.0! Valid CSS!