Re: embedding pdf viewers in firefox

2008-01-27 Thread Matthew Seaman
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

KAYVEN RIESE wrote:

 as you can see, i am running the freeBSD OS.  i have a gnome desktop.  i
 usually run firefox browser (i note that gnome has built in browser
 called ephinany).  i am dissatisfied with the fact that if i browse to a
 webpage that contains pdf content that i am  forced to save the file.

Verb. Sap.  It's best to start a new thread when you have a new subject.
Changing the subject on an old thread will tend to hide your message
quite effectively in some mail clients, plus hijacking someone else's
thread is rude at best.  This is also a subject more suitable for
[EMAIL PROTECTED] rather than [EMAIL PROTECTED]

Anyhow, if you are running native FreeBSD firefox, then simply install
print/acroread7.  This includes a browser plugin that has the effect you
desire:

/usr/local/Adobe/Acrobat7.0/ENU/Browser/intellinux/nppdf.so

In order to get firefox to load the plugin it needs to be wrapped in a
small amount of translation code and made available in the appropriate
directory.  To do that install the www/nspluginwrapper port.  Then run:

   % nspluginwrapper -v -a -i

as your own UID.  This will create objects in ${HOME}/.mozilla/plugins

Stop and restart firefox.  Type about:plugins into the URL bar and it should
now show (amongst others):

   Adobe Reader 7.0

File name: npwrapper.nppdf.so
The Adobe Reader plugin is used to enable viewing of PDF and FDF files from 
within the browser.

Et voilà.

Cheers,

Matthew


- -- 
Dr Matthew J Seaman MA, D.Phil.   7 Priory Courtyard
  Flat 3
PGP: http://www.infracaninophile.co.uk/pgpkey Ramsgate
  Kent, CT11 9PW
-BEGIN PGP SIGNATURE-
Version: GnuPG v2.0.4 (FreeBSD)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iD8DBQFHnEz88Mjk52CukIwRCKduAJ4v7lCxGbsiCjyzLqGb+dRKtRCeJwCdH1rD
iycULv8rmO1PSozE2xRkWBs=
=MzpM
-END PGP SIGNATURE-
___
freebsd-hackers@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to [EMAIL PROTECTED]


Re: gettimeofday() in hping

2008-01-27 Thread Stefan Lambrev

Greetings,

Stefan Lambrev wrote:

Greetings,

Kris Kennaway wrote:

Stefan Lambrev wrote:

It is the socket buffer that is filling up.  Either the application 
is not increasing it to large enough size or the default maximum is 
too low (Linux may set a larger default).  Try increasing 
kern.ipc.maxsockbuf and confirming with the source and/or ktrace 
that it is doing the right setsockopt() call.

Increasing kern.ipc.maxsockbuf doesn't help.

