date:20120822

On Wed, 22 Aug 2012 12:59:13 +0200
Andy Wodfer wrote:

 Hi,
 I have about 500MB in my /tmp and it seems to be too small when the
 periodic LOCATE script runs every week.
 
 What's the best way to increase the size of /tmp ? Could I simply
 remove it and create a symbolic link ln -s to say /usr/tmp instead
 (where I have several hundred GBs free)?
 


Either that or you could use tmpfs. You could also change the locate
tmp directory in /etc/locate.rc.


There's also a periodic script to remove older files from /tmp which
may help.
___
freebsd-questions@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-questions
To unsubscribe, send any mail to freebsd-questions-unsubscr...@freebsd.org

Re: Warning - FreeBSD (*BSD) entanglement in Linux ecosystem

2012-08-22 Thread CyberLeo Kitsana

On 08/21/2012 09:04 PM, David Jackson wrote:
 In reference to the claims that systemd developers do not care about
 portability, this is deceptive and misleading. It implies that he is
 building in a dependance on intractable hardware platform dependance when
 this is absolutely not the case, there is no dependance on a hardware
 platform.There is nothing about systemd that FreeBSD could not easily
 support. Yes, his software does use system call facilities provided by
 Linux, but since this is a dependance on software systems, FreeBSD could
 easily add these facilities to its own libraries and kernel. This fact
 exposes what the complaints from some people are about, it has nothing to
 do with portability, because these issues can be easily addressed in
 software code by FreeBSD, it has to do with FreeBSD not wanting to
 implement equivalent functionality as  Linux.
 
 The fact is, FreeBSD can fully support systemd and all kernel and system
 features, there is nothing here that is impossible for FreeBSD to support.
 
 By doing so, it would give users MORE freedom rather than less freedom.
 FreeBSD would not even be required to use systemd for its own bootup
 sequence, which can be BSD init scripts still, but, systemd could be made
 available on FreeBSD, called from FreeBSDs init scripts, for users that
 wants to use it.
 
 Some here would make it seem like it is impossible for FreeBSD to support
 systemd, nothing could be further from the truth. No one is stopping
 FreeBSD from implementing it or any other feature found in Linux.
 
 I carefully looked through the documentation of systemd, I could see
 nothing except for a well designed, powerful and flexible start up system
 that is a major improvement. It IS backwards compatable with SysV and init
 scripts, so, no one can say they are taking away someones capability to use
 their own init scripts. BSD could continue to use its own startup init
 system and optionally allow systemd to be called from this for software
 that needs systemd. So, FreeBSD does not even have to change much about its
 current init system to support systemd. systemd could be called from
 FreeBSDs current init scripts as an addon rather than needing to replace
 any of the existing init system.
 
 I basically cannot see a rational reason to not support it.

If I were to hazard a guess, it's because systemd is intended to replace
a subsystem which is simple and has had decades of testing with
something that is as yet largely unproven. If not done properly, and
with competent oversight, it could result in an unmaintainable system
that requires more than just a text editor to repair. Just imagine
losing a library against which systemd is compiled: no single-user mode
because 'init' couldn't start at all now, and no /bin/sh because the
startup scripts required to get the machine into a usable state are no
longer written in bourne shell.

But the larger issue, in my analysis, is that it forces feature creep
into any other posix implementation that must support it to run software
that depends upon it. FreeBSD has a jail implementation that is far more
advanced and secure than anything Linux currently offers; yet systemd
requires what basically amounts to a neutered version (containers) so
that it can keep track of processes. Not a dishonourable endeavour in
and of itself, but then it's like GEM/KMS all over again, where smaller,
more resource-constrained teams are rushing to add otherwise-unneeded
features to their kernels in such a way that won't cause instability or
security vulnerabilities. In this case, there isn't even any
compatibly-licensed reference code for containers that can be freely
used; the implementation must be engineered from scratch.

Lastly, it's also LGPL-licensed; either someone will have to convince
the authors to dual-license it, or a BSD-licensed implementation will
have to be written. With the current FreeBSD GPL-exodus, I don't see the
adoption of further GPL/LGPL code having much chance of succeeding;
especially when said code is required to actually bootstrap the userland.

Personally, I think diversity is good, and systemd does offer alternate
options that were previously lacking in a sysvinit/bsdinit world; but
systemd could be a lot more flexible in supporting platforms that are
other than Linux or GPL.

-- 
Fuzzy love,
-CyberLeo
Technical Administrator
CyberLeo.Net Webhosting
http://www.CyberLeo.Net
cyber...@cyberleo.net

Furry Peace! - http://.fur.com/peace/
___
freebsd-questions@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-questions
To unsubscribe, send any mail to freebsd-questions-unsubscr...@freebsd.org

Re: /tmp filesystem full

2012-08-22 Thread Robert Huff


RW writes:

   I have about 500MB in my /tmp and it seems to be too small when the
   periodic LOCATE script runs every week.
  
  There's also a periodic script to remove older files from /tmp which
  may help.

My gut reaction is: what's taking up so much room?
My /tmp contains 6 mbytes.  Even back when it was sharing space
on a 500 mbyte /, it only filled up on the rare occasions when something
went Horribly Wrong(tm) with a large compilation or backup.
To the OP:
See what you can delete.
Then figure out what's filling it up.

Respoectfully,


Robert Huff

___
freebsd-questions@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-questions
To unsubscribe, send any mail to freebsd-questions-unsubscr...@freebsd.org

Re: /tmp filesystem full

2012-08-22 Thread Matthias Apitz

El día Wednesday, August 22, 2012 a las 12:59:13PM +0200, Andy Wodfer escribió:

 Hi,
 I have about 500MB in my /tmp and it seems to be too small when the
 periodic LOCATE script runs every week.
 
 What's the best way to increase the size of /tmp ? Could I simply remove it
 and create a symbolic link ln -s to say /usr/tmp instead (where I have
 several hundred GBs free)?
 
 PS! This is on a live server and I would like to keep downtime and problems
 to a minimum. :-)

Hi,

See the script /usr/sbin/periodic, it supports TMPDIR env var and you
could direct this to some place with more space;

HIH

matthias

-- 
Matthias Apitz
e g...@unixarea.de - w http://www.unixarea.de/
UNIX since V7 on PDP-11, UNIX on mainframe since ESER 1055 (IBM /370)
UNIX on x86 since SVR4.2 UnixWare 2.1.2, FreeBSD since 2.2.5
___
freebsd-questions@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-questions
To unsubscribe, send any mail to freebsd-questions-unsubscr...@freebsd.org

Re: Warning - FreeBSD (*BSD) entanglement in Linux ecosystem

2012-08-22 Thread Jerry

On Wed, 22 Aug 2012 12:29:56 +0200
Michel Talon articulated:

 David Jackson said:
 
  In reference to the claims that systemd developers do not care
  about portability, this is deceptive and misleading.
 
 You should read the following interview of Lennart Poettering
 http://linuxfr.org/nodes/86687/comments/1249943
 The amount of hubris and self confidence he deploys is really
 astounding. I will just quote two extracts:
 
  LinuxFr.org : Systemd use a lot of Linux only technologies (cgroups,
 udev, fanotify, timerfd, signalfd, etc). Do you really think the Linux
 API has been taking the role of the POSIX API and the other systems
 are irrelevant ?
 
 Lennart : Yes, I don't think BSD is really too relevant anymore, and I
 think that this implied requirement for compatibility with those
 systems when somebody hacks software for the free desktop or
 ecosystem is a burden, and holds us back for little benefit.  
 
 and cherry on the cake
 
 LinuxFr.org : Why Linux desktop hasn't been adopted by the
 mainstream users ? Linus Torvalds seems to think it's mostly a social
 issue and not a technical one. Do you agree with him ?
 
 Lennart : I think we weren't innovative enough in the interface, and
 we didn't have a convincing message and clear platform. If you accept
 MacOS as benchmark for user interfaces, then we weren't really
 matching it, at best copying it. I think this is changing now, with
 GNOME 3 which is a big step forward as an interface for Linux and for
 the first time is something that has been strictly designed under UI
 design guidelines. 

