On Fri, Mar 21, 2014 at 10:33:07PM -0700, Keith Lofstrom wrote:
> Indeed. By big, slow stuff I am indeed talking days on end. I've
> run programs that used both processors of a dual core CPU for over a
> week. Perhaps virtualbox can use two processors, too; otherwise I
> take a 2x performance hi
On Fri, 21 Mar 2014, Keith Lofstrom wrote:
> However, I do a lot of science/technical/medical work. These oddball
> programs do a particular task and there are not many alternatives. The
> author is usually a subject specialist rather than a programmer, with bits
> of contributed code, borrowed
On Fri, Mar 21, 2014 at 11:52 PM, Keith Lofstrom wrote:
> ... For the big, slow stuff, I'll have to keep tweaking C code, sigh.
On Sat, Mar 22, 2014 at 12:03:02AM -0500, chris (fool) mccraw wrote:
> ... If you run code for days on end, maybe this makes sense. if your runs
> are shorter, make
I meant to sound off earlier about many things in this thread, such as:
- not all dependencies are libraries ("need gnome >= 2.0 because its
settings manager is how you change the color scheme in program Z" or
"must have an MTA so that the disk-health-checker can notify you of
impending failures")
Keith wrote:
> ... The problem is, almost all recent third party not-in-
> the-standard-distro packages want later major revs of libraries
> with new features; I can't compile or run those because the
> dependencies collide.
On Fri, Mar 21, 2014 at 02:45:34PM -0700, Ali Corbin wrote:
> Are the pa
On 03/21/14 14:45, Ali Corbin wrote:
>>
>> I run a Red Hat Enterprise clone, Scientific Linux 6.5 . It is
>> stodgy (equivalent to Fedora 12, a 4 year old base kernel) - but
>> it will get security updates until 2023, supported by Fermilabs
>> even if Red Hat goes away (or worse, gets bought by La
>
> I run a Red Hat Enterprise clone, Scientific Linux 6.5 . It is
> stodgy (equivalent to Fedora 12, a 4 year old base kernel) - but
> it will get security updates until 2023, supported by Fermilabs
> even if Red Hat goes away (or worse, gets bought by Larry
> Ellison). The problem is, almost al
Yeah, it seems to me that running a VM for legacy incompatible stuff
is far easier.
I typically stay away from distros that are very task-specific. While
it's convenient and all to have a certain set of software installed
and configured by default, the folks managing those distros have very
limi
That seems like a great reason to run a virtual machine and sandbox a more
modern linux to run those specific apps.
On Thu, Mar 20, 2014 at 8:58 PM, Keith Lofstrom wrote:
> On Tue, Mar 18, 2014 at 04:43:53PM -0700, Tim wrote:
> > Your software distribution does you a grand service by managing th
On Tue, Mar 18, 2014 at 04:43:53PM -0700, Tim wrote:
> Your software distribution does you a grand service by managing this
> for you. Use a distro that does it right, buy into it and use their
> framework, and many of the headaches you describe become minor.
On Wed, Mar 19, 2014 at 08:31:38AM -0
On Tue, 18 Mar 2014, Wayne E. Van Loon Sr. wrote:
Most of you probably know this, but what you are talking about is
the difference between static and dynamic linking. When using static
linking, all the libraries needed by the program are inserted into
the executable code. Depending upon the en
Most of you probably know this, but what you are talking about is the
difference between static and dynamic linking. When using static
linking, all the libraries needed by the program are inserted into the
executable code. Depending upon the environment on the target machine,
statically linked
> The justification for dependencies in software packages is that
> they can be shared, saving RAM and disk space. But disks and
> RAM is growing very large, while not much is actually shared.
> Besides many instances of the same program sharing the runtime
> code, do programs really need to shar
day 'till forever.
Pleasantly,
Ronald Bynoe
From: plug-boun...@lists.pdxlinux.org [plug-boun...@lists.pdxlinux.org] on
behalf of Keith Lofstrom [kei...@gate.kl-ic.com]
Sent: Tuesday, March 18, 2014 4:26 PM
To: PLUG
Subject: [PLUG] Are dependences obsolete?
The justification for dependencies in software packages is that
they can be shared, saving RAM and disk space. But disks and
RAM is growing very large, while not much is actually shared.
Besides many instances of the same program sharing the runtime
code, do programs really need to share anything,
15 matches
Mail list logo