Actually this is the code that failed and print this error:

   result = sendto(sockraw, packet, packetsize, 0,
   (struct sockaddr*)remote, sizeof(remote));

   if (result == -1  errno != EINTR  !opt_rand_dest  
!opt_rand_source) {

   perror([send_ip] sendto);

Those are the only references for setsockopt when ktracing:
3385 hpingCALL  __sysctl(0xbfbfe870,0x6,0,0xbfbfe888,0,0)
 3385 hpingRET   __sysctl 0
 3385 hpingCALL  __sysctl(0xbfbfe870,0x6,0x28305180,0xbfbfe888,0,0)
 3385 hpingRET   __sysctl 0
 3385 hpingCALL  socket(PF_INET,SOCK_DGRAM,IPPROTO_IP)
 3385 hpingRET   socket 3
 3385 hpingCALL  
setsockopt(0x3,SOL_SOCKET,SO_BROADCAST,0xbfbfe884,0x4)

 3385 hpingRET   setsockopt 0
 3385 hpingCALL  connect(0x3,0x8067da0,0x10)
 3385 hpingRET   connect 0
 3385 hpingCALL  getsockname(0x3,0xbfbfe874,0xbfbfe888)
 3385 hpingRET   getsockname 0
 3385 hpingCALL  close(0x3)
 3385 hpingRET   close 0
 3385 hpingCALL  socket(PF_INET,SOCK_RAW,IPPROTO_RAW)
 3385 hpingRET   socket 3
 3385 hpingCALL  
setsockopt(0x3,SOL_SOCKET,SO_BROADCAST,0xbfbfe914,0x4)

 3385 hpingRET   setsockopt 0
 3385 hpingCALL  setsockopt(0x3,0,0x2,0xbfbfe914,0x4)
 3385 hpingRET   setsockopt 0
 3385 hpingCALL  open(0xbfbfe8a4,O_RDWR,unused0)
 3385 hpingNAMI  /dev/bpf0
 3385 hpingRET   open -1 errno 16 Device busy
 3385 hpingCALL  open(0xbfbfe8a4,O_RDWR,unused0)
 3385 hpingNAMI  /dev/bpf1
 3385 hpingRET   open 4


OK, try adding the setsockopt(...SO_SNDBUF...) call.

Will something like this do the trick?

void socket_sndbuf(int sd)
{
   long int bufsize;
   bufsize = 65536;
   if (setsockopt(sd, SOL_SOCKET, SO_SNDBUF,
   (char *)bufsize, sizeof(int)) == -1)
   {
   printf([socket_sndbuf] can't set SO_SNDBUF option\n);
   }
}

I'm not a C developer so pardon me if I made something stupid :)
Also how can I make bufsize = default settings*2 for example?

I tried this code and here is what ktrace show now:
65372 hping3   CALL  socket(PF_INET,SOCK_DGRAM,IPPROTO_IP)
65372 hping3   RET   socket 3
65372 hping3   CALL  
setsockopt(0x3,SOL_SOCKET,SO_BROADCAST,0xbfbfe844,0x4)

65372 hping3   RET   setsockopt 0
65372 hping3   CALL  connect(0x3,0x8067e20,0x10)
65372 hping3   RET   connect 0
65372 hping3   CALL  getsockname(0x3,0xbfbfe834,0xbfbfe848)
65372 hping3   RET   getsockname 0
65372 hping3   CALL  close(0x3)
65372 hping3   RET   close 0
65372 hping3   CALL  socket(PF_INET,SOCK_RAW,IPPROTO_RAW)
65372 hping3   RET   socket 3
65372 hping3   CALL  
setsockopt(0x3,SOL_SOCKET,SO_BROADCAST,0xbfbfe8d4,0x4)

65372 hping3   RET   setsockopt 0
65372 hping3   CALL  setsockopt(0x3,0,0x2,0xbfbfe8d4,0x4)
65372 hping3   RET   setsockopt 0
65372 hping3   CALL  setsockopt(0x3,SOL_SOCKET,SO_SNDBUF,0xbfbfe8d4,0x4)
65372 hping3   RET   setsockopt 0



Kris
___
freebsd-hackers@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to 
[EMAIL PROTECTED]



I finally managed to get ktrace of falling hping

 2250 hping3   RET   sendto 40/0x28
 2250 hping3   CALL  sigaction(SIGALRM,0x7fffe7b0,0x7fffe790)
 2250 hping3   RET   sigaction 0
 2250 hping3   CALL  setitimer(0,0x7fffe7c0,0x7fffe7a0)
 2250 hping3   RET   setitimer 0
 2250 hping3   CALL  gettimeofday(0x7fffe780,0)
 2250 hping3   RET   gettimeofday 0
 2250 hping3   CALL  gettimeofday(0x7fffe780,0)
 2250 hping3   RET   gettimeofday 0
 2250 hping3   CALL  sendto(0x3,0x800e1b050,0x28,0,0x522600,0x10)
 2250 hping3   GIO   fd 3 wrote 40 bytes
  0x 4500 2800 c3f0  4006  0a03 0303 0a03 0301 9570 
0050 6b32 4398 30f3 e723 5002 0200 3737   
|E.([EMAIL PROTECTED]|

 2250 hping3   RET   sendto 40/0x28
 2250 hping3   CALL  sigaction(SIGALRM,0x7fffe7b0,0x7fffe790)
 2250 hping3   RET   sigaction 0
 2250 hping3   CALL  setitimer(0,0x7fffe7c0,0x7fffe7a0)
 2250 hping3   RET   setitimer 0
 2250 hping3   CALL  gettimeofday(0x7fffe780,0)
 2250 hping3   RET   gettimeofday 0
 2250 hping3   CALL  gettimeofday(0x7fffe780,0)
 2250 hping3   RET   gettimeofday 0
 2250 hping3   CALL  sendto(0x3,0x800e1b050,0x28,0,0x522600,0x10)
 2250 hping3   RET   sendto -1 errno 55 No buffer space available
 2250 hping3   CALL  writev(0x2,0x7fffe6a0,0x4)
 2250 hping3   GIO   fd 2 wrote 44 bytes
  [send_ip] sendto: No buffer space available
  
 2250 hping3   RET 

'periodic daily' memory usage

2008-01-27 Thread Dag-Erling Smørgrav
'periodic daily' runs my router out of swap every night, usually killing
named as a result.

A little sleuthing uncovered that the culprit is the 'sort -k 11'
command in /etc/periodic/security/100.checksetuid.  The easy solution
would be to disable that script, but for obvious reasons, I'd rather
not.

Most of the time, named has the largest RSS of all the processes running
on my router, by an order of magnitude. It's difficult to tell precisely
since ssh'ing in to run 'top -o res' skews the results (how are you
doing, mister Heisenberg?), but it's usually named followed by sshd and
zsh.

When 100.checksetuid is running, however, sort grows larger than even
named.

I tried modifying the script to feed considerably less data to sort,
(only fields 2 and 11 from each line), but it doesn't seem to affect
sort's memory usage.  I'm starting to wonder if perhaps GNU sort uses a
fixed-size buffer for each line of input, so reducing the length of the
lines makes no difference.

The solution I found that did work was to eliminate the loop over $MP
and use 'find -s $MP ...' instead, which eliminates the need for sort.
This reduces the memory requirement for 100.checksetuid by, oh, 80% or
so, and greatly simplifies the logic.

Note that 'find -s' and find | sort may not produce the same output, but
this only means you'll get an ugly diff the first time you run the new
script - it won't cause any trouble later.

An entirely different issue is why named uses so much memory...  does
anybody know of a way to specify how much memory named may use for its
cache?

DES
-- 
Dag-Erling Smørgrav - [EMAIL PROTECTED]

Index: etc/periodic/security/100.chksetuid
===
RCS file: /home/ncvs/src/etc/periodic/security/100.chksetuid,v
retrieving revision 1.9
diff -u -r1.9 100.chksetuid
--- etc/periodic/security/100.chksetuid	23 Nov 2007 13:00:31 -	1.9
+++ etc/periodic/security/100.chksetuid	27 Jan 2008 12:54:38 -
@@ -43,22 +43,17 @@
 [Yy][Ee][Ss])
 	echo 
 	echo 'Checking setuid files and devices:'
-	# XXX Note that there is the possibility of overrunning the args to ls
-	MP=`mount -t ufs,zfs | egrep -v  no(suid|exec) | awk '{ print $3 }' | sort`
-	if [ -n ${MP} ]
-	then
-	set ${MP}
-	while [ $# -ge 1 ]; do
-	mount=$1
-	shift
-	find $mount -xdev -type f \
-			\( -perm -u+x -or -perm -g+x -or -perm -o+x \) \
-			\( -perm -u+s -or -perm -g+s \) -print0
-	done | xargs -0 -n 20 ls -liTd | sed 's/^ *//' | sort -k 11 |
-	  check_diff setuid - ${host} setuid diffs:
-	rc=$?
-	fi;;
-*)	rc=0;;
+	MP=`mount -t ufs,zfs | awk '$0 !~ /no(suid|exec)/ { print $3 }'`
+	find -sx $MP -type f \
+		\( -perm -u+x -or -perm -g+x -or -perm -o+x \) \
+		\( -perm -u+s -or -perm -g+s \) -print0 |
+	xargs -0 ls -liTd |
+	check_diff setuid - ${host} setuid diffs:
+	rc=$?
+	;;
+*)
+	rc=0
+	;;
 esac
 
 exit $rc