The critics complain that the new ideas merely introduces de minimis
modifications and does nothing to amend the real faults in the system.
The real problem is that true innovative development in FreeBSD has
become stagnant. It has taken, and in some cases still not achieved
equal standings with other OSs in many areas. Wireless technology, full
USB support to name a few. It is ALWAYS easier to blame others for our
failures than to admit the problem lies within ourselves. Thank God
that everyone is not the complacent. Where would civilization be now if
Edison had considered the candle the ultimate technological advancement
in portable lighting or if Bell had considered the telegraph the
pinnacle of high speed communication. Change is hard -- it always has
been. There exists a strong subculture that would rather curse the
darkness then light a candle. Debating with them is a waste of time.

You should never argue with idiots because they will just drag you down
to their levelthen beat you with experience. Simple ignore them and
when time has passed them by and proven you right, you can smile
knowing that you were. The frontiers are littered with dinosaurs. You
could also enjoy a great day of golf which beats the hell out of
arguing with those married to the past.

-- 
Jerry ♔

Disclaimer: off-list followups get on-list replies or get ignored.
Please do not ignore the Reply-To header.
__

___
freebsd-questions@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-questions
To unsubscribe, send any mail to freebsd-questions-unsubscr...@freebsd.org

Re: /tmp filesystem full

2012-08-22 Thread Andy Wodfer

Thanks to all for your input!

Editing /etc/periodic.rc seem to do the trick, but now I faced a different
problem which I've never seen before:

locate: integer out of +-MAXPATHLEN (1024): 1029


There are some directories that contains A LOT of small files I think. Need
to investigate.

Also thanks for the tip on omitting parts of the filesystem. Perhaps I need
to do that.

/Andreas


On Wed, Aug 22, 2012 at 1:56 PM, Michael Ross g...@ross.cx wrote:

 On Wed, 22 Aug 2012 12:59:13 +0200, Andy Wodfer wod...@gmail.com wrote:

  Hi,
 I have about 500MB in my /tmp and it seems to be too small when the
 periodic LOCATE script runs every week.

 What's the best way to increase the size of /tmp ? Could I simply remove
 it
 and create a symbolic link ln -s to say /usr/tmp instead (where I have
 several hundred GBs free)?

 PS! This is on a live server and I would like to keep downtime and
 problems
 to a minimum. :-)

 Cheers,
 Andy


 If it's just locate.updatedb filling it up temporarily,
 perhaps you can solve this by ommitting part of your filesystem from the
 locate index.

 See /etc/locate.rc


 Regards,

 Michael

___
freebsd-questions@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-questions
To unsubscribe, send any mail to freebsd-questions-unsubscr...@freebsd.org

Re: /tmp filesystem full

2012-08-22 Thread Andy Wodfer

How can I find which directories break the MAXPATHLEN variable?

or can I somehow run the periodic script in verbose mode to see the output?

/Andy

On Wed, Aug 22, 2012 at 2:04 PM, Andy Wodfer wod...@gmail.com wrote:

 Thanks to all for your input!

 Editing /etc/periodic.rc seem to do the trick, but now I faced a different
 problem which I've never seen before:

 locate: integer out of +-MAXPATHLEN (1024): 1029


 There are some directories that contains A LOT of small files I think.
 Need to investigate.

 Also thanks for the tip on omitting parts of the filesystem. Perhaps I
 need to do that.

 /Andy



 On Wed, Aug 22, 2012 at 1:56 PM, Michael Ross g...@ross.cx wrote:

 On Wed, 22 Aug 2012 12:59:13 +0200, Andy Wodfer wod...@gmail.com wrote:

  Hi,
 I have about 500MB in my /tmp and it seems to be too small when the
 periodic LOCATE script runs every week.

 What's the best way to increase the size of /tmp ? Could I simply remove
 it
 and create a symbolic link ln -s to say /usr/tmp instead (where I have
 several hundred GBs free)?

 PS! This is on a live server and I would like to keep downtime and
 problems
 to a minimum. :-)

 Cheers,
 Andy


 If it's just locate.updatedb filling it up temporarily,
 perhaps you can solve this by ommitting part of your filesystem from the
 locate index.

 See /etc/locate.rc


 Regards,

 Michael



___
freebsd-questions@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-questions
To unsubscribe, send any mail to freebsd-questions-unsubscr...@freebsd.org

Re: /tmp filesystem full

2012-08-22 Thread Jerome Herman


Le 22/08/2012 12:59, Andy Wodfer a écrit :

Hi,
I have about 500MB in my /tmp and it seems to be too small when the
periodic LOCATE script runs every week.

What's the best way to increase the size of /tmp ? Could I simply remove it
and create a symbolic link ln -s to say /usr/tmp instead (where I have
several hundred GBs free)?

PS! This is on a live server and I would like to keep downtime and problems
to a minimum. :-)

Cheers,
Andy
___
freebsd-questions@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-questions
To unsubscribe, send any mail to freebsd-questions-unsubscr...@freebsd.org


Removing /tmp and replacing it with a link is a bad idea, it might have 
unexpected effects if you have to go into single user mode for 
maintenance - especially if /usr cannot be mounted at that time. A 
solution would be to create a /usr/tmp BEFORE mounting /usr


If the problem comes from locate, the best option is to move locate 
database and temp files on another drive - take a look at locate.rc for 
information - this should cause 0 downtime.


If the problem is that the tmp file is really too small for a number of 
operation including locate (for example compile also fails due to lack 
of space) you will need to either configure each and every failing 
program to use a different temp directory or move temp directory


___
freebsd-questions@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-questions
To unsubscribe, send any mail to freebsd-questions-unsubscr...@freebsd.org

Re: /tmp filesystem full

2012-08-22 Thread Michael Ross


On Wed, 22 Aug 2012 12:59:13 +0200, Andy Wodfer wod...@gmail.com wrote:


Hi,
I have about 500MB in my /tmp and it seems to be too small when the
periodic LOCATE script runs every week.

What's the best way to increase the size of /tmp ? Could I simply remove  
it

and create a symbolic link ln -s to say /usr/tmp instead (where I have
several hundred GBs free)?

PS! This is on a live server and I would like to keep downtime and  
problems

to a minimum. :-)

Cheers,
Andy


If it's just locate.updatedb filling it up temporarily,
perhaps you can solve this by ommitting part of your filesystem from the  
locate index.


See /etc/locate.rc


Regards,

Michael
___
freebsd-questions@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-questions
To unsubscribe, send any mail to freebsd-questions-unsubscr...@freebsd.org

Re: Warning - FreeBSD (*BSD) entanglement in Linux ecosystem

2012-08-22 Thread Jerome Herman


Le 22/08/2012 13:59, Jerry a écrit :

On Wed, 22 Aug 2012 12:29:56 +0200
Michel Talon articulated:


David Jackson said:


In reference to the claims that systemd developers do not care
about portability, this is deceptive and misleading.

You should read the following interview of Lennart Poettering
http://linuxfr.org/nodes/86687/comments/1249943
The amount of hubris and self confidence he deploys is really
astounding. I will just quote two extracts:

 LinuxFr.org : Systemd use a lot of Linux only technologies (cgroups,
udev, fanotify, timerfd, signalfd, etc). Do you really think the Linux
API has been taking the role of the POSIX API and the other systems
are irrelevant ?

