On Mon, Mar 17, 2003 at 10:06:27AM +0300, "."@babolo.ru wrote:
>It is time to invent "ping socket" and "traceroute socket"
>in addition to tcp, udp, divert so on?
Whilst this might seem nice, actually implementing so that it is
both useful and safe is not easy.
For a "ping socket", this is reason
> On Sun, Mar 16, 2003 at 02:30:36PM -0800, Mooneer Salem wrote:
>
> When i was looking at this i was somewhat frustated with
> the way suser() doesn't really allow any sort of a context-of-check
> to happen easily that i was able to find. ie, was it for a networking
> check, filesystem, et
On Mon, Mar 17, 2003 at 12:39:22PM +0300, sergej wrote:
> mozno li ustanovit% odnovremenno na odin disk:
> unix i windows, i kak jto sdelat%!
Get yourself a copy of the "Complete FreeBSD" by Greg Lehey,
which covers this subject very well. This question also belongs
to , not -hackers.
In short, t
можно ли установить одновременно на один диск:
unix и windows, и как это сделать!
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-hackers" in the body of the message
Jail is irrelevant if an attacker can access the kernel.
It sounds like you're looking for a secure solution that UNIX doesn't
even have the capability to implement. The real solution in a BSD
environment would be too elaborate for my taste. It would make
more sense to me to move away from UNIX ;)
David Schultz wrote:
> Thus spake Terry Lambert <[EMAIL PROTECTED]>:
> > Nope. I commit locally as "nwilliams", and then I commit on
> > FreeBSD.org as "nate". Then I try to update, and the versions
> > match, but the tag data in the file itself doesn't.
>
> So Terry has actually been writing co
Thus spake Terry Lambert <[EMAIL PROTECTED]>:
> Nope. I commit locally as "nwilliams", and then I commit on
> FreeBSD.org as "nate". Then I try to update, and the versions
> match, but the tag data in the file itself doesn't.
So Terry has actually been writing code for the FreeBSD project
all th
> > > I see how you are viewing this: as a means of avoiding a full
> > > CVSup.
> > >
> > > I think the reason the cache was wanted was not to avoid the
> > > CVSup, but to allow operations *other than CVSup* to proceed
> > > more quickly?
> >
> > Having a local 'CVS' tree mirrored already does t
Nate Williams wrote:
> > I see how you are viewing this: as a means of avoiding a full
> > CVSup.
> >
> > I think the reason the cache was wanted was not to avoid the
> > CVSup, but to allow operations *other than CVSup* to proceed
> > more quickly?
>
> Having a local 'CVS' tree mirrored already d
On Sun, Mar 16, 2003 at 02:30:36PM -0800, Mooneer Salem wrote:
> Hello,
>
> This patch is interesting. To my understanding though, ipfw uses RAW sockets
> to communicate with the kernel. Therefore, it might be possible to edit the
> ipfw table from within the jail, which may be a bad thing. Just a
> > > Nate's suggestion covers the version number issue... sort of. It
> > > assumes that the patches will be approved for commit to the main
> > > repo
> >
> > This is easy to get around, b/c if the commit doesn't happen
> > successfully on the repo, then the commit fails, and as such it also
>
Nate Williams wrote:
> > Nate's suggestion covers the version number issue... sort of. It
> > assumes that the patches will be approved for commit to the main
> > repo
>
> This is easy to get around, b/c if the commit doesn't happen
> successfully on the repo, then the commit fails, and as such i
On Sun, Mar 16, 2003 at 04:32:48PM -0700, Nate Williams wrote:
> > What is the status of Perforce in the FreeBSD project? Is the issue the
> > absence of a "p4up"? Licensing? Inertia?
>
> See the archives for a more thorough discussion, but I believe the
> licensing is the biggest issue. If we
Mark Tinguely wrote:
> Intel x86 hardware allows windows of 4GB of virtual memory even if
> you have the PSE-36 and the PAE extensions with more the 4GB of
> physical memory. Sound a little like Intel's 64KB windows, but
> if I remember correctly, the 4GB does not have to be contiguous.
>
> It wou
tem that can handle more RAM.
Suggest you examine:
<http://docs.freebsd.org/cgi/getmsg.cgi?fetch=1124056+0+archive/2003/freebsd-current/20030316.freebsd-current>
Specifically, search for "Jake Burkholder".
Likely, when this is committed, it will be treated as "a different
ar
Sean Chittenden <[EMAIL PROTECTED]> writes:
> Right, which is what I was trying to suggest a fix for in the first
> place: the ability to prevent the loss of work committed to a local
> repository when using cvsup to sync repositories with the master repo.
if you *want* to keep the local changes (
Nate Williams wrote:
> > The current version of Perforce has "p4proxy" which caches
> a local copy
> > of the depot files used.
>
> Does it still require a working net link to the master
> repository? When
> it was originally released, I remember it being useful for slow links,
> but not so goo
> > The other solution to the problem is the P4 route. Making things so
> > darn effecient that there's little need to have a local mirror. Where
> > this falls down is when the remote developer doesn't have a 24x7
> > connection to the main repository. From what I've been told ClearCase
> > all
Yaoping Ruan wrote:
> Does any one know the implementation of "ktrace" in FreeBSD? I would
> like to hack the source code and have a relatively easy way to copy
> the kernel stack image when a certain of thing happens, such as page
> fault. It should work like the breakpoints in gdb. But kernel pan
Nate Williams wrote:
> The other solution to the problem is the P4 route. Making things so
> darn effecient that there's little need to have a local mirror. Where
> this falls down is when the remote developer doesn't have a 24x7
> connection to the main repository. From what I've been told Clea
> > The corollary to that would be to teach cvs(1) to commit changes to
> > the master repo that have been made to the local repo. Version number
> > sync would be a problem, but it'd be really cool to be able to do
> > that. With a branch mapping layer (RELENG_5_SEANC -> HEAD), people
> > could
Sergey Babkin wrote:
> Nate Williams wrote:
[ ... "CVS cache and cache coherency" ... ]
> Yet another idea is to be able to make "local commits" with committing
> them to the central remote repository later. Now I have to use RCS
> locally for the temporary in-delevopment versions of file. Would
Sean Chittenden wrote:
> It'd be cool to teach CVSup to ignore updating certain files that have
> been marked locally as "dirty" or "in flux" until they've been
> committed through to the master repo. Even better would be to have
> CVSup ignore making changes to designated branches (RELENG_5_SEANC
Hello,
This patch is interesting. To my understanding though, ipfw uses RAW sockets
to communicate with the kernel. Therefore, it might be possible to edit the
ipfw table from within the jail, which may be a bad thing. Just a thought.
Thanks,
--
Mooneer Salem
GPLTrans: http://www.translator.cx/
> > [local commit to file A ]
> > [different developer commits to file A on master repo]
> > [commit to file A on master repo]
> > [cvsup local repo with master repo]
> >
> > Wouldn't you have to delete A,v before A,v would continue to pick up
> > future changes? -sc
>
> No, cvsup wou
Sean Chittenden <[EMAIL PROTECTED]> writes:
> [local commit to file A ]
> [different developer commits to file A on master repo]
> [commit to file A on master repo]
> [cvsup local repo with master repo]
>
> Wouldn't you have to delete A,v before A,v would continue to pick up
> future
> > > With the -s option, cvsup will not touch files that it believes are
> > > in sync until they are updated on the server.
> >^^^
> >not ?
>
> no, not "not". "cvsup will not touch files that it believes are in
> sync", the operative word here being "believes" - with -s cvsup will
> use
Sean Chittenden <[EMAIL PROTECTED]> writes:
> > With the -s option, cvsup will not touch files that it believes are
> > in sync until they are updated on the server.
>^^^
>not ?
no, not "not". "cvsup will not touch files that it believes are in
sync", the operative word here being "believ
> > It'd be cool to teach CVSup to ignore updating certain files that have
> > been marked locally as "dirty" or "in flux" until they've been
> > committed through to the master repo.
>
> With the -s option, cvsup will not touch files that it believes are
> in sync until they are updated on the se
Sean Chittenden <[EMAIL PROTECTED]> writes:
> It'd be cool to teach CVSup to ignore updating certain files that have
> been marked locally as "dirty" or "in flux" until they've been
> committed through to the master repo.
With the -s option, cvsup will not touch files that it believes are in
sync
Sergey Babkin <[EMAIL PROTECTED]> writes:
> A similar thing may be achieved by checking the files out from the local
> repository and doing any modification command with option -d. But that's
> troublesome and inconvenient.
Read the manual page for the shell you're using, with particular
emphasis
so, i am working on building a "super-server" for me
and several friends to collaborate with on the money front
to put our machine in a colo location, etc.. and still have good
access to networking resources.
as a result, i needed to modify the FreeBSD kernel such
that it will all
> > Yet another idea is to be able to make "local commits" with committing
> > them to the central remote repository later.
>
> I'd do the reverse, since the possibility of synchronization problems
> are a huge deal. Imagine if someone 'snuck' in and made a commit in
> the master tree after your
> > > The value specified in CVSROOTCACHE is the local path to the cache
> > > repository. All the check-outs, updates, diffs etc. will be obtained
> > > from there. All the check-ins, tagging etc. will go into the master
> > > repository specified by CVSROOT. Naturally, to see these changes
> > >
Nate Williams wrote:
>
> > The value specified in CVSROOTCACHE is the local path to the cache
> > repository. All the check-outs, updates, diffs etc. will be obtained
> > from there. All the check-ins, tagging etc. will go into the master
> > repository specified by CVSROOT. Naturally, to see the
> The idea is to support a "cache" repository (the one copied to a local
> machine by CVSup or CTM) transparently. So that the reads from
> directory will go from the local cache repository (and won't
> overstrain the remote server, and will be fast too), while the commits
> and other changes will
36 matches
Mail list logo