___
freebsd-hackers@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to [EMAIL PROTECTED]

Re: 'periodic daily' memory usage

2008-01-27 Thread Mike Bristow

Dag-Erling Smørgrav wrote:

An entirely different issue is why named uses so much memory...  does
anybody know of a way to specify how much memory named may use for its
cache?
  


Something like :

options {
   directory   /etc/namedb;
   pid-file/var/run/named/pid;
   *max-cache-size 10485760;
};


According to http://www.isc.org/sw/bind/arm94/Bv9ARM.ch06.html#options

*
___
freebsd-hackers@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to [EMAIL PROTECTED]


kstackusage() patch request for comments

2008-01-27 Thread Alexander Motin

Hi.

I have made a patch
http://www.mavhome.dp.ua/kstackusage.patch
that implements machine dependent function returning current kernel 
thread stack usage statistics and uses it in netgraph subsystem for 
receiving maximum benefit from direct function calls and minimum 
queueing while keeping stack protected. As I have never developed 
machine-dependant things I would like to hear any comments about it.


The main question I have is about source files and headers I should use 
for this specific purposes. Is it correct way to define function in 
machine independent header, but implement it in machdep.c? Or I should 
define it in machine dependent headers?


Also I would be grateful for help with implementations of this function 
for arch different from i386/amd64.