Lennart : Yes, I don't think BSD is really too relevant anymore, and I
think that this implied requirement for compatibility with those
systems when somebody hacks software for the free desktop or
ecosystem is a burden, and holds us back for little benefit.  

and cherry on the cake

LinuxFr.org : Why Linux desktop hasn't been adopted by the
mainstream users ? Linus Torvalds seems to think it's mostly a social
issue and not a technical one. Do you agree with him ?

Lennart : I think we weren't innovative enough in the interface, and
we didn't have a convincing message and clear platform. If you accept
MacOS as benchmark for user interfaces, then we weren't really
matching it, at best copying it. I think this is changing now, with
GNOME 3 which is a big step forward as an interface for Linux and for
the first time is something that has been strictly designed under UI
design guidelines. 

The critics complain that the new ideas merely introduces de minimis
modifications and does nothing to amend the real faults in the system.
The real problem is that true innovative development in FreeBSD has
become stagnant. It has taken, and in some cases still not achieved
equal standings with other OSs in many areas. Wireless technology, full
USB support to name a few. It is ALWAYS easier to blame others for our
failures than to admit the problem lies within ourselves.
I would not call FreeBSD approach a failure, from my point of view it is 
definitely a choice. FreeBSD is all about the Least Astonishment. Sure 
it results in new technologies and paradigm making their way into the OS 
really slowly (though in the case of both wifi and USB (and ACPI by the 
way) most of the problem still lies in incomplete specs and dubious 
standard compliance from manufacturers).


But on the other hand it also results in a system that is extremely 
coherent with himself and extremely stable over time. Almost every 
script I wrote under FreeBSD 4.x still work flawlessly in 9.1.


In fact most *BSD contributors, write code for their needs - they 
improve FreeBSD because they need the new stuff, not because they have 
an agenda or a product to sell. Of course non vital improvement 
(graphics, sounds, 3D etc.) takes longer to be implemented. But I 
personally prefer an ugly frontend with a robust motor under the hood 
than the contrary.



  Thank God
that everyone is not the complacent. Where would civilization be now if
Edison had considered the candle the ultimate technological advancement
in portable lighting or if Bell had considered the telegraph the
pinnacle of high speed communication. Change is hard -- it always has
been. There exists a strong subculture that would rather curse the
darkness then light a candle. Debating with them is a waste of time.

You should never argue with idiots because they will just drag you down
to their levelthen beat you with experience. Simple ignore them and
when time has passed them by and proven you right, you can smile
knowing that you were. The frontiers are littered with dinosaurs. You
could also enjoy a great day of golf which beats the hell out of
arguing with those married to the past.



___
freebsd-questions@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-questions
To unsubscribe, send any mail to freebsd-questions-unsubscr...@freebsd.org

Re: /tmp filesystem full

2012-08-22 Thread Robert Bonomi

 From owner-freebsd-questi...@freebsd.org  Wed Aug 22 05:59:52 2012
 Date: Wed, 22 Aug 2012 12:59:13 +0200
 From: Andy Wodfer wod...@gmail.com
 To: freebsd-questions freebsd-questions@freebsd.org
 Subject: /tmp filesystem full

 Hi,
 I have about 500MB in my /tmp and it seems to be too small when the
 periodic LOCATE script runs every week.

 What's the best way to increase the size of /tmp ? Could I simply remove it
 and create a symbolic link ln -s to say /usr/tmp instead (where I have
 several hundred GBs free)?

That is a BAD IDEA(tm)!

There are appliations that assume /tmp, /var/tmp, and /usr/tmp are _distinct_
directories.  They will create files _with_the_same_name_ in two of those
'temp' locations, expecting them to be unique.o

It _is_ OK to symlink /tmp to 'somewhere else', with the caveat that it
should be on the '/' filesystem -- one may need it in single-user mode
befoe other filesystems are mounted.  You can 'live dangerously' and 
symlink to a dir on a different filesystem and _probably_ not have 
problems.

___
freebsd-questions@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-questions
To unsubscribe, send any mail to freebsd-questions-unsubscr...@freebsd.org

Re: /tmp filesystem full

On Wed, 22 Aug 2012 14:12:25 +0200, Andy Wodfer wrote:
 How can I find which directories break the MAXPATHLEN variable?

It's easy to do this with find and awk:

% find / -type d | awk 'length  LIMIT'

where LIMIT is the numerical value you want to be exceeded (in
your case, MAXPATHLEN). You can add  /tmp/longpaths.txt to
obtain a list file for further reference.



 or can I somehow run the periodic script in verbose mode to see the output?

You could manually run it. Note that it's output is tailored
to generate mail messages about success or failure which is
then mailed to the system administrator.

See /etc/defaults/periodic.conf for various *_verbose variables
to make the scripts themselves be more verbose. But I only can
see those:

daily_clean_tmps_verbose=YES  # Mention files deleted
daily_clean_preserve_verbose=YES  # Mention files deleted
daily_clean_rwho_verbose=YES  # Mention files deleted

You could however (temporarily) add your own debugging statements
to the script in question.



-- 
Polytropon
Magdeburg, Germany
Happy FreeBSD user since 4.0
Andra moi ennepe, Mousa, ...
___
freebsd-questions@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-questions
To unsubscribe, send any mail to freebsd-questions-unsubscr...@freebsd.org

Re: /tmp filesystem full

2012-08-22 Thread Steve O'Hara-Smith

On Wed, 22 Aug 2012 08:14:35 -0500 (CDT)
Robert Bonomi bon...@mail.r-bonomi.com wrote:

  From owner-freebsd-questi...@freebsd.org  Wed Aug 22 05:59:52 2012
  Date: Wed, 22 Aug 2012 12:59:13 +0200
  From: Andy Wodfer wod...@gmail.com
  To: freebsd-questions freebsd-questions@freebsd.org
  Subject: /tmp filesystem full

  Hi,
  I have about 500MB in my /tmp and it seems to be too small when the
  periodic LOCATE script runs every week.

  What's the best way to increase the size of /tmp ? Could I simply
  remove it and create a symbolic link ln -s to say /usr/tmp instead
  (where I have several hundred GBs free)?

 That is a BAD IDEA(tm)!

 There are appliations that assume /tmp, /var/tmp, and /usr/tmp are
 _distinct_ directories.  They will create files _with_the_same_name_ in
 two of those 'temp' locations, expecting them to be unique.o

/usr/tmp usually does not exist so creating it and
symlinking /tmp to it is OK.

 It _is_ OK to symlink /tmp to 'somewhere else', with the caveat that it
 should be on the '/' filesystem -- one may need it in single-user mode
 befoe other filesystems are mounted.  You can 'live dangerously' and 
 symlink to a dir on a different filesystem and _probably_ not have 
 problems.

A null mount would be a safer way of pushing /tmp onto /usr or
indeed any other filesystem - that way when the null mount fails the mount
point is still a directory. There's really no point in linking it elsewhere
on the same filesystem.

-- 
Steve O'Hara-Smith  |   Directable Mirror Arrays
C:WIN  | A better way to focus the sun
The computer obeys and wins.|licences available see
You lose and Bill collects. |http://www.sohara.org/
___
freebsd-questions@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-questions
To unsubscribe, send any mail to freebsd-questions-unsubscr...@freebsd.org

Re: Warning - FreeBSD (*BSD) entanglement in Linux ecosystem

2012-08-22 Thread David Jackson

