> "Mark" == Mark Murray <[EMAIL PROTECTED]> writes:
Mark> o A username may only be checked $number times per
Mark> $timeperiod; after that, _all_ answers are silently
Mark> converted to "no".
Umm, massive DOS hole.
Mark> o Daemon may only be invoked $number times per $timepe
> "Garrett" == Garrett Wollman <[EMAIL PROTECTED]> writes:
Garrett> And what happens when the daemon is dead, has crashed, or
Garrett> was never started?
You incorporate my patches to inetd that teach it to listen on
named sockets, and then run the daemon from there in wait mode.
If
> "Garrett" == Garrett Wollman <[EMAIL PROTECTED]> writes:
>> You incorporate my patches to inetd that teach it to listen on
>> named sockets, and then run the daemon from there in wait mode.
>> If inetd dies you're pretty much hosed, anyway.
Garrett> Think ``single-user mode
> "Christian" == Christian Weisgerber <[EMAIL PROTECTED]> writes:
Christian> Commercial users need to get
Christian> an explicit license from RSA Inc., which from what I
Christian> hear you can't get in practice.
Correct. The only option for commercial software (in the US) is to
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]
with "unsubscribe free
> "John" == John Polstra <[EMAIL PROTECTED]> writes:
John> Applications need to clean up after themselves. The OS has
John> no way of knowing whether an application wants its shared
John> memory segments to survive after it terminates.
Tricky when the program crashes. Remember t
> "Gary" == Gary Palmer <[EMAIL PROTECTED]> writes:
Gary> There are two `standards' from SMTP Auth out there ... one
Gary> by Netscape (which is that rfc), and one by M$. To date,
Gary> only Netscape 4.5 and higher (I believe), and products from
Gary> Software.com (i.e. Inter
> "Matthew" == Matthew Dillon <[EMAIL PROTECTED]> writes:
Matthew> Why don't we get rid of the 'e' option to ps while we
Matthew> are at it considering how much of a security hole it is.
I wouldn't nuke it completely. Make -e a noop unless the real uid ps
is running with matches
> "David" == David Malone <[EMAIL PROTECTED]> writes:
David> I guess it goes with the "stop ps showing the environment"
David> changes. If you remove one it makes sense to remove the
David> other.
After you verify that this change isn't going to break things that
assume they can
> "Dieter" == Dieter Rothacker <[EMAIL PROTECTED]> writes:
Dieter> Why would you want to define "correct" numbering the
Dieter> non-spread-out numbering? Or did I misunderstand you? I
Dieter> have all my disks as master drives on the channels. Now,
Dieter> when I hook up anot
> "Adam" == Adam <[EMAIL PROTECTED]> writes:
Adam> As I understand it, cam or pre-cam or wd or ata it is simply
Adam> an issue of defaults. If you plan to use disks that die or
Adam> become removed, simply read LINT on how to wire your disk
Adam> id's.
I understand. The poi
> "Mike" == Mike Smith <[EMAIL PROTECTED]> writes:
Mike> The "right" solution is and has always been to name your
Mike> disks and mount them by name. Once devfs is a reality,
Mike> we'll be able to do just this. Until then, the problem's
Mike> not really as bad as you make i
> "BSDman" == BSDman <[EMAIL PROTECTED]> writes:
BSDman> one idea about /usr is to allow the admin to mount it
BSDman> read-only. I didn't tried it but this would give some
BSDman> level of security against modifications of the files there
BSDman> in.
This is particulary us
> "Peter" == Peter Jeremy <[EMAIL PROTECTED]> writes:
>> And then we could telinit -on sshd telinit -off sshd
Peter> This looks nice. The major problem I see is coming up with
Peter> a secure mechanism for passing the daemon name from telinit
Peter> to init.
Named sockets w
I like the idea, but the -l flag conflicts with a different usage for
SVR4 derived makes (on at least AIX, Irix, and Solaris):
-l load
Specifies that no new jobs (commands) should be started
if there are others jobs running and the load average
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 "unsubscribe free
> "David" == David O'Brien <[EMAIL PROTECTED]> writes:
David> You might get more interest if you mention what the PR
David> fixes.
It adds missing binary/manpage links from opiekey to otp-md4 and otp-md5.
Some of our remote users run software that semi-automates OTP logins,
and that
Chuck> Compatibility with those other makes is pretty low to begin
Chuck> with, but it doesn't hurt, I guess, to allow for this. -dl
Chuck> is ok with me. I just wouldn't consider the compatibility
Chuck> thing a real issue if it weren't this easy to satisfy.
It's not a big deal
> "Ruslan" == Ruslan Ermilov <[EMAIL PROTECTED]> writes:
Ruslan> It doesn't really matter what the home directory is set to
Ruslan> (IIRC), but the shell must be uucico(8).
No, this is wrong on both counts.
By convention, the home directory of the uucp login has corresponded
to the
> "Garrett" == Garrett Wollman <[EMAIL PROTECTED]> writes:
Garrett> I remember, back in the mists of ancient time, it was
Garrett> common practice to provide ``anonymous UUCP'' service
Garrett> along the lines of anonymous FTP in (what was at that
Garrett> time) ARPANET.
Yu
> The convention was to use ``uucp'' as the default anonymous login
> service.
I think we're talking about two different things. Yes, many
UNIX distributions shipped with a passwordless 'uucp' account
with uucico as the shell. My comments about the 'nuucp'
convention were referring to the publica
All these "solutions" assume that everyone is wired up with IP
connectivity. The original questions was "who uses UUCP?"
One answer is: "those without IP connectivity." Part of the problem
here I suspect is that the people who develop and maintain FreeBSD
live a life where a T-3 into your living
> Do you mean 'full-time IP connectivity', because if you can setup a UUCP
> connection, you can just as easily setup a PPP connection over the same
> medium, giving you IP connectivity.
True, but there's a lot more infrastructure overhead involved in
setting up a group of disconnected machines v
> None of those things are realproblems. I've set up the port to be
> hosted on MASTER_SITE_LOCAL for now, but Lyndon's free to go and host
> it wherever he likes, organise whatever community support he likes (if
> theres nontrivial interest he could surely even get a freebsd.org
> mailing list s
> > Just like with anonymous FTP, don't make it world writable if you don't
> > want the world writing to it.
>
> Right - that's what actually was done.
> Don't install it unless you need.
Oh give me a break. You do not disable anonymous FTP uploads by
'rm /usr/libexec/ftpd'.
> I'm talking abou
> What are *you* doing to address the problem? Are you stepping up as a
> maintainer?
Yes. If you read the list archives you will see I've done so
twice in the past already.
> Are you willing to fix the problems with UUCP in FreeBSD as it is
Yes.
> How much time are you willing to contribute?
> There are many other points - some examples I know of:
> The /var/spool/uucppublic which is writeable by everyone.
> Usually you don't want this.
Just like with anonymous FTP, don't make it world writable if you don't
want the world writing to it.
> Ever received a mail with an envelope like "
> "David" == David W Chapman <[EMAIL PROTECTED]> writes:
David> mergemaster only checks to see if RCSID's are different by
David> default, I forget which option, but there is one to actually
David> diff the two files when doing its inital compare, but the
David> RCSID's would
> "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
> "Andrey" == Andrey A Chernov <[EMAIL PROTECTED]> writes:
Andrey> I think it is very contr-intuitive way, better action will
Andrey> be "replace" if number is the same.
Nonsense. This is what 'add' and 'delete' are for.
Andrey> For example "ipfw delete" takes number as an argum
> Then why bother having rc.conf in the first place? Just wire in all
> the defaults straight into /etc/rc and leave rc.conf strictly for
> overriding the defaults only, and eliminate rc.conf.* entirely.
Because rc.conf contains configuration variables, whereas rc contains
commands to execute
On 8 Feb, Jordan K. Hubbard wrote:
>> These should be left has ports.
>
> Can't really get away with that anymore - too many people require
> DHCP for very basic bootstrapping.
To insert some reality into this discussion, a quick survey at the
office shows:
PlatformHas DHCP
An alternative to dhclient and bpf would be to add an ioctl that would
force an interface to initiate a DHCP configuration. This would allow
for something like:
ifconfig ep0 dhcp
Of course, this means moving the entire DHCP state engine into the
kernel ...
--lyndon
To Unsubs
> Erm, you forgot to include the patches to do this...
I'll leave that to the anti-bpf fanatics (who can also supply patches
to eliminate /dev/[k]mem while they're at it). I'm quite happy seeing
ISC dhclient move into /sbin.
To Unsubscribe: send mail to majord...@freebsd.org
with "unsubscribe f
> > Basically, it is a patch into libkvm and w, that will allow a user (with
> > the exception to the super user, naturally) to only view processes or
> > information belonging to him/herself.
> The only problem with this is setuid binaries. The processes may have
> been started by me (top, etc.
I've been trying to get some progamming doc out of TI for
the PCI1200 PCI/Cardbus bridge (used in the Dell Inspiron
7000), however they cannot seem to understand that I'm not
asking for a pre-written device driver :-(
Does anyone out there have doc for the PCI1200 (and
preferably the entire PC
> There are PDF and zipped PostScript data sheets for these
> parts on TI's web page:
>
> http://www.ti.com/sc/docs/folders/analog/pci1211.html
Ya, I found those by doing a search inside the TI site. The
problem is the data sheets those URLs point to only
describe the hardware side of things. T
> While CardBus isn't supported, this controller (in my Fujitsu Lifebook 280dx)
> works with PAO because the PCI<->CardBus bridge supposedly uses some kind
> of Intel-compatible mode. I've been unable to get it to work under stock
> pccard without PAO (look at my post to -hackers yesterday), but i
I finally managed to extract a copy of the PCI-1220 chip documentation
from TI. If anyone needs a copy of this, e-mail me and I'll forward it
along. (Beware, it's a 3.5 MB PDF.) (If I get the okay from TI I'll
also put it up for FTP someplace.)
--lyndon
To Unsubscribe: send mail to majord...@f
It's online now at:
ftp://ftp.execmail.ca/pub/staff/lyndon/misc/PCI1220.pdf
--lyndon
To Unsubscribe: send mail to majord...@freebsd.org
with "unsubscribe freebsd-current" in the body of the message
> I recently upgraded one of my machines to 5.1-current, and for some reason I keep
> getting "Share object 'libintl.so.4' not found" errors when I attempt to install
> from ports or execute certain commands/programs. I read that upgrading my version of
> gettext would fix the issue, but it has
--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://lists.freebsd.org/mailman/listinf
--On Thursday, November 20, 2003 9:40 PM -0500 Richard Coleman
<[EMAIL PROTECTED]> wrote:
ust put a tiny termcap file in /rescue (i.e. termcap.rescue) that
contains 5 or 6 of the most common terminal types (cons25, vt102,
etc), and have /rescue/vi default to cons25.
If you are hosed enough to req
(And yes, this is a bit of an irony considering that I used to be the
maintainer of the base-system Kerberos code in the long-ago krb4
days. But my job requires me to administer MIT Kerberos, so I need
the MIT kadmin utility and not the Heimdal one.)
Aren't the reasons for the Heimdal distribut
... 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
you?
--lyndon
___
> "M" == M Warner Losh <[EMAIL PROTECTED]> writes:
M> I think that we need a mtree.obsolete that goes through and
M> deletes these sorts of things as part of installworld/upgrade
M> scripts.
No solution like this will ever work for everyone, or in every
situation. For example, yo
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 Unsubscribe: send mail to [
Garance A Drosihn writes:
>>We could add 'rm -rf /usr/include/*' at a suitable point inside
>>the installworld target.
>
>Installers should not be blindly removing entire directory structures.
The only things that live under /usr/include are those owned by the
system's install target, therefore
>> Maybe future generations will wonder what it is named after
>> similarly to GCOS field in passwd today :-)
>
>At the very least we should change the shell. But Kris' suggestions
>sound the best.
I agree. But more importantly, let's make sure that we don't, by
removing the uucp login, make it d
>>I can't find any shell script 'adduser' in
>>http://www.freebsd.org/cgi/cvsweb.cgi/
>>Where can I find it?
I'm not sure about the one Terry (?) mentioned, but I have a shell
replacement for adduser that's 98% complete. There's one remaining
bug. I wasn't going to say anything until I had rmuser
For the benefit of packet sniffers and other things that only want
read-only access to /dev/bpf*, what do people think of adding a 'bpf'
group for those programs? This allows bpf devices to be read by
programs running with an effective gid of 'bpf' instead of the current
requirement for an effect
> "Crist" == Crist J Clark <[EMAIL PROTECTED]> writes:
Crist> I do this a lot too on systems where it makes sense. But I'm
Crist> not sure I understand what you are asking to be done. Is it
Crist> asking too much of an administrator to do,
There are two ways to handle this. One
> "Crist" == Crist J Clark <[EMAIL PROTECTED]> writes:
Crist> OK. Now you've really lost me. What do ports have to do with
Crist> this? Which ports? None of the sniffing programs I am aware
Crist> of use set{g,u}id bits. They rely on the permissions of the
Crist> user running
> "Garance" == Garance A Drosihn <[EMAIL PROTECTED]> writes:
Garance> I agree. That's why a redirector makes more sense, because
Garance> the redirector can be part of the base-system, and the port
Garance> can be installed in /usr/local.
There is one problem with the /usr/bin/p
> "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
> "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't we use ed for in-place edits?
--lyndon
To
>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 PROTECTED]
with "unsubscribe freebsd
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 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
On May 9, 2015, at 8:05 AM, Pedro Giffuni wrote:
> We do that with GNU code anyways. The latest (GPLv3) version
> of RCS has already diverged and is incompatible for some third
> party software so we basically ran out of support from upstream.
> OpenRCS has it's own share of problems but general
On Oct 24, 2015, at 12:06 PM, John-Mark Gurney wrote:
> The thing I like most about encryption is that when I RMA a bad
> drive, I don't have to worry about my data leaking if I am unable
> to overwrite all the data...
You are optimistic if you believe that. We ($WORK) factor the cost of
DOA/
On 2016-04-18 5:09 PM, Nathan Whitehorn wrote:
I'm not so sure about these statements. Maintaining groups of packages
can be easier, but it can be also be harder. The goal is to find the
right level. And I haven't seen a case where an 800-packages level of
granularity is helpful.
Not to mention
On 2016-04-18 7:01 PM, Roger Marquis wrote:
Can you explain what would be accomplished by testing all or even a
fraction of the possible permutations of base package combinations? We
don't do that for ports.
The ports tree isn't a mandatory part of the system. And by definition
it could not b
On 2016-04-18 8:17 PM, Alfred Perlstein wrote:
Can someone on the "too many packages" campaign here explain to me how
having too fine a granularity stops you from making macro packages
containing packages?
Because honestly I can't see how having granularity hurts at all when if
someone wanted to
On Tue, 19 Apr 2016, Poul-Henning Kamp wrote:
As far as I know, nobody is taking the source code or the Makefiles
away, so if somebody doesn't like the system being distributed with
pkg, they can very well roll their own.
True enough. But I am also wary of decending into what became of X, whe
On Tue, 19 Apr 2016, Warner Losh wrote:
Sadly the tenor and tone of the discussion isn?t one where progress is
made. The tone has been a bit toxic and demanding, which grinds people
into dust, rather than motivating them to fix things. You might call it
a discussion, but it reads to me more as
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
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
That was actually not why catman was brought into the world: ATT/USL
thought text-processing was The Goods so they unbundled it base SVR
and invented catman to make up for the missing nroff.
Not quite. They (AT&T) sold the rights to sell typeset manuals to some
publishing house (I forget whic
On Tue, 12 Sep 2017, Poul-Henning Kamp wrote:
I'm pretty sure that SVR1 had catman and roff was an extra and somewhat
pricey software package.
The SVR1 (and 2) systems I had access to were all CTIX, and it shipped
with nroff/troff. And the 3B4000 & 3B2s I used later (SVR2 and later)
also ha
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"
Max, I think a reasonable default is to continue building and shipping
profiled libraries. This keeps FreeBSD consistent with every other UNIX
variant released in the last (at least) 30 years.
If you personally find profiled library builds slow you down too much, a
one line addition to your /
Nothing is being broken here, just a default being changed.
Users make up a greater proportion of our userbase than developers, so
sensible defaults for them are more appropriate, right?
This has no impact on non-developer end-users.
For "developer" end-users, this has a huge impact. You are
Something else I forgot to mention ...
The point of -CURRENT is to make sure everything works before it becomes
-STABLE and -RELEASE. Not building significant components of the system
ensures those components don't get tested. This includes the actual build
process, as well as the underlying
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
Obsolete does not mean it doesn't work.
No, these days 'obsolete' seems to mean 'it does not have a sexy
Flash-driven web GUI.'
Profiling is a simple basic tool that makes it easy to quickly find code
execution hot-spots. It's not dtrace, or any other plethora of tools that
do a more exten
In this case, 'obsolete' means it's a difficult-to-use tool that
requires recompiling your application, can't be used in production,
doesn't work when shared libraries are in the picture, offers
limited-to-no visibility into the underlying reasons why a particular
code path is a hotspot and introd
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.
__
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
About the donations page et al ... that's set up for cash donations.
Hardware doesn't go through there very well. I don't care about tax
receipts. I'd rather just send the gear directly to any people who can
legitimately use it (i.e. someone with an @freebsd.org address, or someone
with an @f
I know I am a certified crank, but ... why? This is some of the simplest code
on the planet. Is it broken by recent OS releases? 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 'c
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
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: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 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 4:37 PM, Adrian Chadd wrote:
> Then you and others should stand up and provide feedback like this far, far
> earlier in the development process.
So when was this first discussed? I've been on -current for over a decade. If
I missed a prior discussion I truly apologize.
--
On 2013-10-07, at 4:49 PM, Adrian Chadd wrote:
> I've asked on IRC to figure out when this was first proposed.
Adrian, something to keep in mind is that the majority of your code's users
will never use your preferred communication media. So when you propose to
remove a feature, absence of pu
On 2013-10-07, at 5:40 PM, Julian Elischer wrote:
>> svnlite?
>>
> fail
I won't go that far, immediately.
But I need a tool that lets me migrate the history of my RCS files to the new
regime.
And the new tools(s) *must* be part of the base system. (Migration tools
included.)
And the new
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
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.
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/listinfo
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
On 2013-10-08, at 11:17 AM, Freddie Cash wrote:
> I haven't kept up-to-date with all the developments, but isn't this part of
> the bsdinstall/pkgng plan? Once the pkgng repos are all available and
> populated, then bsdinstall will be able to install packages from there during
> the install
On 2013-10-10, at 1:06 PM, Igor Mozolevsky wrote:
> You're missing the point- the requirement is "provide a way to keep track
> of changes for file X" not "have many fancy and unnecessary features"...
The point is to put back the specific RCS commands that were recently removed.
Those of us us
On 2013-10-10, at 2:54 PM, Allan Jude wrote:
> I've been working on the handbook section on ZFS and made certain to
> mention that, I'll have to look at improving the man page as well, but
> as far as I know, the man page is imported from IllumOS, where spares do
> work.
This is probably worthy
> Support for a cron.d directory is a tool that can be
> used in many ways.
I have used cron.d on other UNIXen, and for package-installed cron jobs I find
it significantly friendlier, in that it makes these jobs easily identifiable to
the sysadmin.
As we do it now, the per-user crontabs are qui
On Nov 6, 2013, at 7:49 PM, Kimmo Paasiala wrote:
> What's wrong with using the existing tools for achieving the same
> effect? Periodic can be adapted to do exactly what you're describing
> as noted above by adding an hourly (even minutely? :D ) periodic run.
Periodic is geared towards periodi
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
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 19:46, Kimmo Paasiala wrote:
> I don't like the idea of having untracked files installed by the rc(8)
> script. Why not install the cron.d snippet by default but leave
> everything in it commented out with instructions at the beginning to
> uncomment the contents to enable it?
1 - 100 of 116 matches
Mail list logo