Thanks.

--
Alexander Motin
___
freebsd-hackers@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to [EMAIL PROTECTED]


Re: FreeBSD hacker 101

2008-01-27 Thread Mike Meyer
On Sat, 26 Jan 2008 15:55:53 -0800 (PST) KAYVEN  RIESE [EMAIL PROTECTED] 
wrote:

 
 
 On Sat, 26 Jan 2008, Mike Meyer wrote:
  On Sat, 26 Jan 2008 12:24:36 -0800 (PST) KAYVEN  RIESE [EMAIL PROTECTED] 
  wrote:
  On Sat, 26 Jan 2008, Dag-Erling Smørgrav wrote:
  KAYVEN  RIESE [EMAIL PROTECTED] writes:
  .rpm is a package format, and comes with a tool set for using it. Most
  (all?) GNU/Linux systems come with tools for dealing with it, but they
  all also come with tools for dealing with .tgz. Some GNU/Linux distros
  use .rpm to distribute their software, but not all do. I don't think
  any Unix systems have adopted it; most of them have packaging systems
  that predate .rpm, and they're all different. Different package
  formats for vendor software isn't a GNU/Linux vs. FreeBSD or Unix
  thing, it's a fact of line in a multi-platform Unix environment.
 my reason for bringing the whole thing up was based on the idea
 that this person might be used to using *.rpm all the time

Well, maybe. But consider the context: they're looking at moving from
GNU/Linux to FreeBSD, so they're probably familiar with more than one
GNU/Linux distro, so there's a good chance they'ev seen more than just
rpms for system software distribution. Further, they're looking at
working on the FreeBSD code base, so they're a programmer, so there's
a good chance they've gone to the source sites for the packages
included in those distros, where they almost certainly would have
noticed that the binaries for other platforms weren't in rpms. Since
they're programmers, they've probably downloaded source distributions,
which are almost invariable tarballs of some sort or another.

In other words, the chances that they've only seen rpm file
distributions would seem to be vanishingly small, so there are things
that are far more likely to disrupt them - like the difference in
which system calls will work properly between fork() and exec() that
Posix() doesn't require to do so - that are still so unlikely to do so
to be worth mentioning in this context.

If you feel you have to mention it, then you should really talk about
the tools, not the formats: GNU/Linux distros tend to use rpm* or apt*
tools for installing and managing software packages, whereas FreeBSD
uses the pkg* tools.

 and this
 would be a difference he would experience moving to 
freeBSD, if
 this was the case.  if this is not the case for him, as you seem
 to be implying, then.. well.. still.. he must know to avoid
 *.rpm distributions in any case unless he installs a *.rpm compatibility
 tool.  is that part of the linux-compat stuff that freeBSD has?

Just out of curiosity, where do you expect to find software for
FreeBSD in an rpm format? I don't think they exist, so *avoiding* them
wont' be a problem. Possibly wasting time looking for them might be,
but again, that seems really unlikely given the context, so there are
more important things to suggest they not waste time on, like
wandering how they upgrade just part of the base system.

 mike
-- 
Mike Meyer [EMAIL PROTECTED]  http://www.mired.org/consulting.html
Independent Network/Unix/Perforce consultant, email for more information.
___
freebsd-hackers@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to [EMAIL PROTECTED]


Re: FreeBSD hacker 101

2008-01-27 Thread KAYVEN RIESE