On Wed, Aug 22, 2012 at 7:03 AM, Jamie Paul Griffin ja...@kode5.net wrote:

 [ Michel Talon wrote on Wed 22.Aug'12 at 12:29:56 +0200 ]

 
  David Jackson said:

   In reference to the claims that systemd developers do not care about
   portability, this is deceptive and misleading.

  You should read the following interview of Lennart Poettering
  http://linuxfr.org/nodes/86687/comments/1249943
  The amount of hubris and self confidence he deploys is really
  astounding. I will just quote two extracts:

   LinuxFr.org : Systemd use a lot of Linux only technologies (cgroups,
  udev, fanotify, timerfd, signalfd, etc). Do you really think the Linux
  API has been taking the role of the POSIX API and the other systems are
  irrelevant ?

  Lennart : Yes, I don't think BSD is really too relevant anymore, and I
  think that this implied requirement for compatibility with those systems
  when somebody hacks software for the free desktop or ecosystem is a
  burden, and holds us back for little benefit.  




That sort of shows my point in fact. There is nothing stopping FreeBSD from
implementing cgroups,  udev, fanotify, timerfd, signalfd, its not like
Linux is going to enforce patents on these things, its software, and
freebsd can easily add code to support these things, and as well, systemd.
You are acting like there is dependancy in systemd on some hardware device
you cannot change, this is not true, Software is flexible and can be easily
extended and improved, they use some software features provided by the OS,
and you clearly can install these features into FreeBSD if you would care
to do so. FreeBSD can implement all of the software interfaces to make
systemd and other software portable to FreeBSD.

So this is clearly not about portability, FreeBSD is free to implement
these software interfaces to assure that software is portable to FreeBSD.
What this is about is FreeBSDs refusal to implement equivalent
functionality as Linux has. On this, FreeBSD has only itself to blame if it
refuses to do so, since FreeBSD clearly has the capability to easily add
the code necessary.

Clearly this is all FreeBSDs politics. It refuses to implement the features
because Linux developed because of the animosity towards Linux. FreeBSD has
a not made here syndrome.

FreeBSD would rather criticize other OSs that are trying to improve their
features and flexibility, and power, rather than to improve itself.

As for FreeBSDs market share, it is vanishingly small on the desktop with
far less uptake than Linux. It is also shrinking in the server area, there
is increasingly little reason to use an OS that has worse hardware support,
less functionality. Linux is just as reliable as FreeBSD and has more
functionality by far.

I have been a supporter of FreeBSD for some time, but it was becoming clear
that Linux distributions can offer much more and are just as reliable, in
addition to offering more capabilities, power and features. all of this has
left little reason to keep using FreeBSD. Why use an OS that has less
features and capabilities when there are more powerful alternatives with
more capabilities that are just as reliable, available?




 This guy seems to be a real moron. What a ridiculous statement to make.
 ___
 freebsd-questions@freebsd.org mailing list
 http://lists.freebsd.org/mailman/listinfo/freebsd-questions
 To unsubscribe, send any mail to 
 freebsd-questions-unsubscr...@freebsd.org

___
freebsd-questions@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-questions
To unsubscribe, send any mail to freebsd-questions-unsubscr...@freebsd.org

Re: /tmp filesystem full

2012-08-22 Thread John Hein

Andy Wodfer wrote at 12:59 +0200 on Aug 22, 2012:
  Hi,
  I have about 500MB in my /tmp and it seems to be too small when the
  periodic LOCATE script runs every week.
 
  What's the best way to increase the size of /tmp ? Could I simply remove it
  and create a symbolic link ln -s to say /usr/tmp instead (where I have
  several hundred GBs free)?
 
  PS! This is on a live server and I would like to keep downtime and
  problems to a minimum. :-)

One way is to work around your problem is to add
'TMPDIR=/path/to/bigger/filesystem' in /etc/crontab
and/or 'export TMPDIR=/path/...' in /etc/periodic.conf.
No downtime for that.

But yes, you can make /tmp a sym link.  You may have to worry about
edge cases regarding booting (like if the filesystem you point to is
not available early enough at boot time).  In the typical case (e.g.,
locally mounted ufs), it should work fine.  There may be very rare
cases of software that gets confused by a sym link for /tmp, but
certainly the stock periodic scripts should work with it.

Depending on what processes have files open on /tmp, you may decide to
use some down time to make the sym link.  You can't use mv(1) to
rename a mounted mount point.  If you can umount /tmp, then you can
rename it and make the sym link.  But it's possible some processes
have files open in /tmp preventing a normal umount (see lsof(8),
fstat(1)).  You would have to convince those processes to close the
/tmp file descriptors.

___
freebsd-questions@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-questions
To unsubscribe, send any mail to freebsd-questions-unsubscr...@freebsd.org

Re: Warning - FreeBSD (*BSD) entanglement in Linux ecosystem

On Wed, 22 Aug 2012 09:41:05 -0400, David Jackson wrote:
On Wed, Aug 22, 2012 at 7:03 AM, Jamie Paul Griffin ja...@kode5.net wrote:

[ Michel Talon wrote on Wed 22.Aug'12 at 12:29:56 +0200 ]

David Jackson said:

In reference to the claims that systemd developers do not care about
portability, this is deceptive and misleading.

You should read the following interview of Lennart Poettering
http://linuxfr.org/nodes/86687/comments/1249943
The amount of hubris and self confidence he deploys is really
astounding. I will just quote two extracts:

LinuxFr.org : Systemd use a lot of Linux only technologies (cgroups,
udev, fanotify, timerfd, signalfd, etc). Do you really think the Linux
API has been taking the role of the POSIX API and the other systems are
irrelevant ?

Lennart : Yes, I don't think BSD is really too relevant anymore, and I
think that this implied requirement for compatibility with those systems
when somebody hacks software for the free desktop or ecosystem is a
burden, and holds us back for little benefit.

That sort of shows my point in fact. There is nothing stopping FreeBSD from
implementing cgroups, udev, fanotify, timerfd, signalfd, its not like
Linux is going to enforce patents on these things, its software, and
freebsd can easily add code to support these things, and as well, systemd.

A problem might be that the Linux world is constantly changing.
Do you remember the HAL and DBUS problems? When FreeBSD had
implemented it, it has been abolished in Linux. There are of
course Linux-oriented software solutions that heavily rely
on Linux-specific things to fully function. Xfce is an example.
In case FreeBSD doesn't offer low level functionality like
kernel interfaces or library calls that are addressed by that
software on Linux, it will make that software unusable (or at
least limited in function) on FreeBSD. Assuming that more and
more software _will_ be primarily developed ON and FOR Linux,
it implies that FreeBSD will soon be out of that software.

Of course FreeBSD can implement those requirements. I just
think it's not _that_ easy because FREEBSD IS NOT LINUX.
Many dependencies will be resolved, many things added to
the kernel and system libraries, and when they are in a
working state, Linux will already use something else.

FreeBSD puts emphasize on durability, stability, the ability
to predict things, and the UNIX principle to have small
functional parts that do _one_ thing, and do it well, and
to interconnect those parts, instead intending to build
an egg-laying-wool-milk-sow, a one size fits all thing
that does everything. Of course it's nice to have a system
where different functionality can be plugged into to have
basically the same purpose (e. g. start or stop something).
FreeBSD has -- in ITS environment! -- such a system. Linux
has a different system, has different systemS. The more the
functional parts the OS and the applications are merged,
as it is the case in Linux (where no the OS exists, even
the kernel and the system tools are additional packages),
the more problems this implies to systems like FreeBSD that
have this functional distinction. However, integrating the
OS more with the installed GUI (!) programs is massively
important to attract desktop users with limited knowledge
about basic computer operations. This seems to be a growing
majority.

http://www.theatlantic.com/technology/archive/2012/08/fewer-and-fewer-people-want-to-know-about-computers-says-google/261271/

Not sure where this leads to...

What this is about is FreeBSDs refusal to implement equivalent
functionality as Linux has.

I'm not competent to make a statement regarding the amount
of work to do that, the benefit it brings and for how long
it will work until the whole thing has to be replaced by
something completely different. Still it would make sense
to assume that it's not that easy.

As for FreeBSDs market share, [...]

FreeBSD _does not have_ any market share. It's not a commercial
undertaking per se. It has usage share and even mind share. There
is no way you could bring _any_ numbers regarding market share
because (1st) it doesn't apply (e. g. like Which market share
has air in comparison to coal? - stupid question, I know),
and (2nd) as per the BSD license, you wouldn't even notice all
the BSDs running in network gear, storage appliances, electric
control units, display devices and so on. You have _zero_ chance
to find any numbers here you could compare.

