On 2012-05-26 01:52, Peter Humphrey wrote:
> $ elogviewer --help
> File "/usr/local/bin/elogviewer", line 11
> """
> ^
> SyntaxError: invalid syntax
Huh? Mine (latest stable 0.5.2-r2, official Gentoo portage - not some
overlay) is installed in /usr/bin/...
Have you changed the instal
On Saturday 26 May 2012 09:36:50 pk wrote:
> On 2012-05-26 01:52, Peter Humphrey wrote:
> > $ elogviewer --help
> > File "/usr/local/bin/elogviewer", line 11
> > """
> > ^
> > SyntaxError: invalid syntax
>
> Huh? Mine (latest stable 0.5.2-r2, official Gentoo portage - not some
> overla
On 05/26/2012 10:34 AM, Peter Humphrey wrote:
> On Saturday 26 May 2012 09:36:50 pk wrote:
>> On 2012-05-26 01:52, Peter Humphrey wrote:
>>> $ elogviewer --help
>>> File "/usr/local/bin/elogviewer", line 11
>>> """
>>> ^
>>> SyntaxError: invalid syntax
>>
>> Huh? Mine (latest stable 0.5
on 2012-05-14 at 08:52 ny6...@gmail.com wrote:
>9. DO NOT TOP-POST and DO trim your replies!!!
why don't you observe these yourself? you quoted the whole message you
replied to, which itself contained another full quote, which itself...
many people here complain against top-posting, but few obs
I'm debating whether I should hire an expert programmer for $X/hour,
or a company of expert programmers for $2X/hour. It makes sense from
a financial perspective to hire programmers directly, but I wonder if
there are benefits to hiring a really good company.
I'm sorry this is OT, but I bet you g
on 2012-05-14 at 22:54 Alan McKinnon wrote:
> (getting old...)
you don't say, really? what a coincidence, it's happening to me too.
anyone else getting older around here? is anyone actually getting
*younger*?
Am 26.05.2012 13:26, schrieb Grant:
> I'm debating whether I should hire an expert programmer for $X/hour,
> or a company of expert programmers for $2X/hour. It makes sense from
> a financial perspective to hire programmers directly, but I wonder if
> there are benefits to hiring a really good com
On Saturday 26 May 2012 10:37:38 Markos Chandras wrote:
> Portage *never* installs anything in /usr/local.
Indeed so.
> My best bet is that you have been experimenting back in 2007 and
> probably copied the original file in /usr/local. Remove it and then
> emerge elogviewer again ;)
As I said b
On Sat, May 26, 2012 at 08:18:32AM -0300, luis jure wrote:
> on 2012-05-14 at 08:52 ny6...@gmail.com wrote:
>
> >9. DO NOT TOP-POST and DO trim your replies!!!
>
> why don't you observe these yourself? you quoted the whole message you
> replied to, which itself contained another full quote, whic
Hi,
after updating baselayout from 2.0.3 to 2.1-r1 /run is mounted
as tmpfs. But I can not find any mount-option for controlling
how much memory is (or could be) used for it.
Filesystem 1K-blocksUsed Available Use% Mounted on
tmpfs8223848 224 8223624 1% /run
I know i
Jarry wrote:
> Hi,
>
> after updating baselayout from 2.0.3 to 2.1-r1 /run is mounted
> as tmpfs. But I can not find any mount-option for controlling
> how much memory is (or could be) used for it.
>
> Filesystem 1K-blocksUsed Available Use% Mounted on
> tmpfs8223848 224
On 26-May-12 22:01, Dale wrote:
Jarry wrote:
after updating baselayout from 2.0.3 to 2.1-r1 /run is mounted
as tmpfs. But I can not find any mount-option for controlling
how much memory is (or could be) used for it.
Filesystem 1K-blocksUsed Available Use% Mounted on
tmpfs82
Jarry wrote:
> On 26-May-12 22:01, Dale wrote:
>> Jarry wrote:
>>>
>>> after updating baselayout from 2.0.3 to 2.1-r1 /run is mounted
>>> as tmpfs. But I can not find any mount-option for controlling
>>> how much memory is (or could be) used for it.
>>>
>>> Filesystem 1K-blocksUsed Availabl
On Sat, May 26, 2012 at 8:08 PM, Jarry wrote:
> On 26-May-12 22:01, Dale wrote:
>
>> Jarry wrote:
>>>
>>>
>>> after updating baselayout from 2.0.3 to 2.1-r1 /run is mounted
>>> as tmpfs. But I can not find any mount-option for controlling
>>> how much memory is (or could be) used for it.
>>>
>>> F
On Sat, 26 May 2012 22:08:48 +0200, Jarry wrote:
> I suppose default size for tmpfs is half of physical memory,
> if it is not configured somewhere else.
It is, but that is the default maximum size, a tmpfs filesystem uses
only as much memory as its contents require.
> BTW, is there any way to
On Sat, May 26, 2012 at 8:28 PM, Dale wrote:
[snip]
> I had no idea it was doing this either until your post. I got the same
> questions as you do. Why is it there?
tmpfs is frequently used in places where data doesn't need to persist
across reboots. /var/run meets this description, because i
Dale writes:
> Jarry wrote:
>> On 26-May-12 22:01, Dale wrote:
>>> Jarry wrote:
after updating baselayout from 2.0.3 to 2.1-r1 /run is mounted
as tmpfs. But I can not find any mount-option for controlling
how much memory is (or could be) used for it.
Filesystem 1K
Am 26.05.2012 22:28, schrieb Dale:
> Jarry wrote:
>> On 26-May-12 22:01, Dale wrote:
>>> Jarry wrote:
after updating baselayout from 2.0.3 to 2.1-r1 /run is mounted
as tmpfs. But I can not find any mount-option for controlling
how much memory is (or could be) used for it.
On Sat, May 26, 2012 at 9:02 PM, Michael Hampicke wrote:
[snip]
> As Michael Mol already said, tmpfs for the run dir is not a bad thing,
> it, it does not eat all your ram :)
> I however have a different question: Why do we need a new /run when we
> already have /var/run. There's no mention of /
On 26/05/12 22:46, Jarry wrote:
Hi,
after updating baselayout from 2.0.3 to 2.1-r1 /run is mounted
as tmpfs. But I can not find any mount-option for controlling
how much memory is (or could be) used for it.
Filesystem 1K-blocks Used Available Use% Mounted on
tmpfs 8223848 224 8223624 1% /run
I
Neil Bothwick wrote:
> On Sat, 26 May 2012 22:08:48 +0200, Jarry wrote:
>
>> I suppose default size for tmpfs is half of physical memory,
>> if it is not configured somewhere else.
>
> It is, but that is the default maximum size, a tmpfs filesystem uses
> only as much memory as its contents requi
On Sat, 26 May 2012 17:17:54 -0500, Dale wrote:
> > It makes sure that /run is available and writeable early in the boot
> > process, whereas /var/run may not be and / may be mounted ro.
> Mine wouldn't be since I have /var on a separate partition. I guess the
> devs are getting ready for the ul
On Sat, May 26, 2012 at 10:17 PM, Dale wrote:
> Neil Bothwick wrote:
>> On Sat, 26 May 2012 22:08:48 +0200, Jarry wrote:
>>
>>> I suppose default size for tmpfs is half of physical memory,
>>> if it is not configured somewhere else.
>>
>> It is, but that is the default maximum size, a tmpfs filesy
Neil Bothwick wrote:
> On Sat, 26 May 2012 17:17:54 -0500, Dale wrote:
>
>>> It makes sure that /run is available and writeable early in the boot
>>> process, whereas /var/run may not be and / may be mounted ro.
>
>> Mine wouldn't be since I have /var on a separate partition. I guess the
>> devs
On Sat, 26 May 2012 18:17:38 -0500
Dale wrote:
> It
> appears that /run is sort of a temp thing while booting and just sort
> of sticks around after getting booted, since it is there anyway. Why
> not use it?
No, that is incorrect.
/run is a deliberate design decision (and a damn good one that
On Sat, 26 May 2012 23:02:13 +0200
Michael Hampicke wrote:
>
>
> Am 26.05.2012 22:28, schrieb Dale:
> > Jarry wrote:
> >> On 26-May-12 22:01, Dale wrote:
> >>> Jarry wrote:
>
> after updating baselayout from 2.0.3 to 2.1-r1 /run is mounted
> as tmpfs. But I can not find any mount
Alan McKinnon wrote:
> On Sat, 26 May 2012 18:17:38 -0500
> Dale wrote:
>
>> It
>> appears that /run is sort of a temp thing while booting and just sort
>> of sticks around after getting booted, since it is there anyway. Why
>> not use it?
>
> No, that is incorrect.
>
> /run is a deliberate de
On May 27, 2012 7:19 AM, "Dale" wrote:
>
> Alan McKinnon wrote:
> > On Sat, 26 May 2012 18:17:38 -0500
> > Dale wrote:
> >
> >> It
> >> appears that /run is sort of a temp thing while booting and just sort
> >> of sticks around after getting booted, since it is there anyway. Why
> >> not use it?
Pandu Poluan wrote:
>
> On May 27, 2012 7:19 AM, "Dale" >
>> What I was saying tho, since it appears to be needed now, since /var may
>> not be mounted yet, it was created and is used during booting up. Since
>> it is there, why not use it, even AFTER the system is booted. After
>> all, the fil
On Sun, May 27, 2012 at 3:06 AM, Dale wrote:
> Pandu Poluan wrote:
>>
>> On May 27, 2012 7:19 AM, "Dale"
>>>
>>> What I was saying tho, since it appears to be needed now, since /var may
>>> not be mounted yet, it was created and is used during booting up. Since
>>> it is there, why not use it, e
Joshua Murphy wrote:
> Well, given that it's there, it cleans up after itself, and it avoids
> issues in the instance where /var isn't available early on, is there
> much reason _not_ to link /var/run and /var/lock over to their
> respective equivalents on /run? And both with and without /var moun
On Sun, May 27, 2012 at 4:51 AM, Dale wrote:
> Joshua Murphy wrote:
>
> Well, I don't see why not. As you say, lack of a proper clean up after
> a bad shutdown can cause problems. Anything in /run would disappear
> after a shutdown, clean or not, since it is in tmpfs. It doesn't seem
> to use
Joshua Murphy wrote:
> On Sun, May 27, 2012 at 4:51 AM, Dale wrote:
>> Joshua Murphy wrote:
>
>>
>> Well, I don't see why not. As you say, lack of a proper clean up after
>> a bad shutdown can cause problems. Anything in /run would disappear
>> after a shutdown, clean or not, since it is in tmp
On Sat, May 26, 2012 at 11:29 PM, Joshua Murphy wrote:
[ snip ]
> Well, given that it's there, it cleans up after itself, and it avoids
> issues in the instance where /var isn't available early on, is there
> much reason _not_ to link /var/run and /var/lock over to their
> respective equivalents o
>> I'm debating whether I should hire an expert programmer for $X/hour,
>> or a company of expert programmers for $2X/hour. It makes sense from
>> a financial perspective to hire programmers directly, but I wonder if
>> there are benefits to hiring a really good company.
>>
>> I'm sorry this is OT
On Sun, May 27, 2012 at 1:20 AM, Canek Peláez Valdés wrote:
> On Sat, May 26, 2012 at 11:29 PM, Joshua Murphy wrote:
> [ snip ]
>> Well, given that it's there, it cleans up after itself, and it avoids
>> issues in the instance where /var isn't available early on, is there
>> much reason _not_ to
36 matches
Mail list logo