On Sun, 27 Jan 2008, Mike Meyer wrote:

On Sat, 26 Jan 2008 15:55:53 -0800 (PST) KAYVEN  RIESE [EMAIL PROTECTED] 
wrote:

On Sat, 26 Jan 2008, Mike Meyer wrote:

On Sat, 26 Jan 2008 12:24:36 -0800 (PST) KAYVEN  RIESE [EMAIL PROTECTED] 
wrote:

On Sat, 26 Jan 2008, Dag-Erling Smørgrav wrote:

KAYVEN  RIESE [EMAIL PROTECTED] writes:




thing, it's a fact of line in a multi-platform Unix environment.

my reason for bringing the whole thing up was based on the idea
that this person might be used to using *.rpm all the time


Well, maybe. But consider the context: they're looking at moving from
GNU/Linux to FreeBSD, so they're probably familiar with more than one
GNU/Linux distro, so there's a good chance they'ev seen more than just
rpms for system software distribution. Further, they're looking at



noticed that the binaries for other platforms weren't in rpms. Since
they're programmers, they've probably downloaded source distributions,
which are almost invariable tarballs of some sort or another.

In other words, the chances that they've only seen rpm file
distributions would seem to be vanishingly small, so there are things
that are far more likely to disrupt them - like the difference in



i feel like i have noticed some sites that only have rpms.  this is
more like the type of serious concern that i was concocting in my
own tiny mind.  however, if you simply note that its part of the
linux compatibility packages, then my concern is absolutely
unfounded and i will shut up  {:}




If you feel you have to mention it, then you should really talk about
the tools, not the formats: GNU/Linux distros tend to use rpm* or apt*
tools for installing and managing software packages, whereas FreeBSD
uses the pkg* tools.


and this
would be a difference he would experience moving to

freeBSD, if

this was the case.  if this is not the case for him, as you seem
to be implying, then.. well.. still.. he must know to avoid
*.rpm distributions in any case unless he installs a *.rpm compatibility
tool.  is that part of the linux-compat stuff that freeBSD has?


Just out of curiosity, where do you expect to find software for
FreeBSD in an rpm format? I don't think they exist, so *avoiding* them
wont' be a problem. Possibly wasting time looking for them might be,
but again, that seems really unlikely given the context, so there are
more important things to suggest they not waste time on, like
wandering how they upgrade just part of the base system.

mike
--
Mike Meyer [EMAIL PROTECTED]http://www.mired.org/consulting.html
Independent Network/Unix/Perforce consultant, email for more information.



*--*
  Kayven Riese, BSCS, MS (Physiology and Biophysics)
  (415) 902 5513 cellular
  http://kayve.net
  Webmaster http://ChessYoga.org
*--*___
freebsd-hackers@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to [EMAIL PROTECTED]

Re: HLA v1.100 is now available for FreeBSD

2008-01-27 Thread Peter Jeremy
On Fri, Jan 25, 2008 at 05:06:56PM -0800, Randall Hyde wrote:
I am pleased to announce that HLA v1.100 and the HLA standard library
(v3.0) are now running natively under FreeBSD.  For those who are
unfamiliar with the product, HLA is a High Level Assembler for the
80x86. It allows you to write portable 80x86 code that runs under
Windows, Linux, or FreeBSD with nothing more than a recompile.

This looks like it might be interesting.

Two comments:
1) Is there a FreeBSD port available?
2) Do you have any plans to target anything other than 80x86?  HLA looks
   like it would be very handy as a development tool for embedded micros
   (PIC, Atmel etc).

-- 
Peter Jeremy
Please excuse any delays as the result of my ISP's inability to implement
an MTA that is either RFC2821-compliant or matches their claimed behaviour.


pgpRycZfGiLc5.pgp
Description: PGP signature


Re: 'periodic daily' memory usage

2008-01-27 Thread Bert JW Regeer


On Jan 27, 2008, at 05:55 , Dag-Erling Smørgrav wrote:

'periodic daily' runs my router out of swap every night, usually  
killing

named as a result.



From your email it sounds like you run bind in just a caching  
situation, have you looked at alternatives yet? For example dnscache  
from DJB, you give it a set amount of memory to use, and that is all  
it uses.



[...]