[...] it is vanishingly small on the desktop with
far less uptake than Linux.

You mean usage share. Okay, agreed. FreeBSD is not a typically
known desktop system (even though _I_ am using it on the desktop
exclusively since 4.0). It's much more prominent in servers
where durability and stability are much more important than
bleeding edge features. You have no idea how many FreeBSD boxes
are still out there, running 4.x, 5.x or 6.x, acting as a file
server,

Re: Warning - FreeBSD (*BSD) entanglement in Linux ecosystem

2012-08-22 Thread Markiyan Kushnir


http://lists.freebsd.org/pipermail/freebsd-questions/2011-July/231832.html

Already read and discussed/flamed here.

--
Markiyan.

On 22.08.2012 13:29, Michel Talon wrote:


David Jackson said:


In reference to the claims that systemd developers do not care about
portability, this is deceptive and misleading.


You should read the following interview of Lennart Poettering
http://linuxfr.org/nodes/86687/comments/1249943
The amount of hubris and self confidence he deploys is really
astounding. I will just quote two extracts:

 LinuxFr.org : Systemd use a lot of Linux only technologies (cgroups,
udev, fanotify, timerfd, signalfd, etc). Do you really think the Linux
API has been taking the role of the POSIX API and the other systems are
irrelevant ?

Lennart : Yes, I don't think BSD is really too relevant anymore, and I
think that this implied requirement for compatibility with those systems
when somebody hacks software for the free desktop or ecosystem is a
burden, and holds us back for little benefit.  

and cherry on the cake

LinuxFr.org : Why Linux desktop hasn't been adopted by the
mainstream users ? Linus Torvalds seems to think it's mostly a social
issue and not a technical one. Do you agree with him ?

Lennart : I think we weren't innovative enough in the interface, and we
didn't have a convincing message and clear platform. If you accept MacOS
as benchmark for user interfaces, then we weren't really matching it, at
best copying it. I think this is changing now, with GNOME 3 which is a
big step forward as an interface for Linux and for the first time is
something that has been strictly designed under UI design guidelines.








___
freebsd-questions@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-questions
To unsubscribe, send any mail to freebsd-questions-unsubscr...@freebsd.org

Re: Warning - FreeBSD (*BSD) entanglement in Linux ecosystem

2012-08-22 Thread Jonathan McKeown

On Wednesday 22 August 2012 15:41:05 David Jackson wrote:
 So this is clearly not about portability, FreeBSD is free to implement
 these software interfaces to assure that software is portable to FreeBSD.

Really? You make software portable by writing it to one environment and then 
changing every other environment to suit the software?

I'm not sure software portability means what you think it means.

Jonathan
___
freebsd-questions@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-questions
To unsubscribe, send any mail to freebsd-questions-unsubscr...@freebsd.org

Re: Warning - FreeBSD (*BSD) entanglement in Linux ecosystem

2012-08-22 Thread C. P. Ghost

On Wed, Aug 22, 2012 at 3:41 PM, David Jackson djackson...@gmail.com wrote:
 That sort of shows my point in fact. There is nothing stopping FreeBSD from
 implementing cgroups,  udev, fanotify, timerfd, signalfd, its not like
 Linux is going to enforce patents on these things, its software, and
 freebsd can easily add code to support these things, and as well, systemd.

Right!

Nothing prevents us from writing a Linux compat shim similar
to the Linux-ABI (linuxulator) to provide the framework needed
by systemd et al. Make it optional, if necessary, so that the base
default FreeBSD system won't be contaminated.

It would also be nice to be able to kldload linux drivers
(binary blobs developed for Linux and provided by 3rd party
hardware vendors), but that would be harder to implement.
Then again, why not try? Isn't it like ndis(4), all over again?

-cpghost.

-- 
Cordula's Web. http://www.cordula.ws/
___
freebsd-questions@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-questions
To unsubscribe, send any mail to freebsd-questions-unsubscr...@freebsd.org

Issue with kernel building

2012-08-22 Thread antonin tessier






Hi,

I have a problem when I try to build my own kernel. I had never got such a one; 
here is my kernel configuration file and the building errors that it makes.

#device tun # Packet tunnel.
device  pty # BSD-style compatibility pseudo ttys
device  md  # Memory disks
device  gif # IPv6 and IPv4 tunneling
device  faith   # IPv6-to-IPv4 relaying (translation)
#device firmware# firmware assist module

# The `bpf' device enables the Berkeley Packet Filter.
# Be aware of the administrative consequences of enabling this!
# Note that 'bpf' is required for DHCP.
device  bpf # Berkeley packet filter

# USB support
options USB_DEBUG   # enable debug msgs
device  uhci# UHCI PCI-USB interface
device  ohci# OHCI PCI-USB interface
device  ehci# EHCI PCI-USB interface (USB 2.0)
#device xhci# XHCI PCI-USB interface (USB 3.0)
device  usb # USB Bus (required)
#device udbp# USB Double Bulk Pipe devices (needs netgraph)
device  uhid# Human Interface Devices
#device ukbd# Keyboard
#device ulpt# Printer
device  umass   # Disks/Mass storage - Requires scbus and da
device  ums # Mouse
#device urio# Diamond Rio 500 MP3 player
# USB Serial devices
#device u3g # USB-based 3G modems (Option, Huawei, Sierra)
#device uark# Technologies ARK3116 based serial adapters
#device ubsa# Belkin F5U103 and compatible serial adapters
#device uftdi   # For FTDI usb serial adapters
#device uipaq   # Some WinCE based devices
#device uplcom  # Prolific PL-2303 serial adapters
#device uslcom  # SI Labs CP2101/CP2102 serial adapters
#device uvisor  # Visor and Palm devices
#device uvscom  # USB serial support for DDI pocket's PHS
# USB Ethernet, requires miibus
#device aue # ADMtek USB Ethernet
#device axe # ASIX Electronics USB Ethernet
#device cdce# Generic USB over Ethernet
#device cue # CATC USB Ethernet
#device kue # Kawasaki LSI USB Ethernet
#device rue # RealTek RTL8150 USB Ethernet
#device udav# Davicom DM9601E USB
# USB Wireless
#device rum # Ralink Technology RT2501USB wireless NICs
#device run # Ralink Technology RT2700/RT2800/RT3000 NICs.
#device uath# Atheros AR5523 wireless NICs
#device upgt# Conexant/Intersil PrismGT wireless NICs.
#device ural# Ralink Technology RT2500USB wireless NICs
device  urtw# Realtek RTL8187B/L wireless NICs
#device zyd # ZyDAS zd1211/zd1211b wireless NICs

# FireWire support
#device firewire# FireWire bus code
# sbp(4) works for some systems but causes boot failure on others
#device sbp # SCSI over FireWire (Requires scbus and da)
#device fwe # Ethernet over FireWire (non-standard!)
#device fwip# IP over FireWire (RFC 2734,3146)
#device dcons   # Dumb console driver
#device dcons_crom  # Configuration ROM for dcons

# Sound support
device  sound   # Generic sound driver (required)
#device snd_cmi # CMedia CMI8338/CMI8738
#device snd_csa # Crystal Semiconductor CS461x/428x
#device snd_emu10kx # Creative SoundBlaster Live! and Audigy
#device snd_es137x  # Ensoniq AudioPCI ES137x
device  snd_hda # Intel High Definition Audio
device  snd_ich # Intel, NVidia and other ICH AC'97 Audio
#device snd_uaudio  # USB Audio
device  snd_via8233 # VIA VT8233x Audio

