stands. I'm genuinely curious
to know how (or if) people still use atime.
--lyndon
ed or needed atime for *anything*. And
over that time period I have been responsible for running hundreds
of UNIX servers.
I'm really interested in hearing from people who actively use
atime on a regular basis for non-trivial purposes. What are
the modern use cases for atime?
--lyndon
t. For those
that must have it, /var/mail can be carved out as a distinct
filesystem and mounted appropriately.
--lyndon
ect the background noise
from people port scanning you and attempting other nefarious deeds.
--lyndon
ble to
include properly typeset manpages with the course documentation
(especially reflecting our local modifications to the systems) made me ...
grumpy.
--lyndon
___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/free
r/man, because, back in the day, running nroff on demand was slow.
Even on a 785. (catman without nroff would have been a no-op.)
--lyndon
___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubsc
Same as it is now for releases. Packages will be available for SAs/ENs.
There is no intention to change this model.
I get that. But the dependency base will be huge. Right now I can count on
a very limited set of dependencies for anything I ship as a 3rd party
package. Doing that for n>100 p
Here's a real example.
I have n Centos servers. Cron, once or twice a day, updates our local
cache of the yum repos. Then nagios comes along and flags 35 packages out
of date.
An hour later, management comes along asking questions about the security
implications of those packages. An hour l
n about this. But the
blowback is incredible. Let alone incredulous.
--lyndon
___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
f time ...
So no matter what the good intentions, this is going to impact everyone,
like it or not.
--lyndon
___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to &
.g.,
the dev stuff (cc, yacc, lex) could be split off, but at least include
the headers that match what's in /lib and /usr/lib, in a compiler
agnostic set. Since the point of packages is to allow for selections of
optional software.
--lyndon
___
m really asking is: where is the peer reviewed research
that shows this actually improves things for the not-1% of FreeBSD users?
--lyndon
P.S. Don't turn this into a pissing match. I really want to know how
this is of net benefit to everyone. But I don't want hyperbole. I have
test all the viable combinations for one single release.
If fact, I would suggest a good metric for package granularity be based
on the set of combinations that *can* be tested in a realistic timeframe
for each release.
--lyndon
___
freebsd-current@free
e cost of
DOA/warranty drives into our operational budget. They never get RMAed. We
drill them when they die.
--lyndon
signature.asc
Description: Message signed with OpenPGP using GPGMail
k the paranoia
might be a bit overdone in this case.
--lyndon
signature.asc
Description: Message signed with OpenPGP using GPGMail
On Thu, 7 May 2015, Pedro Giffuni wrote:
Unfortunately I don't use RCS enough (it looks like I should though) so
I am not in a good position to take the next step and deal with any
fallout it may produce.
If we can have a build-knob to disable GNU RCS and enable the new one I
will happily twi
Beware that they (DO) do not at all grok ipv6. They hand out /124s, or
something equally silly.
signature.asc
Description: Message signed with OpenPGP using GPGMail
On Sep 12, 2014, at 3:55 PM, Bryan Drewery wrote:
> There already is one and ports requires using it!
Doh!
signature.asc
Description: Message signed with OpenPGP using GPGMail
are exposed to MacOS X and Linux on desktops.
Given the rigid nature of shebangs to begin with, it's really not that hard to
write a sed command that will capture all instances of '#!.../bash[ foo]' and
wire in an appropriate value of '...'.
In fact, this
nd call it a day. It's not like the shell source code is changing every other
week, even for bash.
--lyndon
signature.asc
Description: Message signed with OpenPGP using GPGMail
D
10.x pf, that doesn't seem to be an issue.
--lyndon
signature.asc
Description: Message signed with OpenPGP using GPGMail
On Feb 27, 2014, at 15:59, Matthew Rezny wrote:
> If they corrected that, it was after I abandoned the platform years ago.
It has been like that since at least 10.8.
And I am also tempted to say that Windows 7 acts the same, but I don't have one
at hand to double check.
_
the while it continues its attempts
to renew the DHCP lease and, once successful, removes the 169.254.x.y address
from the interface.
--lyndon
signature.asc
Description: Message signed with OpenPGP using GPGMail
ernal system, which we
then rsynced to a USB drive, marched inside, and rsynced to the fileserver.
Not pretty ... but with all the distfiles at hand we knew the inside ports
builds wouldn't fail due to missing dependencies.
--lyndon
signature.asc
Description: Message signed with OpenPGP using GPGMail
ckage serves
nobody. (Yes, I exaggerate to make a point.)
--lyndon
signature.asc
Description: Message signed with OpenPGP using GPGMail
On Feb 24, 2014, at 7:40 AM, Bryan Drewery wrote:
> Anything not meeting the bare-bones criteria can be installed with 'pkg
> install' or ports.
Try this in a shop where all your machines are completely air-gapped from the
internet.
signature.asc
Description: Message signed with OpenPGP usin
ents to enable it?
It’s un-necessarily complicated. The package manifest can specify both
locations for the crontab file. If the copy isn’t made, at package removal the
worst that will happen is a warning diagnostic will be printed about the
missi
On Nov 7, 2013, at 19:41, Allan Jude wrote:
> it really depends on the port and what the cron
> is doing.
Why? Can you give some specific examples?
___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
On Nov 7, 2013, at 9:13, Allan Jude wrote:
> Right. The best way to handle this is likely to have the ports install
> the example cron to ${PREFIX}/share/portname/ or wherever else they
> normally put examples, with instructions in the pkg-message on how to
> enable the cron. The same way that p
(8)s dispatch control as a set of shell functions. That's
just silly.
--lyndon
___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
login class, and
perhaps capsicum capabilities. Actually, the latter two features are useful in
the general case. Regardless, the core idea is both sound and useful.
--lyndon
___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.or
g to believe that, and
unknowingly put themselves in a position where Bad Things could happen. Until
zfsd goes into the tree, zpool(8) should have a warning that the hot spare
functionality is not available under FreeBSD.
Proposed diff attached.
--
n, and is very low maintenance code. /usr/src/gnu/usr.bin/rcs
has been modified four times in the last decade. Two of those changes were
sweeping Makefile updates that affected much more than RCS. Of the other two,
only one update touched the actual code, and that
tached to an internal file
server, and its /usr/ports rsynced to the file server's /usr/ports.
Not pretty, but it got the job done. But that /usr/ports tree is way too big
to fit on a DVD. In fact, it might even be too large for a BD-ROM. (I don't
have access to the file serv
On 2013-10-07, at 8:15 PM, Steve Kargl
wrote:
> Maybe there was no development for 15 years. However, the 7364
> lines in ChangeLog after 2010-02-04 suggests that there may
> be few bugs to worry about.
Dear Troll,
Demonstrate one.
___
freebsd-cu
Okay folks, can we make a call about keeping the RCS tools in the base?
The proponents wanting to remove RCS need to speak up and make their technical
case.
--lyndon
___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman
On 2013-10-07, at 6:05 PM, Lyndon Nerenberg wrote:
> I don't see any discussion as to why the code (CVS, in this case) *needs* to
> be removed.
My stupidity: I meant RCS, not CVS.
___
freebsd-current@freebsd.org mailing list
http://lists.
On 2013-10-07, at 5:58 PM, Ian Lepore wrote:
> I have not re-read those threads to see just how much of the discussion
> involved rcs, I just spot-checked a few and confirmed my memory that it
> showed up in some of the messages there.
I don't see any discussion as to why the code (CVS, in this
luded.)
And the new scheme should provide something as simple as 'ci -l foo'. I'm not
convinced svn does that.
--lyndon
___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To uns
e
mailing lists. Slow and dumb (in the media-rich sense), but everyone knows
what's going on.
In that light, if there is a rational argument for pulling RCS out of the base,
propose it here on the -current list and let's all discuss it.
--lyndon
__
y apologize.
--lyndon
___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
On 2013-10-07, at 3:45 PM, Lyndon Nerenberg wrote:
> Having RCS in the base system is very useful. We use it to track changes to
> bits of /etc on the machines where we don't do wholesale customizations.
> (Those ones get git, but they also get an install of /usr/port
On 2013-10-07, at 2:53 PM, David Chisnall wrote:
> Or do you really only run the base OS and no other software on your systems,
> without any of your own code or any customisation?
We install from the base release ISO images burned on DVDs.
We are physically air-gapped from the internet, none
On 2013-10-07, at 2:08 PM, Lyndon Nerenberg wrote:
> And sorry, what I left out was how having ci/co in the base is immensely
> helpful with the installer scripts I write. The server installation scripts
> I've cooked up use ci(1) to keep a record of changes made during th
On 2013-10-07, at 2:02 PM, Lyndon Nerenberg wrote:
> I use ci/co every single day to track changes to individual config files on
> individual machines. For simple things like ntp.conf, rc.conf, sysctl.conf,
> a simple 'ci -l xxx' is a trivial way to maintain local rev
'ci -l xxx' is a
trivial way to maintain local revision control.
For small stand-alone systems, RCS is more than adequate. Why ditch it?
--lyndon
___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-
On 2013-04-29, at 8:27 PM, Teske, Devin wrote:
> http://www.youtube.com/watch?v=SXmv8quf_xM
>
> (Please, don't be drinking anything.. I disclaim all responsibility
> for keyboard damage)
Please, PLEASE, can we have a "Where Are They Now" segment about this kid? I
want to know which company he
or someone
with an @freebsd friend who will vouch for them). I will pay for any
reasonable shipping charges.
--lyndon
___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail
Speaking of throwing hardware at people, I have a couple of Sun V100s that
could go to a good home for FreeBSD Sparc development purposes. They come
equipped with 1GB of RAM and a pair of 80GB disks. If anyone can make a
legitimate case for them, drop me a note.
--lyndon
Isn't this about user choice, and making sensible defaults?
There are two or three "users" out of thousands complaining about the
default. If the extra build time bugs you that much, I'll contribute
towards buying you better build hardware, too.
__
ss in a few hundred bucks to help Max buy a
faster build machine.
--lyndon
___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
ink profiling is truly useless in this day and age, the
proposal should be to eradicate it from the system entirely.
--lyndon
___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Using profiled libs and gprof to profile your code has been obsolete
in FreeBSD on i386 and amd64 for over six years now.
Funny, it still seems to work on my systems.
___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinf
w how to do that.
--lyndon
___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
f our
userbase than 'Max', so sensible defaults for them are more appropriate,
right?
--lyndon
___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
builds.
If you choose not to profile your code, that's entirely your choice.
Breaking this functionality for everyone else who *does* make the effort
to profile their code is a non-starter.
--lyndon
___
freebsd-current@freebsd.org mailing list
Methinks your $TERM is set incorrectly.
___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
mes"
dance. It's not like people will do this often enough that the
pain will be fatal. And if it is, they ought to be bright enough to
know how to automate the process.
--lyndon
___
freebsd-current@freebsd.org mailing list
http://lists.freeb
... and it's not going to get any better till someone steps up and volunteers
to improve it. Can we count on you?
I've brought this up at least three times over the past 10(+?) years, and
been blown off every time. So yes, I'm volunteering, again. Can I count on
imdal distribution moot these days?
Beyond that, Free is one of the few UNIXen I cannot talk to (or from!)
using Kerberos for things like SSH, rlogin, rdist, etc. We're woefully
behind Solaris, Linux, even Windows, when it comes to integrated GSSAPI/K5
SSO authentication.
sole will already know how to use
ed(1).
--lyndon
___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "[EMAIL PROTECTED]"
--On Wednesday, November 19, 2003 12:30 AM -0500 Garance A Drosihn
<[EMAIL PROTECTED]> wrote:
have a: chflags ldcache /bin/sh
Shouldn't that be 'chmod +t /bin/sh' ???
--lyndon
___
[EMAIL PROTECTED] mailing list
http://list
would fix the issue, but it has not. Is there any other way to get this
> object?
The simple fix:
1) teach your MUA to insert line breaks at reasonable places, and
2) ln /usr/lib/libintl.so.4 /usr/lib/libintl.so.5
--lyndon
___
[EMAIL PROTECTED] ma
lternative implementation, the
code is at ftp://orthanc.ab.ca/lyndon/freebsd/usr.sbin/adduser/. It's
functional, but still needs edge case testing and some code cleanup.
--lyndon
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message
wasn't going to say anything until I had rmuser done as well
(it's not, yet). If people are interested I clean up the adduser
part and put it up for FTP. (FWIW, my version front-ends pw, and
takes it's policy from pw.conf.)
--lyndon
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message
exists (things that want to mess with modems, like FAX software).
It makes more sense to (perhaps) mention 'uucp' is a deprecated
login, but until *BSD defines an "official" interface to the
dialer devices, it would be premature to remove the existing
de-facto interface to them (
here's no conflict here; anything
that stops working after a "make install" scrubs /usr/include is
itself broken.
--lyndon
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message
Danny> And a list of files to delete would have saved many emails
Danny> about the GCC being broken when the old headers just needed
Danny> to be deleted.
We could add 'rm -rf /usr/include/*' at a suitable point inside
the installworld target.
--lyndon
To Unsubs
findstale script that wraps this might be a useful adjunct to
mergemaster.) I use /bin/cat as a timestamp file for rough analysis
purposes.
--lyndon
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message
>perl -pi.hold -e 's/FOO/BAR/g' ${WRKSRC}/a/b/{X,Y}
> is not as easy to do with `ed'.
It's not *that* hard. 10 lines of shell script is preferable to
XX MB of perl bloat. Especially for this sort of problem.
--lyndon
To Unsubscribe: send mail to [EMAIL PR
>>>>> "Ade" == Ade Lovett <[EMAIL PROTECTED]> writes:
Ade> Because not everyone using the ports system has the in-place
Ade> editing feature of sed that was recently added, and thus it
Ade> needs to be conditional on ${OSVERSION}.
Why can&#
> "Jonathan" == Jonathan Perkin <[EMAIL PROTECTED]> writes:
Jonathan> An auto-configuration script which merely checks for the
Jonathan> existance of a file rather than actually testing it's the
Jonathan> file it needs is a bit silly and probably deserves the
Jonathan> breakag
ocal.
There is one problem with the /usr/bin/perl redirector: it can cause
autoconfiguration scripts to mistakenly think perl is installed on the
system (they find the /usr/bin/perl wrapper) when it isn't (there is no
perl-from-ports backing the redirector).
--lyndon
To Unsubscribe: send m
oot on my firewalls if I can avoid it).
Programs like snort can attempt to lose uid-0 after opening the bpf
device, but others like tcpdump do not.
As David Wolfskill mentioned in a previous message, this idea is the
same as how the operator group is used for dump. kmem did the same
thing for ps an
sticky across
reboots, anyway). If the OS sets the access policy there cannot be any
confusion.
--lyndon
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message
t
requirement for an effective user of root. I've been running this way
on many of our servers for several months now, and things like snort,
tcpdump, etc., are quite happy with it (under stable).
--lyndon
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message
> "David" == David W Chapman <[EMAIL PROTECTED]> writes:
David> Sometimes things get changed and then backed out to their
David> original state, but you cannot keep the original RCSID
I can see that happening on the head, but this also happens
on stable ...
To Unsubscribe: send mail
ing large numbers of machines. If there's a
simple fix to the problem (at the source), let's work on it.
--lyndon
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message
should be built as part of the freebsd-uucp
port, or become a port unto itself.
--lyndon
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message
ing to contribute?
As much as it takes.
--lyndon
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message
ng is being
done to address the actual problem. I.e., people are going out of
their way to see the problem NOT get fixed. There's an issue of
principal at stake here, and I really don't like the precedent that
is being set by this move.
--lyndon
Never hit a man with glasses. Hit hi
l be build and you can install
> it whenever you need it.
jot, lam, colldef, lkbib, xstr, bikeshed.
> If you don't need it - which is the by far most common case - you
> don't want to see such a critical and unmaintained software installed.
How can it be both unneeded and
impact of that fix is
a lot lower than ripping out UUCP altogether.
--lyndon
We've heard that a million monkeys at a million keyboards could produce
the Complete Works of Shakespeare; now, thanks to the Internet, we know
this is not true.
-- Robert Wilensky,
it is, rather than making up specious excuses for it's removal.
--lyndon
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message
ng a wee bit fuzzy.)
> Certainly, anonymous uucp is more secure than
> anonymous ftp.
For the server. The client side of the copy could definately use
some work.
--lyndon
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message
her than reality.
UUCP still gets used. It's one of the few sane ways to handle email in
a laptop environment when you're always connecting through different
dialups/ISPs. It has mostly fallen out of favour due to ignorance and
FUD. Which is a shame, as it can still be a useful tool in certa
ever* allow remote site UUCP
logins (those that run uucico) under the `uucp' login, for obvious
security reasons. Instead, create seperate unique logins for each
remote site, just as you would for each of your shell accounts, but
set the login shell to uucico.
--lyndon
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message
ommit the fix in bin/18550. And get rid of the needlessly verbose
usage message ipfw spits out when it fails to parse a command. It
would be a lot more useful if ipfw printed (only) the failed command.
At least I might have a chance of seeing what the error is, instead of
having the usage message cau
ftware that semi-automates OTP logins,
and that software expects the otp-* commands to be on the remote system.
The opiekey(1) manpage also mentions the otp-* commands by name.
--lyndon
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message
to satisfy.
It's not a big deal for me. I just get annoyed at all the seemingly
gratuitous incompatibilities between the different versions of
something as fundamental as make.
--lyndon
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message
is at least load (a floating-point number). With no
argument, removes a previous load limit.
Maybe this should instead be a -d sub-option?
And I like the idea of adding the -l functionality described above.
--lyndon
To Unsubscribe: send mail to [EMAIL PROTECTED]
with
Could someone with commit privs please take a look at bin/14911? I'd
really appreciate it if that could get committed, and MFC'd into
RELENG_4. Also, bin/6997 has been aging away for quite some time as
well.
Thanks,
--lyndon
To Unsubscribe: send mail to [EMAIL PROTECTED]
with &q
ricky when the program crashes. Remember that a bug-free application
can still crash due to buggy shared-libraries.
I'm too lazy to look right this second ;-) ... do atexit() functions get
run when a process takes (say) a segmentation fault?
--lyndon
To Unsubscribe: send mail to [EMAIL PRO
LINT has an entry for an 'awe' device, however there doesn't appear
to be any corresponding source code in the tree. Is this device dead?
If so, the entry should be removed from LINT, or an appropriate
comment added.
--lyndon
To Unsubscribe: send mail to [EMAIL PROTECTED]
wi
ion for commercial software (in the US) is to
license the BSAFE libraries from RSA.
--lyndon
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message
much hosed, anyway.
Garrett> Think ``single-user mode''.
In single user mode you're root by definition. If init wants roots
password before going single user it can certainly go directly to the
password file. (It's really no different than if you're serving up
p
he daemon from there in wait mode.
If inetd dies you're pretty much hosed, anyway.
--lyndon
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message
ties for DoS attacks, but the
Mark> daemon talks only to a Unix Domain Socket, so finding the
Mark> perp is easy.
Not if the daemon has shut itself off due to load (#1 or #2 above) and you
aren't currently logged in to the box.
--lyndon
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message
telinit
Peter> to init.
Named sockets work well for this sort of control channel.
--lyndon
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message
es there
BSDman> in.
This is particulary useful in a lab environment where you have xx
workstations with local root, var, and swap NFS mounting an RO /usr.
--lyndon
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message
1 - 100 of 117 matches
Mail list logo