DES
--
Dag-Erling Smørgrav - [EMAIL PROTECTED]


Bert JW Regeer

Re: kstackusage() patch request for comments

2008-01-27 Thread Dag-Erling Smørgrav
Alexander Motin [EMAIL PROTECTED] writes:
 The main question I have is about source files and headers I should
 use for this specific purposes. Is it correct way to define function
 in machine independent header, but implement it in machdep.c? Or I
 should define it in machine dependent headers?

If you intend to implement the same functions on all platforms, the
prototypes should be in a machine-independent header.

DES
-- 
Dag-Erling Smørgrav - [EMAIL PROTECTED]
___
freebsd-hackers@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to [EMAIL PROTECTED]


Re: 'periodic daily' memory usage

2008-01-27 Thread Dag-Erling Smørgrav
Mike Bristow [EMAIL PROTECTED] writes:
 Dag-Erling Smørgrav [EMAIL PROTECTED] writes:
  An entirely different issue is why named uses so much memory...  does
  anybody know of a way to specify how much memory named may use for its
  cache?

 Something like :

 options {
directory   /etc/namedb;
pid-file/var/run/named/pid;
*max-cache-size 10485760;
 };

That made no difference.  It looked like it might at first, but after
just a few minutes RSS was back to 24 MB.

DES
-- 
Dag-Erling Smørgrav - [EMAIL PROTECTED]
___
freebsd-hackers@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to [EMAIL PROTECTED]


Re: FreeBSD hacker 101

2008-01-27 Thread Mohacsi Janos




On Sun, 27 Jan 2008, Mike Meyer wrote:


On Sat, 26 Jan 2008 15:55:53 -0800 (PST) KAYVEN  RIESE [EMAIL PROTECTED] 
wrote:




On Sat, 26 Jan 2008, Mike Meyer wrote:

On Sat, 26 Jan 2008 12:24:36 -0800 (PST) KAYVEN  RIESE [EMAIL PROTECTED] 
wrote:

On Sat, 26 Jan 2008, Dag-Erling Sm˙˙rgrav wrote:

KAYVEN  RIESE [EMAIL PROTECTED] writes:

.rpm is a package format, and comes with a tool set for using it. Most
(all?) GNU/Linux systems come with tools for dealing with it, but they
all also come with tools for dealing with .tgz. Some GNU/Linux distros
use .rpm to distribute their software, but not all do. I don't think
any Unix systems have adopted it; most of them have packaging systems
that predate .rpm, and they're all different. Different package
formats for vendor software isn't a GNU/Linux vs. FreeBSD or Unix
thing, it's a fact of line in a multi-platform Unix environment.

my reason for bringing the whole thing up was based on the idea
that this person might be used to using *.rpm all the time


Well, maybe. But consider the context: they're looking at moving from
GNU/Linux to FreeBSD, so they're probably familiar with more than one
GNU/Linux distro, so there's a good chance they'ev seen more than just
rpms for system software distribution. Further, they're looking at
working on the FreeBSD code base, so they're a programmer, so there's
a good chance they've gone to the source sites for the packages
included in those distros, where they almost certainly would have
noticed that the binaries for other platforms weren't in rpms. Since
they're programmers, they've probably downloaded source distributions,
which are almost invariable tarballs of some sort or another.

In other words, the chances that they've only seen rpm file
distributions would seem to be vanishingly small, so there are things
that are far more likely to disrupt them - like the difference in
which system calls will work properly between fork() and exec() that
Posix() doesn't require to do so - that are still so unlikely to do so
to be worth mentioning in this context.

If you feel you have to mention it, then you should really talk about
the tools, not the formats: GNU/Linux distros tend to use rpm* or apt*
tools for installing and managing software packages, whereas FreeBSD
uses the pkg* tools.



Not necessary to use pkg* tools on FreeBSD. You can use pkgsrc

http://www.pkgsrc.org/

or openpkg

http://www.openpkg.org/

All above are supported on multi-os environment.

Regards,

Janos Mohacsi
Network Engineer, Research Associate, Head of Network Planning and Projects
NIIF/HUNGARNET, HUNGARY
Key 70EF9882: DEC2 C685 1ED4 C95A 145F  4300 6F64 7B00 70EF 9882
___
freebsd-hackers@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to [EMAIL PROTECTED]