# make kernel KERNCONF=GOLLUM

 MAKE=make sh /usr/src/sys/conf/newvers.sh GOLLUM
cc -c -O2 -frename-registers -pipe -fno-strict-aliasing -march=native -std=c99 
-g -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes  
-Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual  -Wundef 
-Wno-pointer-sign -fformat-extensions  -Wmissing-include-dirs 
-fdiagnostics-show-option   -nostdinc  -I. -I/usr/src/sys 
-I/usr/src/sys/contrib/altq -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include 
opt_global.h -fno-common -finline-limit=8000 --param inline-unit-growth=100 
--param large-function-growth=1000  -fno-omit-frame-pointer -mcmodel=kernel 
-mno-red-zone -mno-mmx -mno-sse -msoft-float  -fno-asynchronous-unwind-tables 
-ffreestanding -fstack-protector -Werror  vers.c
linking kernel.debug
rt2560.o: In function `rt2560_ioctl':

Re: /tmp filesystem full

2012-08-22 Thread Robert Bonomi

 From owner-freebsd-questi...@freebsd.org  Wed Aug 22 08:27:59 2012
 Date: Wed, 22 Aug 2012 14:25:51 +0100
 From: Steve O'Hara-Smith st...@sohara.org
 To: freebsd-questions@freebsd.org
 Subject: Re: /tmp filesystem full

 On Wed, 22 Aug 2012 08:14:35 -0500 (CDT)
 Robert Bonomi bon...@mail.r-bonomi.com wrote:

   From owner-freebsd-questi...@freebsd.org  Wed Aug 22 05:59:52 2012
   Date: Wed, 22 Aug 2012 12:59:13 +0200
   From: Andy Wodfer wod...@gmail.com
   To: freebsd-questions freebsd-questions@freebsd.org
   Subject: /tmp filesystem full

   Hi,
   I have about 500MB in my /tmp and it seems to be too small when the
   periodic LOCATE script runs every week.

   What's the best way to increase the size of /tmp ? Could I simply
   remove it and create a symbolic link ln -s to say /usr/tmp instead
   (where I have several hundred GBs free)?

  That is a BAD IDEA(tm)!

  There are appliations that assume /tmp, /var/tmp, and /usr/tmp are
  _distinct_ directories.  They will create files _with_the_same_name_ in
  two of those 'temp' locations, expecting them to be unique.o

   /usr/tmp usually does not exist so creating it and
 symlinking /tmp to it is OK.

I've used enough different versions of Unix wher '/usr/tmp/ _was_ a standard
diretory to be *very* leery.  wry grin

___
freebsd-questions@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-questions
To unsubscribe, send any mail to freebsd-questions-unsubscr...@freebsd.org

Re: /tmp filesystem full

2012-08-22 Thread Sergio de Almeida Lenzi

If you use zfs, that is easy...  zfs set quota=NNG  pool/tmp

if not
try to mount tmp in memory... 
in /etc/rc.conf

tmpmfs=YES
tmpsize=400m  

reboot
this would create a /tmp in memory (swap)
size=400 Megabytes

Sergio
___
freebsd-questions@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-questions
To unsubscribe, send any mail to freebsd-questions-unsubscr...@freebsd.org

Warning - FreeBSD (*BSD) entanglement in Linux ecosystem

2012-08-22 Thread J B

Hi,
I think it would be useful to get familiar with what systemd is,
technically and fundamentally.
Here is a thread in which a knowledgeable professional
questions many technical aspects of it:

open this thread in one browser window (to get a nice overview of what
you already read):
http://lists.fedoraproject.org/pipermail/devel/2011-June/thread.html#152323

and start with the first post in another window (the reason is that tricksters
tried to change the thread subject, but if you follow thr thread with next
post you will not miss anything; be patient - there are some intermediate
posts that are noice):
systemd: please stop trying to take over the world :)   Denys Vlasenko
http://lists.fedoraproject.org/pipermail/devel/2011-June/152323.html

There are important points raised:
- going beyond system init replacement, systemd to be a platform for OS,
  together with GNOME 3
- not adhering to UNIX principles (modularity, etc)
- interference with sysadmin duties/decisions to set up the system (e.g.
  loading modules on its own and e.g. enabling sys capabilities and protocols)
- there are many other phantom reasons systemd was introduced as
  the next thing after the sliced bread invention, like parallelization that
  is not (but they sold it as if they implemented concurrency)

This is just an intro ...
There is much more to be questioned if you know what and care to.

The author of this snake oil knows what and why he sells it.
He is not a UNIX mind.

One can scratch her head thinking what kind of pseudo progress can
be sold to those goofies in Linux ecosystem, and apparently in *BSD
ecosystem as well.
The Slackware dev hit it exactly on the nail !

Think and enjoy it.
I will eventually comment more on it later as well.
jb
___
freebsd-questions@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-questions
To unsubscribe, send any mail to freebsd-questions-unsubscr...@freebsd.org

Re: /tmp filesystem full

This will happen automatically if you go to multiuser without a
writeable /tmp.  See /etc/rc.d/tmp
I have a problem with the semantics of the rc scripts for this and
var, though - if you are going to use a memory-backed filesystem, you
should reserve all the space at the outset.  Bad things can occur as
you approach the memory limit (like a kernel panic) otherwise.

I'd prefer something like this:

_mdunit=`mdconfig -a -n -t malloc -o reserve -s ${tmpsize}`
newfs /dev/md${_mdunit}  /dev/null 21
mount -o ${tmpmfs_flags} /dev/md${_mdunit} /tmp

But that's just me. mount_md doesn't quite do this.

-M

On Wed, Aug 22, 2012 at 12:48 PM, Sergio de Almeida Lenzi
lenzi.ser...@gmail.com wrote:
 If you use zfs, that is easy...  zfs set quota=NNG  pool/tmp

 if not
 try to mount tmp in memory...
 in /etc/rc.conf

 tmpmfs=YES
 tmpsize=400m

 reboot
 this would create a /tmp in memory (swap)
 size=400 Megabytes

 Sergio
 ___
 freebsd-questions@freebsd.org mailing list
 http://lists.freebsd.org/mailman/listinfo/freebsd-questions
 To unsubscribe, send any mail to freebsd-questions-unsubscr...@freebsd.org
___
freebsd-questions@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-questions
To unsubscribe, send any mail to freebsd-questions-unsubscr...@freebsd.org

Re: /tmp filesystem full

On Wed, 22 Aug 2012 14:14:17 -0700
Michael Sierchio wrote:

 This will happen automatically if you go to multiuser without a
 writeable /tmp.  See /etc/rc.d/tmp

It doesn't, the default is an old-fashioned md device, not tmpfs.


 I have a problem with the semantics of the rc scripts for this and
 var, though - if you are going to use a memory-backed filesystem, you
 should reserve all the space at the outset.  

It defaults to 20MB. There's no such thing as an unlimited md-backed
device


 Bad things can occur as
 you approach the memory limit (like a kernel panic) otherwise.

Provided that you have swap you can have a /tmp that's much bigger
than memory with either md or tmpfs.

 I'd prefer something like this:
 
 _mdunit=`mdconfig -a -n -t malloc -o reserve -s ${tmpsize}`

It's a bad idea to use a malloc device as it uses wired kernel memory, the 
default allows the files to be written out
to swap rather than panic the kernel.

 newfs /dev/md${_mdunit}  /dev/null 21
 mount -o ${tmpmfs_flags} /dev/md${_mdunit} /tmp
 
 But that's just me. mount_md doesn't quite do this.
___
freebsd-questions@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-questions
To unsubscribe, send any mail to freebsd-questions-unsubscr...@freebsd.org

Re: /tmp filesystem full

On Wed, 22 Aug 2012 23:21:12 +0100
RW wrote:

 On Wed, 22 Aug 2012 14:14:17 -0700
 Michael Sierchio wrote:
 
  This will happen automatically if you go to multiuser without a
  writeable /tmp.  See /etc/rc.d/tmp
 
 It doesn't, the default is an old-fashioned md device, not tmpfs.

Sorry I misread the previous post which *was* referring to an md device,
but the rest is right.
___
freebsd-questions@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-questions
To unsubscribe, send any mail to freebsd-questions-unsubscr...@freebsd.org

firefox png

2012-08-22 Thread david coder


is there a system png that comes w/ 8.3 that is distinct from the ports png?
if not, how explain that install of firefox-14.0.1 fails w/ the error message
that the system png does not support APNG even though the makefile for the
png port contains the line

OPTIONS=APNG Animated PNG support On

?

i am puzzled.

thx.  


david coder
___
freebsd-questions@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-questions
To unsubscribe, send any mail to freebsd-questions-unsubscr...@freebsd.org

Re: firefox png

On Wed, 22 Aug 2012 19:01:50 -0400, david coder wrote:
 is there a system png that comes w/ 8.3 that is distinct from the ports png?
 if not, how explain that install of firefox-14.0.1 fails w/ the error message
 that the system png does not support APNG even though the makefile for the
 png port contains the line
 
   OPTIONS=APNG Animated PNG support On
 
 ?
 
 i am puzzled.

The question has already been answered on 2012-08-02.

http://lists.freebsd.org/pipermail/freebsd-questions/2012-August/243984.html

You need to recompile the PNG library (from ports, does _not_
belong to the system - it's /usr/ports/graphics/png that will
install libpng to your system) with the Animated PNG support
(APNG) option [x] set. After doing so, you will be able to resume
your Firefox build. See man ports or the manual of your port
management tool (e. g. portmaster) on how to do that. Make sure
you do make clean prior to that attempt.

From the error message which you _have not shown_ (so I'm just
guessing) it seems that libpng has been installed without the
animation support. If you can make sure it's properly installed
and you still get the error, please _show_ the error here so a
better diagnostics step can be done.


-- 
Polytropon
Magdeburg, Germany
Happy FreeBSD user since 4.0
Andra moi ennepe, Mousa, ...
___
freebsd-questions@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-questions
To unsubscribe, send any mail to freebsd-questions-unsubscr...@freebsd.org

Re: firefox png

2012-08-22 Thread david coder


thx, i hadn't seen the reply to my earlier message.

unfortunately, though i've got the png port installed w/ 


OPTIONS=APNG Animated PNG support On

the install of freebsd fails w/ the error message given below.

is there something else required in the png makefile or elsewhere that i'm
missing?

some writers have insisted that a recent install of the os is also needed,
but that is also a non-issue for my boxes:  they're up to date.

installing firefox is not as urgent for me since chrome is adequate for most
purposes, but still...

thx for your reply.  any further thoughts would be appreciated.

david

+++ Polytropon [23/08/12 01:17 +0200]:

On Wed, 22 Aug 2012 19:01:50 -0400, david coder wrote:

is there a system png that comes w/ 8.3 that is distinct from the ports png?
if not, how explain that install of firefox-14.0.1 fails w/ the error message
that the system png does not support APNG even though the makefile for the
png port contains the line

OPTIONS=APNG Animated PNG support On

?

i am puzzled.


The question has already been answered on 2012-08-02.

http://lists.freebsd.org/pipermail/freebsd-questions/2012-August/243984.html

You need to recompile the PNG library (from ports, does _not_
belong to the system - it's /usr/ports/graphics/png that will
install libpng to your system) with the Animated PNG support
(APNG) option [x] set. After doing so, you will be able to resume
your Firefox build. See man ports or the manual of your port
management tool (e. g. portmaster) on how to do that. Make sure
you do make clean prior to that attempt.


From the error message which you _have not shown_ (so I'm just

guessing) it seems that libpng has been installed without the
animation support. If you can make sure it's properly installed
and you still get the error, please _show_ the error here so a
better diagnostics step can be done.


--
Polytropon
Magdeburg, Germany
Happy FreeBSD user since 4.0
Andra moi ennepe, Mousa, ...

___
freebsd-questions@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-questions
To unsubscribe, send any mail to freebsd-questions-unsubscr...@freebsd.org

Re: firefox png

On Wed, 22 Aug 2012 19:43:55 -0400, david coder wrote:
 thx, i hadn't seen the reply to my earlier message.
 
 unfortunately, though i've got the png port installed w/ 
 
   OPTIONS=APNG Animated PNG support On

That should be the default. Anyway, you can always check which
options had been in use when building and installing a port:

% cat /var/db/ports/png/options
# This file is auto-generated by 'make config'.
# No user-servicable parts inside!
# Options for png-1.4.8
_OPTIONS_READ=png-1.4.8
WITH_APNG=true

In this example you can see that it has been properly installed.



 the install of freebsd fails w/ the error message given below.

Sadly the Firefox build error message is not included. 



 is there something else required in the png makefile or elsewhere that i'm
 missing?

I'm sure this entry of /usr/ports/UPDATING applies:

20120531:
  AFFECTS: users of graphics/png
  AUTHOR: din...@freebsd.org

  The PNG library has been updated to version 1.5.10.  Please rebuild all
  ports that depend on it.

  If you use portmaster:
portmaster -r png-
  If you use portupgrade:
portupgrade -fr graphics/png

It's easy to do so as the required commands are provided. Make
sure your ports tree is up to date and follow the advice to
install all ports depending on the _latest_ libpng (which you
seem to have installed, as you confirmed).



 some writers have insisted that a recent install of the os is also needed,
 but that is also a non-issue for my boxes:  they're up to date.

That is only needed when a 3rd party program or library requires
a newer OS version. The OS itself does not provide a PNG library.
If such a requirement is present, ports usually refuse to build
on older systems (the Makefile refuses to continue working if the
minimum OS version is not met). Such a change in a port will
definitely be mentioned in /usr/ports/UPDATING, a file worth
checking whenever dealing with updates as it often contains
important information regarding such changes.



 installing firefox is not as urgent for me since chrome is adequate for most
 purposes, but still...

I also have Firefox installed here, even though it's not up to
date, perfectly fitting the system's outdatedness. :-) I had
no problems installing it. Examining the Makefile of Firefox
(/usr/ports/www/firefox/Makefile) I don't see anything that
mentions libpng or animated PNG support. Maybe this is a
dependency of a dependency of Firefox?

Again, this seems to match the entry of /usr/ports/UPDATING.
It does _not_ require you to reinstall your OS. Where would
we be if every little package addition would force the OS to
be reinstalled... :-)



-- 
Polytropon
Magdeburg, Germany
Happy FreeBSD user since 4.0
Andra moi ennepe, Mousa, ...
___
freebsd-questions@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-questions
To unsubscribe, send any mail to freebsd-questions-unsubscr...@freebsd.org

Re: firefox png

2012-08-22 Thread Dan Nelson

In the last episode (Aug 22), david coder said:
 thx, i hadn't seen the reply to my earlier message.
 
 unfortunately, though i've got the png port installed w/ 
 
   OPTIONS=APNG Animated PNG support On

This line just tells you what the default is on a system that hasn't built
the png port yet.  Before 2011-07-08, the default was Off.
 
 the install of freebsd fails w/ the error message given below.

What does make showconfig in the ports/graphics/png directory print?  I
bet you first installed the png port over a year ago, so you have inherited
the Off value from then.

-- 
Dan Nelson
dnel...@allantgroup.com
___
freebsd-questions@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-questions
To unsubscribe, send any mail to freebsd-questions-unsubscr...@freebsd.org

Re: firefox png

2012-08-22 Thread david coder


+++ Dan Nelson [22/08/12 19:01 -0500]:

In the last episode (Aug 22), david coder said:

thx, i hadn't seen the reply to my earlier message.

unfortunately, though i've got the png port installed w/ 


OPTIONS=APNG Animated PNG support On


This line just tells you what the default is on a system that hasn't built
the png port yet.  Before 2011-07-08, the default was Off.


the install of freebsd fails w/ the error message given below.


What does make showconfig in the ports/graphics/png directory print?  I
bet you first installed the png port over a year ago, so you have inherited
the Off value from then.

--
Dan Nelson
dnel...@allantgroup.com
___
freebsd-questions@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-questions


right on!  thank you.

david coder
dcodernet


To unsubscribe, send any mail to freebsd-questions-unsubscr...@freebsd.org

___
freebsd-questions@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-questions
To unsubscribe, send any mail to freebsd-questions-unsubscr...@freebsd.org

Re: /tmp filesystem full

On Wed, Aug 22, 2012 at 3:29 PM, RW rwmailli...@googlemail.com wrote:

 Sorry I misread the previous post which *was* referring to an md device,
 but the rest is right.

Not really. ;-)  The one compelling reason to use an md filesystem for
/tmp or /var is when you have no swap, and/or your root fs is read
only (or read mostly), as with embedded computers, Soekris boxes
booting from CF, USB stick, or even mSATA (I wouldn't swap on a
partition on an MLC mSATA device).

In that case, you most certainly want to reserve the space for the
filesystem at creation time.  Usually
/tmp - /var/tmp is that case.

- M
___
freebsd-questions@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-questions
To unsubscribe, send any mail to freebsd-questions-unsubscr...@freebsd.org

Re: /tmp filesystem full

On Wed, 22 Aug 2012 17:35:29 -0700, Michael Sierchio wrote:
 On Wed, Aug 22, 2012 at 3:29 PM, RW rwmailli...@googlemail.com wrote:
 
  Sorry I misread the previous post which *was* referring to an md device,
  but the rest is right.
 
 Not really. ;-)  The one compelling reason to use an md filesystem for
 /tmp or /var is when you have no swap, and/or your root fs is read
 only (or read mostly), as with embedded computers, Soekris boxes
 booting from CF, USB stick, or even mSATA (I wouldn't swap on a
 partition on an MLC mSATA device).
 
 In that case, you most certainly want to reserve the space for the
 filesystem at creation time.  Usually
 /tmp - /var/tmp is that case.

For the mentioned appliances, that would not be a problem.
However there's a distinction between /tmp and /var/tmp
that can be summarized like this: The content of /tmp may
disappear after a reboot (see clear_tmp_enable=YES in
/etc/rc.conf), whereas /var/tmp is to be preserved during
reboot. Some programs rely on this behavior when putting
delete-temporary and keep-temporary files into the
respective directories.



-- 
Polytropon
Magdeburg, Germany
Happy FreeBSD user since 4.0
Andra moi ennepe, Mousa, ...
___
freebsd-questions@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-questions
To unsubscribe, send any mail to freebsd-questions-unsubscr...@freebsd.org

Re: /tmp filesystem full

On Wed, Aug 22, 2012 at 5:43 PM, Polytropon free...@edvax.de wrote:

 For the mentioned appliances, that would not be a problem.
 However there's a distinction between /tmp and /var/tmp
 that can be summarized like this: The content of /tmp may
 disappear after a reboot (see clear_tmp_enable=YES in
 /etc/rc.conf), whereas /var/tmp is to be preserved during
 reboot. Some programs rely on this behavior when putting
 delete-temporary and keep-temporary files into the
 respective directories.

You are quite right - most of what's in /var is expected to be
persistent.  In the case where /var/tmp is on a mfs, it's hard to
oblige.  On these same systems, I do have rc scripts that save parts
of /var (those listed in an rc.conf variable) for shutdown, and
populate those dirs (after /etc/rc.d/var does its mtree stuff) on
start up.

- M
___
freebsd-questions@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-questions
To unsubscribe, send any mail to freebsd-questions-unsubscr...@freebsd.org

Re: Warning - FreeBSD (*BSD) entanglement in Linux ecosystem

2012-08-22 Thread Randal L. Schwartz

 David == David Jackson djackson...@gmail.com writes:

David The fact is, FreeBSD can fully support systemd and all kernel and system
David features, there is nothing here that is impossible for FreeBSD to
David support.

So this statement in the WikiP is false?

systemd is Linux-only by design, as it relies upon features such as
cgroups and fanotify.[6] Debian is avoiding the adoption of systemd due
to this issue.[7]

-- 
Randal L. Schwartz - Stonehenge Consulting Services, Inc. - +1 503 777 0095
mer...@stonehenge.com URL:http://www.stonehenge.com/merlyn/
Smalltalk/Perl/Unix consulting, Technical writing, Comedy, etc. etc.
See http://methodsandmessages.posterous.com/ for Smalltalk discussion
___
freebsd-questions@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-questions
To unsubscribe, send any mail to freebsd-questions-unsubscr...@freebsd.org

Re: Problem with r-o access in jail

2012-08-22 Thread James Edwards

 Want a nullfs filesystem to be read-only for tech people to search-only
 maillog files.

 host machine's files:

 /var/log/mx1/maillog* files

 the maillog files are all 644 and r bit is set all along the path


 using ezjail

 jail root is /var/jails

 jail name is fixit

 mkdir -p /var/jails/fixit/mx1

 fixit/mx1 dir has 644 and r bit is set all along the path


The directory permissions should have the execute bit set, it should be
set to 755 instead of 644.

 mount_nullfs -o ro /var/log/mx1 /var/jails/fixit/mx1


 ezjail-admin console fixit  as fixit jail root user


 I add a user fixit:fixit


 ssh logon to fixit jail's ip as  user fixit

 ll /mx1

 gives nothing but:

 ls: maillog.45.bz2: Permission denied
 ls: maillog.46.bz2: Permission denied
 ls: maillog.47.bz2: Permission denied
 ls: maillog.48.bz2: Permission denied
 ls: maillog.49.bz2: Permission denied
 ls: maillog.5.bz2: Permission denied
 ls: maillog.50.bz2: Permission denied
 ls: maillog.51.bz2: Permission denied


If your permissions are set to 644 on the directories, this is the result
of 'ls'.  After changing the directories permissions to 755, the
'Permission denied' errors will stop.



 ezjail-admin console fixit

 ...shows the  /mx1/maillog* files all to be 644

 If move the jail fixit user from group fixit to group wheel, user fixit
 has access to /mx1/maillog* files.

 suggestions?

 thanks,
 Len

-- 
Regards,
James Edwards


___
freebsd-questions@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-questions
To unsubscribe, send any mail to freebsd-questions-unsubscr...@freebsd.org

Re: /tmp filesystem full

On Wed, 22 Aug 2012 17:35:29 -0700
Michael Sierchio wrote:

 On Wed, Aug 22, 2012 at 3:29 PM, RW rwmailli...@googlemail.com
 wrote:
 
  Sorry I misread the previous post which *was* referring to an md
  device, but the rest is right.
 
 Not really. ;-)  The one compelling reason to use an md filesystem for
 /tmp or /var is when you have no swap, and/or your root fs is
 read-only

 tmpfs and swap md devices don't actually need swap. I don't seen any
 advantage in your way of creating an md device for /tmp.

 
___
freebsd-questions@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-questions
To unsubscribe, send any mail to freebsd-questions-unsubscr...@freebsd.org

Re: /tmp filesystem full