On Fri, 21 Oct 2011 00:54:32 -0700
Garrett Cooper wrote:
> On Fri, Oct 21, 2011 at 12:51 AM, Wojciech Puchar
> wrote:
> >> on entry into each function, which is different from usual x86
> >> convention.
> >> Asynchronous unwind info (yeah, same stuff you keep referring to as
> >> crap), is the o
that i do not want to debug isn't it?
It seems like a binutils bug (or somewhere in that immediate
neighborhood) because all debugging related sections should be
stripped out by strip including unwind, correct?
indeed.
___
freebsd-hackers@freebsd.org
On Fri, Oct 21, 2011 at 12:51 AM, Wojciech Puchar
wrote:
>> on entry into each function, which is different from usual x86
>> convention.
>> Asynchronous unwind info (yeah, same stuff you keep referring to as
>> crap), is the only way you can debug your program or get anything
>> remotely close to
on entry into each function, which is different from usual x86
convention.
Asynchronous unwind info (yeah, same stuff you keep referring to as
crap), is the only way you can debug your program or get anything
remotely close to usable backtrace, by default.
i understand but i DO NOT called compil
On Fri, 21 Oct 2011 00:20:52 +0200 (CEST)
Wojciech Puchar wrote:
> >> i both don't use C++ and don't want to debug when i am linking
> >> final binary.
> >>
> >> how to turn this off?
> >
> > Which compiler do you use?
>
> supplied with FreeBSD 8.2
> [wojtek@wojtek ~]$ cc -v
> Using built-in spe
On Fri, 21 Oct 2011 01:13:59 +0200 (CEST)
Wojciech Puchar wrote:
> >
> > -fno-asynchronous-unwind-tables should get rid of unwind
> > information, a.k.a. 'crap'.
> and this worked. found it just before getting your mail ;)
>
> yes and this is crap... possibly it is needed for some cases and some
-fno-asynchronous-unwind-tables should get rid of unwind information,
a.k.a. 'crap'.
and this worked. found it just before getting your mail ;)
yes and this is crap... possibly it is needed for some cases and some
languages and i would not call it crap if it would not be included by
default!
--remove-section .rel.eh_frame --remove-section .rela.eh_frame
$your_executable
After I done this, the binary size *increased* a lot, while objdump shows
that the content is less. I don't understand.
add -fomit-frame-pointer -fno-exceptions -fno-asynchronous-unwind-tables
-fno-unwind-t
After I done this, the binary size *increased* a lot, while objdump shows that
the content is less. I don't understand.
same for me
strip -R .eh_frame -R .eh_frame_hdr do the same.
___
freebsd-hackers@freebsd.org mailing list
http://lists.freebsd.o
this do the same that strip -R what i already tried and as i already
wrote - the same results.
program is working and sections are stripped but i am getting ca 1MB of
binary zero paddings.
___
freebsd-hackers@freebsd.org mailing list
http://list
i both don't use C++ and don't want to debug when i am linking final binary.
how to turn this off?
Which compiler do you use?
supplied with FreeBSD 8.2
[wojtek@wojtek ~]$ cc -v
Using built-in specs.
Target: amd64-undermydesk-freebsd
Configured with: FreeBSD/amd64 system compiler
Thread model:
On Thu, Oct 20, 2011 at 7:13 AM, Dimitry Andric wrote:
> On 2011-10-20 12:44, Wojciech Puchar wrote:
>
>> i both don't use C++ and don't want to debug when i am linking final
>> binary.
>>
>> how to turn this off?
>>
>
> objcopy --rem
On 2011-10-20 12:44, Wojciech Puchar wrote:
i both don't use C++ and don't want to debug when i am linking final
binary.
how to turn this off?
objcopy --remove-section .eh_frame_hdr --remove-section .eh_frame
--remove-section .rel.eh_frame --remove-section .rela.eh_frame $your_exec
on 20/10/2011 13:44 Wojciech Puchar said the following:
> i both don't use C++ and don't want to debug when i am linking final binary.
>
> how to turn this off?
Which compiler do you use?
--
Andriy Gapon
___
freebsd-hackers@freebsd.org mailing list
ht
i both don't use C++ and don't want to debug when i am linking final
binary.
how to turn this off?
On Thu, 20 Oct 2011, Joerg Sonnenberger wrote:
On Thu, Oct 20, 2011 at 09:41:24AM +0200, Wojciech Puchar wrote:
how to do this and what the hell it is used at all?
It is used to allow unwindi
On Thu, Oct 20, 2011 at 09:41:24AM +0200, Wojciech Puchar wrote:
> how to do this and what the hell it is used at all?
It is used to allow unwinding stack frames. That is required for
exception handling with C++ and also to allow debugging in the presence
of -fomit-frame-pointer, e.g. as used by d
how to do this and what the hell it is used at all?
i found somewhere it is some debugging info but i do not put -g option to
compiler while compiling and still get substantial amount of this trash.
trying strip -R .eh_frame -R .eh_frame_hdr results in working but
LARGER binary, padded with lo
Quoting Kurt Lidl (from Thu, 14 Jul 2011 10:06:45 -0400):
On Thu, Jul 14, 2011 at 01:22:49AM -0500, Zhihao Yuan wrote:
Second, the perl/tcl interpreter support; you can apply a perl/tcl
command to the file whiling you are editing. I beg no one here used
this feature before.
Bzzt. I've used t
Here is my introspection:
Q: Why drop DB3/4?
A: Licenses problem.
Q: Licenses problem matters?
A: It causes we can't accept nvi-1.8x in our base system.
Q: Why an editor in the base system?
A: Always accessible. Anywhere (SSH), any situation (inc. system crashes).
Q: Why not vim-lite/original-vi?
Before adding
> more features like file encoding detection, I want to remove some
> features in nvi.
>
> First, gtags mode. This feature was imported by
> http://lists.gnu.org/archive/html/global-commit/2005-01/msg2.html
> . There's no gtags in our base system, and I can&#x
On 7/14/11 1:07 PM, Zhihao Yuan wrote:
> I regards nvi as a trustful editor when you login into other ppl's
> machines.
Yes - this is the exact use case for Vi in my mind. If I needed features
I'd install vim. Come to think of it, since there is already a vim-lite
and vim port, why not make a logi
Both the guy and me failed to reply to the group. Let me forward it.
-- Forwarded message --
From: Zhihao Yuan
Date: Thu, Jul 14, 2011 at 3:58 AM
Subject: Re: [GSoC]I want to remove everything perl/tcl/gtags in the new nvi
To: Sebastian Chmielewski
On Thu, Jul 14, 2011 at 3
On Thu, Jul 14, 2011 at 01:22:49AM -0500, Zhihao Yuan wrote:
> Second, the perl/tcl interpreter support; you can apply a perl/tcl
> command to the file whiling you are editing. I beg no one here used
> this feature before.
Bzzt. I've used the perl interpreter before on a project.
In that case, we
gh iconv. Before adding
> more features like file encoding detection, I want to remove some
> features in nvi.
>
> First, gtags mode. This feature was imported by
> http://lists.gnu.org/archive/html/global-commit/2005-01/msg2.html
> . There's no gtags in our base system, and I c
Hi hackers,
I'm doing my GSoC project, "Multibyte Encoding Support in Nvi" at
https://github.com/lichray/nvi2 . Currently, the editor can support
read/display/write multibyte encoding through iconv. Before adding
more features like file encoding detection, I want to remove some
On 12.07.2011 11:10, Garrett Cooper wrote:
On Mon, Jul 11, 2011 at 11:16 PM, Alexander V. Chernikov
wrote:
Garrett Cooper wrote:
Hi,
While trying to determine how to print out routes via kvm for
net-snmp, I noticed that there's a chunk of code from the 4.4 BSD Lite
days that isn't execut
On Mon, Jul 11, 2011 at 11:16 PM, Alexander V. Chernikov
wrote:
> Garrett Cooper wrote:
>> Hi,
>> While trying to determine how to print out routes via kvm for
>> net-snmp, I noticed that there's a chunk of code from the 4.4 BSD Lite
>> days that isn't executed in netstat as NewTree is always
Garrett Cooper wrote:
> Hi,
> While trying to determine how to print out routes via kvm for
> net-snmp, I noticed that there's a chunk of code from the 4.4 BSD Lite
> days that isn't executed in netstat as NewTree is always 0. The
> following patch removes that dead code and gets the FreeBSD so
Hi,
While trying to determine how to print out routes via kvm for
net-snmp, I noticed that there's a chunk of code from the 4.4 BSD Lite
days that isn't executed in netstat as NewTree is always 0. The
following patch removes that dead code and gets the FreeBSD source for
netstat more in line wi
2011/7/2 Robert Millan :
> 2011/7/2 Benjamin Kaduk :
>> There is a functional difference between '-nostdinc -I/usr/include -I.' even
>> when the standard include search path is just /usr/include -- the standard
>> include paths are always searched last (unless -nostdinc is given), even if
>> they a
2011/7/3 Matthias Andree :
> Note that there are GCC-version-specific directories for the more
> intricate details such as stdarg.h and compiler-specific builtins -- you
> don't get those with -I/usr/include either.
I know. That's actually the problem I'm trying to solve ( not found).
--
Robert
Am 02.07.2011 17:25, schrieb Benjamin Kaduk:
> On Sat, 2 Jul 2011, Robert Millan wrote:
>
>> The userland aicasm utility in sys/dev/aic7xxx/aicasm/Makefile is being
>> built with "-nostdinc -I/usr/include" options. Unfortunately this breaks
>> building aicasm on systems using the upstream version
2011/7/2 Benjamin Kaduk :
> There is a functional difference between '-nostdinc -I/usr/include -I.' even
> when the standard include search path is just /usr/include -- the standard
> include paths are always searched last (unless -nostdinc is given), even if
> they are explicitly listed on the com
/usr/local/include replacing '.'.)
I have not checked whether this affects aicasm, though (which may or may
not manifest itself as compiler warnings).
-Ben Kaduk
This was introduced by obrien (CCed) in 2002, apparently to remove a
warning. I've verified that removing it d
d by
"-I/usr/include".
This was introduced by obrien (CCed) in 2002, apparently to remove a
warning. I've verified that removing it doesn't produce any warnings
on FreeBSD 9-CURRENT environment.
Please consider this patch to remove -nostdinc in that file.
--
Robert Milla
On 11/22/10, Andriy Gapon wrote:
> on 22/11/2010 01:18 Paul B Mahol said the following:
>> On Sun, Nov 21, 2010 at 9:17 PM, Andriy Gapon wrote:
>>> As is - this is a perfect candidate for a "local only" patch.
>>> To be included into the tree - this, most probably, has to be controlled
>>> by a
>
On Sun, Nov 21, 2010 at 10:18:13PM -0200, Carlos A. M. dos Santos wrote:
> On Sun, Nov 21, 2010 at 9:18 PM, Paul B Mahol wrote:
> > On Sun, Nov 21, 2010 at 9:17 PM, Andriy Gapon wrote:
> >> on 21/11/2010 13:07 Paul B Mahol said the following:
> >>> This patch removes printf which spams console wh
on 22/11/2010 01:18 Paul B Mahol said the following:
> On Sun, Nov 21, 2010 at 9:17 PM, Andriy Gapon wrote:
>> As is - this is a perfect candidate for a "local only" patch.
>> To be included into the tree - this, most probably, has to be controlled by a
>> tunable/sysctl.
>
> So solution for usel
this feature either, so feel free to MFC.
Doug
On 11/12/2010 17:19, Garrett Cooper wrote:
Hi,
ramdisk* hasn't been in place for quite a while now (I think since
the 5.x days when the mdconfig scripts were created). Could someone
please review and potentially commit this manpage update to
On Sun, Nov 21, 2010 at 9:18 PM, Paul B Mahol wrote:
> On Sun, Nov 21, 2010 at 9:17 PM, Andriy Gapon wrote:
>> on 21/11/2010 13:07 Paul B Mahol said the following:
>>> This patch removes printf which spams console whenever thermal state
>>> is changed in laptop. Source of problem is in buggy BIOS
On Sun, Nov 21, 2010 at 9:17 PM, Andriy Gapon wrote:
> on 21/11/2010 13:07 Paul B Mahol said the following:
>> This patch removes printf which spams console whenever thermal state
>> is changed in laptop. Source of problem is in buggy BIOS.
>>
>> diff --git a/sys/dev/acpica/acpi_thermal.c b/sys/de
on 21/11/2010 13:07 Paul B Mahol said the following:
> This patch removes printf which spams console whenever thermal state
> is changed in laptop. Source of problem is in buggy BIOS.
>
> diff --git a/sys/dev/acpica/acpi_thermal.c b/sys/dev/acpica/acpi_thermal.c
> index 515a742..00866b2 100644
> -
This patch removes printf which spams console whenever thermal state
is changed in laptop. Source of problem is in buggy BIOS.
diff --git a/sys/dev/acpica/acpi_thermal.c b/sys/dev/acpica/acpi_thermal.c
index 515a742..00866b2 100644
--- a/sys/dev/acpica/acpi_thermal.c
+++ b/sys/dev/acpica/acpi_ther
x27;t been in place for quite a while now (I think since
the 5.x days when the mdconfig scripts were created). Could someone
please review and potentially commit this manpage update to remove the
ramdisk* references from rc.conf(5)?
Thanks!
-Garrett
--
Nothin' ever doesn't cha
Hi,
ramdisk* hasn't been in place for quite a while now (I think since
the 5.x days when the mdconfig scripts were created). Could someone
please review and potentially commit this manpage update to remove the
ramdisk* references from rc.conf(5)?
Thanks!
-Garrett
Index: share/man/man5/rc
Yet another version of the patch, I hope the last one
http://people.freebsd.org/~bapt/update-libedit.patch
Everything should be working as it used to do before.
Now gdbtui is almost working. why almost because everything works
except Ctrl-D (EOF), I know where the bug is (lib/libedit/read.c :
func
Thanks all for your returns,
I'll update my patch during the next week.
Concerning the reverts I'll try to reintegrate them and then send them
to upstream, Because I think it is better to keep in sync to easier
futures updates.
regards,
Bapt
___
freebsd
Anonymous writes:
> Anonymous writes:
>
>> Baptiste Daroussin writes:
> [...]
>>> You can find the patch against current here:
>>> http://people.freebsd.org/~bapt/update-libedit.patch
>>
>> $ make depend
>> /usr/src/lib/libedit/makelist -h /usr/src/lib/libedit/vi.c > vi.h.tmp &&
>> mv vi
On Fri, Nov 05, 2010 at 04:32:56PM +0100, Baptiste Daroussin wrote:
> I've updated libedit to the latest version available in the netbsd cvs.
> UTF8 support is disabled for now has it seems to be experimental and segfault.
> I also patch and tested all the sources that used to be linked against
> l
Hi all,
I've updated libedit to the latest version available in the netbsd cvs.
UTF8 support is disabled for now has it seems to be experimental and segfault.
I also patch and tested all the sources that used to be linked against
libreadline so that it now uses libedit making libreadline unused (I
Hello,
A friend of me has submitted this PR and I promised him that I would
see if I could get it implemented. I couldn't find anybody directly
responsible for the ips/iprcm tools, so I throw it in here for
discussion.
>Description:
I've observed that linux apps running under the linuxulator
On Thursday 09 November 2006 14:33, Ed Schouten wrote:
> * Ed Schouten <[EMAIL PROTECTED]> wrote:
> > The patch below prevents this by performing this check by do_dup(). It
> > will prevent fcntl() from PROC_LOCK()'ing twice. It also fixes the
> > return value of fcntl(). The manual page states tha
* Ed Schouten <[EMAIL PROTECTED]> wrote:
> The patch below prevents this by performing this check by do_dup(). It
> will prevent fcntl() from PROC_LOCK()'ing twice. It also fixes the
> return value of fcntl(). The manual page states that it should return
> EMFILE when it exceeds its limit, though t
Hello,
I'm working on a project at school to develop a multimedia system (a la
Windows Media Center) based on FreeBSD. I was looking at some code in
sys/kern/kern_descrip.c to figure out how the fcntl() with F_DUPFD and
dup() differ.
I discovered that kern_fcntl() contains some redundant code. Ri
What do people think about adding an equivalent to
gtars --remove-files?
Shouldn't be too tricky. If you think you know
how to implement it, send me the diffs.
Doing this "safely" is nearly impossible, of
course. In the compressed case, the compression
pipeline buffer
Steven Hartland wrote:
What do people think about adding an equivalent to
gtars --remove-files?
Shouldn't be too tricky. If you think you know
how to implement it, send me the diffs.
Doing this "safely" is nearly impossible, of
course. In the compressed case, the compr
- Original Message -
From: "Roman Kurakin" <[EMAIL PROTECTED]>
In case one concerned by the space problem there is now other way to
do it failsafe.
In case it is gziped it need to be extracted first in any case.
Sorry dont follow you there? Are you talking about
issues of deleting the
Steven Hartland:
- Original Message - From: "Eric Anderson"
<[EMAIL PROTECTED]>
Some people on this list might argue that you could do this another
way, something like piping a tar extract to another tar create that
excludes that file.
Sure that can be done but its a PITA and majo
On 08/08/06 13:49, Steven Hartland wrote:
- Original Message -
From: "Eric Anderson" <[EMAIL PROTECTED]>
Some people on this list might argue that you could do this another way,
something like piping a tar extract to another tar create that excludes
that file.
Sure that can be done bu
- Original Message -
From: "Eric Anderson" <[EMAIL PROTECTED]>
Some people on this list might argue that you could do this another way,
something like piping a tar extract to another tar create that excludes
that file.
Sure that can be done but its a PITA and majorly slow
so a none opt
On 08/08/06 12:09, Steven Hartland wrote:
What do people think about adding an equivalent to
gtars --remove-files?
Its an option I find myself longing for on a regular
basis and hence end up installing gtar and using that
which kind of defeats the point of having bsd tar.
So what do people
What do people think about adding an equivalent to
gtars --remove-files?
Its an option I find myself longing for on a regular
basis and hence end up installing gtar and using that
which kind of defeats the point of having bsd tar.
So what do people think about adding this option?
Steve
On Thu, Feb 23, 2006 at 09:56:46AM +0200, Nikos Vassiliadis wrote:
> > Just use:
> >
> > netstat -rn | awk '$3 !~ /L/ { print }'
>
> That's exactly the point Eugene, I don't want to find ways to filter it out.
> It happens frequently. I didn&
On Friday 24 February 2006 15:24, Giorgos Keramidas wrote:
> On 2006-02-24 15:12, Nikos Vassiliadis <[EMAIL PROTECTED]> wrote:
> >On Friday 24 February 2006 15:04, Giorgos Keramidas wrote:
> >>On 2006-02-24 15:00, Giorgos Keramidas <[EMAIL PROTECTED]> wrote:
> >>> Unfortunately, the -s option is ta
don't want to find ways to filter it
> > out. It happens frequently. I didn't say it's difficult to remove it, I
> > just don't want it there all the time. That's why you can use -a to get
> > the old behavior.
>
> Just make ~/bin/netstat that will filter
On 2006-02-24 15:12, Nikos Vassiliadis <[EMAIL PROTECTED]> wrote:
>On Friday 24 February 2006 15:04, Giorgos Keramidas wrote:
>>On 2006-02-24 15:00, Giorgos Keramidas <[EMAIL PROTECTED]> wrote:
>>> Unfortunately, the -s option is taken already. It enables the display
>>> of statistics. A possible
On Friday 24 February 2006 15:04, Giorgos Keramidas wrote:
> On 2006-02-24 15:00, Giorgos Keramidas <[EMAIL PROTECTED]> wrote:
> > Unfortunately, the -s option is taken already. It enables the display
> > of statistics. A possible alternative is the -c (compact) option,
> > i.e. with a patch simi
On 2006-02-24 15:00, Giorgos Keramidas <[EMAIL PROTECTED]> wrote:
> Unfortunately, the -s option is taken already. It enables the display
> of statistics. A possible alternative is the -c (compact) option,
> i.e. with a patch similar to the following:
>
> [...]
I forgot to show sample output, so
On 2006-02-24 11:32, Nikos Vassiliadis <[EMAIL PROTECTED]> wrote:
>On Thursday 23 February 2006 20:24, Giorgos Keramidas wrote:
>>
>> ... about using a switch to shorten the netstat output (by not
>> displaying the link-layer entries):
>>
>> How about making the new behavior non-default, i.e. toggl
On Wed, Feb 22, 2006 at 03:50:17PM +0200, Nikos Vassiliadis wrote:
> netstat -r prints link-layer generated routes and many
> times the output becomes somehow obscure. For
> example:
>
> [EMAIL PROTECTED]:0:/usr/home/src/FreeBSD-6/src/usr.bin/netstat# netstat
> -ranfinet
> Routing tables
>
> In
FlagsRefs Use Netif
> >>>>>Expire default10.1.1.244 UGS 031016
> >>>>>rl0 10.1.1/24 link#1 UC 00
> >>>>> rl0 127.0.0.1 127.0.0.1 UH 0 111
00
> > > > fxp0 [EMAIL PROTECTED]:0:/usr/home/src/FreeBSD-6/src/usr.bin/netstat#
> > > >
> > > >
> > > > The attachment patch ("cvs diff -u -rHEAD route.c" generated) prints
> > > > link-layer generated routes whe
agsRefs Use Netif
>>>>>Expire default10.1.1.244 UGS 031016
>>>>>rl0 10.1.1/24 link#1 UC 00rl0
>>>>>127.0.0.1 127.0.0.1 UH 0 1117lo0
>>>>
f the time.
Thoughts? POLA violation?
Just use:
netstat -rn | awk '$3 !~ /L/ { print }'
That's exactly the point Eugene, I don't want to find ways to filter it out.
It happens frequently. I didn't say it's difficult to remove it, I just don't
want it there a
.1 link#5 UC 00 fxp0
> > > [EMAIL PROTECTED]:0:/usr/home/src/FreeBSD-6/src/usr.bin/netstat#
> > >
> > >
> > > The attachment patch ("cvs diff -u -rHEAD route.c" generated) prints
> > > link-layer generat
erated routes when -a is specified and ignores them
> > the rest of the time.
> >
> > Thoughts? POLA violation?
>
> Just use:
>
> netstat -rn | awk '$3 !~ /L/ { print }'
That's exactly the point Eugene, I don't want to find ways to filter it out.
It h
Hi,
netstat -r prints link-layer generated routes and many
times the output becomes somehow obscure. For
example:
[EMAIL PROTECTED]:0:/usr/home/src/FreeBSD-6/src/usr.bin/netstat# netstat
-ranfinet
Routing tables
Internet:
DestinationGatewayFlagsRefs Use Netif Expir
Daniel Eischen wrote:
On Tue, 3 Jan 2006, Scott Long wrote:
for a bit if the current lock owner is running on another CPU?
Do we currently do that?
(*) No, I am not referring to spin mutexes.
Adaptive mutexes are enabled by default and have been for at least a
year.
Ahh, then that's wh
On Tue, 3 Jan 2006, Scott Long wrote:
> > for a bit if the current lock owner is running on another CPU?
> > Do we currently do that?
> >
> > (*) No, I am not referring to spin mutexes.
> >
>
> Adaptive mutexes are enabled by default and have been for at least a
> year.
Ahh, then that's what they
Daniel Eischen wrote:
On Tue, 3 Jan 2006, John Baldwin wrote:
On Sunday 01 January 2006 02:21 am, prime wrote:
Hi hackers,
I have an idea about remove the kernel option MUTEX_WAKE_ALL.
When we unlock the mutex(in _mtx_unlock_sleep),we can directly
give the lock to the first thread
On Tue, 3 Jan 2006, John Baldwin wrote:
> On Sunday 01 January 2006 02:21 am, prime wrote:
> > Hi hackers,
> >I have an idea about remove the kernel option MUTEX_WAKE_ALL.
> >When we unlock the mutex(in _mtx_unlock_sleep),we can directly
> > give the lock to
On Sunday 01 January 2006 02:21 am, prime wrote:
> Hi hackers,
>I have an idea about remove the kernel option MUTEX_WAKE_ALL.
>When we unlock the mutex(in _mtx_unlock_sleep),we can directly
> give the lock to the first thread waiting on the turnstile.And a
> thread gets the
Hi hackers,
I have an idea about remove the kernel option MUTEX_WAKE_ALL.
When we unlock the mutex(in _mtx_unlock_sleep),we can directly
give the lock to the first thread waiting on the turnstile.And a
thread gets the mutex after he returned from turnstile_wait so he
can simply jump out the
Hi,
I am about to write a special display driver, which should be something
like a framebuffer device, in terms of FreeBSD.
I whould like to make this driver from at the beginning MPSAFE, but I am
not sure that this is possible. Looking at some devices in sys/dev/fb and
sys/dev/syscons there are
On Mon, Jul 18, 2005 at 09:44:35PM +0930, Daniel O'Connor wrote:
> There is always a trade off but it seems most people don't think Heimdal is
> insecure enough to disable by default. (Has it has any bugs that have been
> exploitable in an unused configuration recently? I don't believe so).
In t
On Mon, 18 Jul 2005, Vladimir Terziev wrote:
The problem is that third party software is a part of basic software,
which functionality includes authentication and authorization for host
access. A bug in this third party software could become a reason for a
host compromise even the functional
On Monday 18 July 2005 21:14, Vladimir Terziev wrote:
>The problem is that third party software is a part of basic software,
> which functionality includes authentication and authorization for host
> access. A bug in this third party software could become a reason for a host
> compromise even t
The problem is that third party software is a part of basic software, which
functionality includes authentication and authorization for host access. A bug
in this third party software could become a reason for a host compromise even
the functionality of the third party software in not used (
On Monday 18 July 2005 18:03, Vladimir Terziev wrote:
>your right about useless things, but making basic software to depend on
> these useless things is a very bad idea. I'm sure, telnet & ssh are the
> most used applications on any UNIX system, so they must not depend on any
> third party soft
Vladimir Terziev <[EMAIL PROTECTED]> writes:
Hi.
> i'm sure most of the FreeBSD users do not need kerberos for
> authnetication.
Could you give me your fortune teller crystal ball brand ?
> If someone needs telnet+kerberos, then ok, such meta port could be
> created and this person will
nctionality. One wouldn't use
> it, for other
> person it is necessary. Again, for generic system it is normal to have
> extra functionality.
> If we remove it, many persons would suffer from that. If you do not need
> it, just do
> not use it. And all one would be happy.
on it is necessary. Again, for generic system it is normal to have
extra functionality.
If we remove it, many persons would suffer from that. If you do not need
it, just do
not use it. And all one would be happy.
It is not a problem to depend on kerberos till it isn't removed.
The worse t
; rik
>
> > Vladimir
> >
> >
> >On Sun, 17 Jul 2005 22:02:04 +0930
> >"Daniel O'Connor" <[EMAIL PROTECTED]> wrote:
> >
> >
> >
> >>On Sunday 17 July 2005 02:26, Dominic Marks wrote:
> >>
&
inic Marks wrote:
In /etc/make.conf put
NO_KERBEROS=yes
Then build a new world. That should do the trick.
This won't remove it, it will just not update it.
You would have to delete it by hand.
Telnet/ssh/etc don't have to depend on Kerberos and if you use the above
optio
On Sunday 17 July 2005 22:16, Vladimir Terziev wrote:
> Yes, i deleted it along with all libs related to it. This caused
> telnet/ssh/etc to stop working. So i rebuilt the world with NO_KERBEROS=yes
> and now all is like a charm -- no Heimdal Kerberos and no software
> depending on it. I think
inic Marks wrote:
> > In /etc/make.conf put
> >
> > NO_KERBEROS=yes
> >
> > Then build a new world. That should do the trick.
>
> This won't remove it, it will just not update it.
> You would have to delete it by hand.
>
> Telnet/ssh/etc don't h
On Sunday 17 July 2005 02:26, Dominic Marks wrote:
> In /etc/make.conf put
>
> NO_KERBEROS=yes
>
> Then build a new world. That should do the trick.
This won't remove it, it will just not update it.
You would have to delete it by hand.
Telnet/ssh/etc don't have to depe
On Saturday 16 July 2005 17:43, Vladimir Terziev wrote:
> Hi,
>
> i've just installed a fresh FreeBSD 5.4 on my PC i saw i have
> Heimdal Kerberos installed on it. I don't want Heimdal Kerberos on my
> syetem! Could someone point me to a easy way to remove it a
Vladimir Terziev wrote:
> > Hi,
> >
> > i've just installed a fresh FreeBSD 5.4 on my PC i saw i have
> > Heimdal Kerberos installed on it. I don't want Heimdal Kerberos on my
> > syetem! Could someone point me to a easy way to remove it and rebuild
>
Hi,
i've just installed a fresh FreeBSD 5.4 on my PC i saw i have Heimdal
Kerberos installed on it. I don't want Heimdal Kerberos on my syetem!
Could someone point me to a easy way to remove it and rebuild all
software (telnet, ssh, etc) which dep
1 - 100 of 147 matches
Mail list logo
