 |
|
|
|
|
|
| |
| |
|
|
|
|
| |
| |
|
|
>> One of the discussions suggests that the correct search term is "shell
>> host". This does indeed appear to generate a lot of hits...
>
> A shell host means that they give you a complete VM to yourself and you
> can do whatever you want
I thought the term for that was "virtual server"? (Or "dedicated server"
if the physical hardware is not shared - usually very expensive!)
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
On 19/07/2012 10:24 AM, Invisible wrote:
> Now, how much do you want to bet that a non-trivial program compiled on
> one Unix box won't run on another Unix box? :-/
A simple test confirms that this is indeed the case. Compile
HelloWorld.c on OpenSUSE and it works. Copy it to Debian and it
complains about lots of lib.so files not existing...
Apparently the solution is http://www.pgbovine.net/cde.html
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Le 2012-07-19 10:32, Invisible a écrit :
>>> One of the discussions suggests that the correct search term is "shell
>>> host". This does indeed appear to generate a lot of hits...
>>
>> A shell host means that they give you a complete VM to yourself and you
>> can do whatever you want
>
> I thought the term for that was "virtual server"? (Or "dedicated server"
> if the physical hardware is not shared - usually very expensive!)
Well you might have shell access on a shared server, but with the advent
of easier virtualization, it's easier to just give you a VM rather than
worrying about the security mightmares of having multiple users
installing software on the same machine.
--
/*Francois Labreque*/#local a=x+y;#local b=x+a;#local c=a+b;#macro P(F//
/* flabreque */L)polygon{5,F,F+z,L+z,L,F pigment{rgb 9}}#end union
/* @ */{P(0,a)P(a,b)P(b,c)P(2*a,2*b)P(2*b,b+c)P(b+c,<2,3>)
/* gmail.com */}camera{orthographic location<6,1.25,-6>look_at a }
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
On Thu, 19 Jul 2012 08:56:56 +0100, Invisible wrote:
>>> Most of the discussions appear to be /very/ old.
>>
>> It's an example of how to do a search. Use the search tools to
>> constrain the results to a more recent timeframe.
>
> One of the discussions suggests that the correct search term is "shell
> host". This does indeed appear to generate a lot of hits...
*That's* how searching on Google is accomplished. Learning is an
iterative process - sometimes finding the right search combinations are a
learning process. :)
Jim
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
On Thu, 19 Jul 2012 09:50:29 +0100, Invisible wrote:
> So perhaps I should try compiling a 32-bit ELF binary and see if that
> works? (Man, is there even a way to do that with a 64-bit Linux distro?
> I'm sure there is, but finding it...)
Yes, x64 Linux systems can run ia32 ELF binaries if the library
dependencies are met using 32-bit libraries.
Jim
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
On Thu, 19 Jul 2012 10:24:00 +0100, Invisible wrote:
> Now, how much do you want to bet that a non-trivial program compiled on
> one Unix box won't run on another Unix box? :-/
If the library requirements are met, it'll run.
If they aren't, then it won't.
Jim
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
>> Now, how much do you want to bet that a non-trivial program compiled on
>> one Unix box won't run on another Unix box? :-/
>
> If the library requirements are met, it'll run.
>
> If they aren't, then it won't.
Trouble is, a typical Haskell program compiled with GHC has a vast list
of dependencies. (Off the top of my head, GMP, ncurses, libffi...)
Without shell access, it's going to be fun trying to fake that lot.
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
On Thu, 19 Jul 2012 17:18:37 +0100, Orchid Win7 v1 wrote:
>>> Now, how much do you want to bet that a non-trivial program compiled
>>> on one Unix box won't run on another Unix box? :-/
>>
>> If the library requirements are met, it'll run.
>>
>> If they aren't, then it won't.
>
> Trouble is, a typical Haskell program compiled with GHC has a vast list
> of dependencies. (Off the top of my head, GMP, ncurses, libffi...)
>
> Without shell access, it's going to be fun trying to fake that lot.
Doesn't ghc provide a static linking option?
Jim
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
On Thu, 19 Jul 2012 10:20:06 +0100, Invisible wrote:
> Interestingly, the documentation claims that all CGI scripts must begin
> with a shebang and must have execute permissions. For at least PHP, this
> is clearly untrue...
That's because with apache, php is something it knows about with mod_php*,
so it calls scripts with the php* extensions with the php processor.
But php script does accept a #!/path/to/executable at the start as well,
and if the path is right and the script is executable, it'll work as Perl
or any other scripted *nix language.
Jim
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
>>>> Now, how much do you want to bet that a non-trivial program compiled
>>>> on one Unix box won't run on another Unix box? :-/
>>>
>>> If the library requirements are met, it'll run.
>>>
>>> If they aren't, then it won't.
>>
>> Trouble is, a typical Haskell program compiled with GHC has a vast list
>> of dependencies. (Off the top of my head, GMP, ncurses, libffi...)
>>
>> Without shell access, it's going to be fun trying to fake that lot.
>
> Doesn't ghc provide a static linking option?
By default, GHC statically links all *Haskell* libraries. However, it
usually does not statically link *external* libraries, as far as I can
tell. Perhaps there's a switch somewhere to make it do that...
(And then, of course, we get into the fun of deciding which libraries
should or should not be statically linked. E.g., apparently statically
linking glibc is a bad idea.)
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
