Re: security/pgp on amd64

[Dan Nelson]

In the last episode (Jun 24), Olivier Nicole said:
> Is the port security/pgp working on amd64 system?
> 
> I copied my public and private keyrings from i386 to amd64 system and I
> cannot decipher any file, it keeps on complaining that the pass phrase is
> bad.
> 
> I already tried to export the key on the i386 and import on the amd64, but
> it did not change a thing.

You mean the pgp-6.5.8_1 port, with a source tarball dated 1999-10-31?  I
wouldn't be surprised if it wasn't 64-bit capable.  Try the gnupg port
instead.

-- 
Dan Nelson
dnel...@allantgroup.com
___
freebsd-questions@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-questions
To unsubscribe, send any mail to "freebsd-questions-unsubscr...@freebsd.org"

Re: you're not going to believe this.

[freebsd]

Gary Kline:
> Http://www.mydigitaldiscount.com/SPD/runcore-64gb-pata-mini-pci-e-pcie-ssd-for-asus-eee-pc-901-and-1000---backorder-runcore-64gb-pata-mini-pci-e-pcie-ssd-for-asus-eee-pc-901-and-1000--88DB-1224129741.jsp

> ... statement that this device lasts ten years before it fails to
> hold state.

Roland Smith:
> The big difference is that it is much easier to tweak and change
> algorithms when doing it in software.

Wojciech Puchar:
> This flash chips have to emulate hard drive, which slows them down
> manyfold

> ... has acceptable lifetime/reliability, and uses less power/generates
> less heat than traditional platter HD ...

> [F]or example wear leveling and emulation small blocks requires moving
> of data within flash, this lowers both performance and lifetime.

I should know better, but I'm going to reply anyway.

First, be careful about statements like "10 years before it fails to hold
state." Usually that means if you write data to the device and put it on a
shelf, you've got 10 years before the data is unreadable. Being marketing
figures, these numbers are naturally stretched and inflated. Data retention
is strongly dependent on ambient temperature, among other things. More
to the point, that's a statistic you probably don't care about, because
who's going to buy a $200+ SSD hard drive and then leave it on a shelf
for a decade? The number you probably care about is how long _in active
use_ the drive will last, and that's probably _not_ 10 years. The primary
source of degredation (and eventually, failure) is writes, so minimizing
writes will probably extend the drive's life. NAND Flash, as used in SSDs,
is typically rated for (order of magnitude...) 10k write cycles. How many 
writes that gives you, once you put a bunch of chips together into an SSD 
and do wear leveling and all that, is anyone's guess. (The manufacturer 
probably knows, but won't tell you.)

Current NAND Flash chips do ECC and wear leveling transparently. It
is a significant time cost to move a block, so it's usually done
when a block is already being erased. This eliminates half the time
because you already know half the data trivially (it's being erased),
and erase is already a long operation, so making it a little longer
is less noticeable. Implementing wear leveling in OS-level software
isn't feasible. As I mentioned, wear leveling happens within the chip,
so the OS doesn't even know a block swap has occurred. (As an extension
of this, the OS doesn't know what the write count is, per block.) The OS
doesn't have access to physical parameters of the Flash cells (parameters
the chip itself can measure on-the-fly) to know when a swap needs to
occur. Depending on implementation, the OS may not even realize when (or
how often) an ECC correction occurs. Wear leveling algorithms are anything 
but trivial, are usually are closely guarded trade secrets, and depend 
heavily on manufacturing process parameters that are themselves trade 
secret. (This is not to say a Flash-specific file system doesn't have
value... you can probably get a lot just by caching writes as long as
possible, and putting commonly-modified pieces of data near each other
in the address space so they can be written together when updating is
needed.)

The SATA bridge does have a non-zero impact on read and write
times. However, that impact is nowhere near "manyfold" the inherenet
read/write time. In fact, it's pretty close to negligible. Most of the
time is eaten up by multi-level cell sensing/placement, ECC correction,
and as mentioned above, wear leveling (for writes).

The lifetime and reliability of SSDs are less-than-or-equal-to the
lifetime and reliability of spinning magnetic drives, so don't buy an SSD
for that. Whether SSDs use less power is an open question. There's a lot
of data going either way. The last comparison I saw suggested spinning 
drives average less power than their SSD counterparts. In any event, it's 
not clear-cut yet. SSDs probably do generate less heat (but I've not seen 
data on that). Of course, the access time on an SSD is order(s) of 
magnitude less than for a spinning drive, and that's cause enough for 
lots of people to buy one.

And finally, wear leveling is just a fact of life with Flash. It's not a
symptom of emulating a spinning drive or some particular block size. Wear
leveling won't go away (and you won't gain back that part of the write
time) by inventing a non-SATA, Flash-specific HD interface that nobody
supports yet. In fact, Gary's link talks about a device with a PCIe
interface, so the whole issue of acting like a spinning drive isn't
applicable.


___
freebsd-questions@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-questions
To unsubscribe, send any mail to "freebsd-questions-unsubscr...@freebsd.org"

Re: you're not going to believe this.

[Wojciech Puchar]

First, be careful about statements like "10 years before it fails to hold
state." Usually that means if you write data to the device and put it on a
shelf, you've got 10 years before the data is unreadable. Being marketing


possibly it's true if you will write it few times and no more ;) store it 
in perfect stable room temperature with low natural radiation background 
etc.



for a decade? The number you probably care about is how long _in active
use_ the drive will last, and that's probably _not_ 10 years. The primary


1 writes of it's size if it would be properly managed (flash 
filesystem). As it emulates disk divide it by at least two on writing 
large files, at least 20 in case of random small writes.



is less noticeable. Implementing wear leveling in OS-level software
isn't feasible. As I mentioned, wear leveling happens within the chip,
so the OS doesn't even know a block swap has occurred. (As an extension


you are wrong. flash chips doesn't do this. There is a controller that do 
this. If it would give simple interface to flash chips and say PCI-Express 
or SATA, making proper flash filesystem would be possible.

___
freebsd-questions@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-questions
To unsubscribe, send any mail to "freebsd-questions-unsubscr...@freebsd.org"

The question of moving vi to /bin

[Manish Jain]

On Tuesday 23 June 2009 15:41:48 Manish Jain wrote:

> I hope the next release will address these problems, as well as a pretty
> reasonable request from me much earlier to move vi from /usr/bin to
> /bin. Even in single-user mode, you almost always need an editor.





Which is why you have ed(1) - both in /bin and in /rescue - and /rescue/vi 
(although that needs a bit of tweaking due to the /etc/termcap problem).


Bear in mind that /usr/bin/vi is over 300K, compared to the whole of /bin 
which is ~950K (if you avoid double-counting entries like /bin/csh 
and /bin/tcsh which are hardlinks to the same file), so you need to convince 
people who think /bin should stay small to let it grow by a third to save 
people learning ed(1).


Jonathan



Hello Jonathan,

About ed first. I might annoy a few people (which would gladden me in 
this particular case), but ed was just one of Ken Thompson's nightmares 
which he managed to reproduce in Unix with great precision. By no 
stretch of imagination would it qualify as an editor, because an editor 
can meaningfully edit only what it can first show. And ed has never had 
anything to show. A modern operating system like FreeBSD should really 
be kicking ed out of the distribution completely : bad ideas don't have 
to be necessarily perpetuated just for the sake of compliance with the 
original concept of Unix.


and /rescue/vi 
(although that needs a bit of tweaking due to the /etc/termcap problem)


That's the whole problem of /rescue/vi. When you suddenly find yourself 
in single-user mode, the last thing you want to do is realise that 
tweaking is needed for something which should work normally just when 
you need it, and quickly too.



Bear in mind that /usr/bin/vi is over 300K


Actually, the cost is more than 300K because the terminal database would 
have to be put into / too. But why are we talking about a few hundred 
kilos for such a basic utility as vi in times when everyone has hundreds 
of GB's on the disk, and the / partition itself is 512 MB by default. 
The BSD concept of having vi under /usr originated when resources were 
less by a factor of thousands (<= (100 MB disks), <= (8 MB physical RAM) 
and so on). When we are well past those kind of constraints, the concept 
needs an rethink.


Actually, there is an even more radical update that I would have loved 
FreeBSD to have initiated. Instead, the credit has gone to Microsoft. 
The simple thing is when a system has multiple gigabytes of RAM, the OS 
should be able give an option to the user of completely doing away with 
swapping and force all the action in real, physical memory instead.


This latter idea might still sound a bit far-fetched, but at least 
dumping ed and /rescue/vi to pave way for /bin/vi is certainly more than 
a workable idea. Till that happens, people like me might be forced to do 
outlandish things like copying /usr/local/bin/{bash,vim} to /bin and 
their associated libraries to /lib. I really mean copying, not moving - 
which could create problems with port/library upgrades at a later date. 
It works, is safe and easy, and requires no tweaking.


Hope there are some takers.

--
Regards
Manish Jain
invalid.poin...@gmail.com
+91-96500-10329

Laast year I kudn't spell Software Engineer. Now I are won.
___
freebsd-questions@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-questions
To unsubscribe, send any mail to "freebsd-questions-unsubscr...@freebsd.org"

Re: upgrading openoffice.org with portmaster

[Boris Samorodov]

On Wed, 24 Jun 2009 00:39:22 +0200 kenneth hatteland wrote:

> when I start upgrading openoffice.org it switches from my localized
> language build to standard us en.

> Anyone have an idea how to force upgrade to stick with my norwegian
> build with portmaster ??

> Platform freebsd 7.2 stable (x86)

I have at /etc/make.conf for russian language:
-
.if ${.CURDIR:M*/editors/openoffice.org-3}
LOCALIZED_LANG=ru
.endif
-

I'm not sure if Norwegian is "nb" or something else though. But
you have an idea.


WBR
-- 
bsam
___
freebsd-questions@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-questions
To unsubscribe, send any mail to "freebsd-questions-unsubscr...@freebsd.org"

Re: Untrusted X11 forwarding setup failed

[Lowell Gilbert]

Daniel Underwood  writes:

> Whenever I
>
> $ ssh -X u...@server
>
> from my FreeBSD machine, I get the following message (and am
> successfully logged in):
>
> Warning: untrusted X11 forwarding setup failed: xauth key data not generated
> Warning: No xauth data; using fake authentication data for X11 forwarding.
>
> When I log in to the same servers from my Ubuntu machines, I do NOT
> get that message.
>
> What's wrong here?

See the ssh(1) manual for information on the -X and -Y options, and
ssh_config(5) for information on ForwardX11Trusted.

-- 
Lowell Gilbert, embedded/networking software engineer, Boston area
http://be-well.ilk.org/~lowell/
___
freebsd-questions@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-questions
To unsubscribe, send any mail to "freebsd-questions-unsubscr...@freebsd.org"

Re: upgrading openoffice.org with portmaster

[Rolf Nielsen]

Boris Samorodov wrote:

On Wed, 24 Jun 2009 00:39:22 +0200 kenneth hatteland wrote:


when I start upgrading openoffice.org it switches from my localized
language build to standard us en.



Anyone have an idea how to force upgrade to stick with my norwegian
build with portmaster ??



Platform freebsd 7.2 stable (x86)


I have at /etc/make.conf for russian language:
-
.if ${.CURDIR:M*/editors/openoffice.org-3}
LOCALIZED_LANG=ru
.endif
-

I'm not sure if Norwegian is "nb" or something else though. But
you have an idea.


WBR


Norwegian should be no if I'm not mistaken.If you install 
ports-mgmt/portconf, you get a means to configure default knobs for 
ports, that's not dependant on which portmanager you use.

___
freebsd-questions@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-questions
To unsubscribe, send any mail to "freebsd-questions-unsubscr...@freebsd.org"

Re: The question of moving vi to /bin

[b. f.]

> On Tuesday 23 June 2009 15:41:48 Manish Jain wrote:

...

>About ed first. I might annoy a few people (which would gladden me in
>this particular case), but ed was just one of Ken Thompson's nightmares
>which he managed to reproduce in Unix with great precision. By no
>stretch of imagination would it qualify as an editor, because an editor
>can meaningfully edit only what it can first show. And ed has never had
>anything to show. A modern operating system like FreeBSD should really
>be kicking ed out of the distribution completely : bad ideas don't have
>to be necessarily perpetuated just for the sake of compliance with the
>original concept of Unix.

If you want to make a case for replacing ed(1), you're going to have
to come up with some concrete reasons for doing so, not just make a
(long and hyperbolic) statement that you don't like it.

...

>That's the whole problem of /rescue/vi. When you suddenly find yourself
>in single-user mode, the last thing you want to do is realise that
>tweaking is needed for something which should work normally just when
>you need it, and quickly too.

Yes.  But there have been some recent changes:

http://svn.freebsd.org/changeset/base/194628

that suggest that this problem is being addressed.

...

>But why are we talking about a few hundred
>kilos for such a basic utility as vi in times when everyone has hundreds
>of GB's on the disk, and the / partition itself is 512 MB by default.
>The BSD concept of having vi under /usr originated when resources were
>less by a factor of thousands (<= (100 MB disks), <= (8 MB physical RAM)
>and so on). When we are well past those kind of constraints, the concept
>needs an rethink.

No, we're not.  A lot of people are still using old hardware, or
embedded hardware, where efficiency in space and computational effort
are still important, and will remain so for a while.  Please don't
encourage bloat.

...

>Actually, there is an even more radical update that I would have loved
>FreeBSD to have initiated. Instead, the credit has gone to Microsoft.
>The simple thing is when a system has multiple gigabytes of RAM, the OS
>should be able give an option to the user of completely doing away with
>swapping and force all the action in real, physical memory instead.

??? Who is giving them that credit?  This isn't new.  You already have
some control over swapping via several oids:

vm.swap_enabled
vm.disable_swapspace_pageouts
vm.defer_swapspace_pageouts
vm.swap_idle_enabled
vm.swap_idle_threshold1
vm.swap_idle_threshold2
etc.

See, for example, tuning(7).  These have been around for ages (well,
at least since June 1996).  You can also build your kernel with:

options NO_SWAPPING

which takes precedence over these settings.  That option has been
around even longer. Linux has corresponding features, although they
didn't always work well on older kernels.

More recently, kib@ has just committed some changes that allow for
finer control of swapping, and, in the opposite direction, "anonymous
memory",  in his overcommit patches:

http://svn.freebsd.org/changeset/base/194766
http://svn.freebsd.org/changeset/base/194767
http://people.freebsd.org/~kib/overcommit/


b.
___
freebsd-questions@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-questions
To unsubscribe, send any mail to "freebsd-questions-unsubscr...@freebsd.org"

Re: Best practices for securing SSH server

[RW]

On Tue, 23 Jun 2009 22:37:12 +0200
Erik Norgaard  wrote:


> You're right, as long as port-knocking as a first pass authentication 
> scheme is not in wide spread use, then any attackers will not waste
> time port-knocking. If ever port-knocking becomes common, attackers
> will adapt and start knocking.

It would be fairly straightforward to prevent that by having a
combination of knocking ports and secret guard ports. When a guard port
gets hit the sequence is broken, and the source IP gets blocked for a
while.
___
freebsd-questions@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-questions
To unsubscribe, send any mail to "freebsd-questions-unsubscr...@freebsd.org"

Re: Best practices for securing SSH server

[Erik Norgaard]

RW wrote:

On Tue, 23 Jun 2009 22:37:12 +0200
Erik Norgaard  wrote:

You're right, as long as port-knocking as a first pass authentication 
scheme is not in wide spread use, then any attackers will not waste

time port-knocking. If ever port-knocking becomes common, attackers
will adapt and start knocking.


It would be fairly straightforward to prevent that by having a
combination of knocking ports and secret guard ports. When a guard port
gets hit the sequence is broken, and the source IP gets blocked for a
while.


Great: Wouldn't that be the same as monitoring failed login attempts and 
temporarily blacklisting ips that repeatedly connect through standard 
methods?


Point remains: Adding port knocking does not solve any security problem, 
it only adds complexity, cost, points of failure, inconvenience etc 
while making your problem appear differently and leaving you with the 
illusion of being more secure.


BR, Erik
--
Erik Nørgaard
Ph: +34.666334818/+34.915211157  http://www.locolomo.org
___
freebsd-questions@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-questions
To unsubscribe, send any mail to "freebsd-questions-unsubscr...@freebsd.org"

Re: Best practices for securing SSH server

[cpghost]

On Wed, Jun 24, 2009 at 03:53:15PM +0200, Erik Norgaard wrote:
> RW wrote:
> > On Tue, 23 Jun 2009 22:37:12 +0200
> > Erik Norgaard  wrote:
> > 
> >> You're right, as long as port-knocking as a first pass authentication 
> >> scheme is not in wide spread use, then any attackers will not waste
> >> time port-knocking. If ever port-knocking becomes common, attackers
> >> will adapt and start knocking.
> > 
> > It would be fairly straightforward to prevent that by having a
> > combination of knocking ports and secret guard ports. When a guard port
> > gets hit the sequence is broken, and the source IP gets blocked for a
> > while.
> 
> Great: Wouldn't that be the same as monitoring failed login attempts and 
> temporarily blacklisting ips that repeatedly connect through standard 
> methods?

Hmmm..., you're right on this point.

But port knocking can be useful and provide more security *if* you
modify the kocking sequence algorithmically and make it, e.g. a
function of time, source IP/range (and other factors). This could
prevent a whole class of replay-attacks.

Of course, you can modify the keys/passwords algorithmically and
make them a function of time, source IP etc. as well... ;-)

And while we're at it: how about real OPIE? Or combining SSH keys,
OPIE, and port knocking?

> Erik N?rgaard
> Ph: +34.666334818/+34.915211157  http://www.locolomo.org

-cpghost.

-- 
Cordula's Web. http://www.cordula.ws/
___
freebsd-questions@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-questions
To unsubscribe, send any mail to "freebsd-questions-unsubscr...@freebsd.org"

Re: The question of moving vi to /bin

[cpghost]

On Wed, Jun 24, 2009 at 06:13:49AM -0700, b. f. wrote:
> > On Tuesday 23 June 2009 15:41:48 Manish Jain wrote:
> 
> >About ed first. I might annoy a few people (which would gladden me in
> >this particular case), but ed was just one of Ken Thompson's nightmares
> >which he managed to reproduce in Unix with great precision. By no
> >stretch of imagination would it qualify as an editor, because an editor
> >can meaningfully edit only what it can first show. And ed has never had
> >anything to show. A modern operating system like FreeBSD should really
> >be kicking ed out of the distribution completely : bad ideas don't have
> >to be necessarily perpetuated just for the sake of compliance with the
> >original concept of Unix.
> 
> If you want to make a case for replacing ed(1), you're going to have
> to come up with some concrete reasons for doing so, not just make a
> (long and hyperbolic) statement that you don't like it.

Please don't touch/remove ed(1)!

  * It's still very useful on non-curses/termcap capable terminals
like raw serial lines etc.

  * It's also very useful in batch/script mode, as there are some
multi-line text processing problems that you can't tackle with
sed(1) alone, and where awk(1) or even perl, python etc.. are
overkill.

-cpghost.

-- 
Cordula's Web. http://www.cordula.ws/
___
freebsd-questions@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-questions
To unsubscribe, send any mail to "freebsd-questions-unsubscr...@freebsd.org"

Re: The question of moving vi to /bin

[Chris Rees]

2009/6/24 cpghost :
> On Wed, Jun 24, 2009 at 06:13:49AM -0700, b. f. wrote:
>> > On Tuesday 23 June 2009 15:41:48 Manish Jain wrote:
>>
>> >About ed first. I might annoy a few people (which would gladden me in
>> >this particular case), but ed was just one of Ken Thompson's nightmares
>> >which he managed to reproduce in Unix with great precision. By no
>> >stretch of imagination would it qualify as an editor, because an editor
>> >can meaningfully edit only what it can first show. And ed has never had
>> >anything to show. A modern operating system like FreeBSD should really
>> >be kicking ed out of the distribution completely : bad ideas don't have
>> >to be necessarily perpetuated just for the sake of compliance with the
>> >original concept of Unix.
>>
>> If you want to make a case for replacing ed(1), you're going to have
>> to come up with some concrete reasons for doing so, not just make a
>> (long and hyperbolic) statement that you don't like it.
>
> Please don't touch/remove ed(1)!
>
>  * It's still very useful on non-curses/termcap capable terminals
>    like raw serial lines etc.
>
>  * It's also very useful in batch/script mode, as there are some
>    multi-line text processing problems that you can't tackle with
>    sed(1) alone, and where awk(1) or even perl, python etc.. are
>    overkill.
>
> -cpghost.
>

I may be mistaken, but isn't ed required for POSIX compliance?

Chris



-- 
A: Because it messes up the order in which people normally read text.
Q: Why is top-posting such a bad thing?
A: Top-posting.
Q: What is the most annoying thing in a mailing list?
___
freebsd-questions@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-questions
To unsubscribe, send any mail to "freebsd-questions-unsubscr...@freebsd.org"

Re: The question of moving vi to /bin

[Jonathan McKeown]

On Wednesday 24 June 2009 12:59:13 Manish Jain wrote:

> About ed first. I might annoy a few people (which would gladden me in
> this particular case), but ed was just one of Ken Thompson's nightmares
> which he managed to reproduce in Unix with great precision. By no
> stretch of imagination would it qualify as an editor, because an editor
> can meaningfully edit only what it can first show. And ed has never had
> anything to show. A modern operating system like FreeBSD should really
> be kicking ed out of the distribution completely : bad ideas don't have
> to be necessarily perpetuated just for the sake of compliance with the
> original concept of Unix.

Hold on. I didn't claim it was a *good* editor - I was reacting to your 
suggestion that /bin didn't contain an editor at all. ed(1)'s interface is 
certainly minimal, but it's easy enough to list lines in the file you're 
editing, contrary to what you seem to be saying - to list every line of the 
file, try the two characters , l.

However, if you want a more visual editor, perhaps /usr/bin/ee (which is just 
over 10K bigger than /bin/ed) would do?

You also suggested doing away with ed and /rescue/vi altogether. You may not 
need statically-linked tools very often, but when you do need them, you 
*REALLY* need them. Don't suggest throwing them away without thinking through 
the implications.

Jonathan
___
freebsd-questions@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-questions
To unsubscribe, send any mail to "freebsd-questions-unsubscr...@freebsd.org"

Re: Best practices for securing SSH server

[Daniel Underwood]

> Point remains: Adding port knocking does not solve any security problem, it 
> only adds
> complexity, cost, points of failure, inconvenience etc while making your 
> problem appear
> differently and leaving you with the illusion of being more secure.

I think that's grossly overstated, if not just plain wrong.  Ceteris
paribus, a system with port knocking is almost certainly more secure
than a system without port knocking. It's not a guarantee against
penetration.  But even if it's only a heightened "degreee" of security
not an additional "kind" of security measure (as you argue), it's
still heightened security.
___
freebsd-questions@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-questions
To unsubscribe, send any mail to "freebsd-questions-unsubscr...@freebsd.org"

Re: Best practices for securing SSH server

[Erik Norgaard]

cpghost wrote:

On Wed, Jun 24, 2009 at 03:53:15PM +0200, Erik Norgaard wrote:
But port knocking can be useful and provide more security *if* you
modify the kocking sequence algorithmically and make it, e.g. a
function of time, source IP/range (and other factors). This could
prevent a whole class of replay-attacks.

Of course, you can modify the keys/passwords algorithmically and
make them a function of time, source IP etc. as well... ;-)


I don't think it's worth wasting time trying to repair a conceptually 
bad idea, in particular when there are so many alternatives.


Whichever way you turn around this idea, it boils down to a shared 
secret. The security of a shared secret is inversely proportional to the 
people knowing it, while the trouble of changing it is proportional to 
the number knowing it.


You've already got individual passwords in place. If your knock 
sequence/shared secret is randomly chosen of say 1 million (any number 
will do for the example) won't you get better security increasing the 
entropy of the individual passwords equivalently?



And while we're at it: how about real OPIE? Or combining SSH keys,
OPIE, and port knocking?


What is the easier solution: implement port knocking or doubling the 
length of your ssh keys?


Each of the technologies you mention can be tuned for higher security 
using longer passwords, checking entropy when people choose a new 
password, more ports in the range of your combination, more knocks etc.


I don't get why you wish to combine different technologies rather than 
tune the well tested and tried already implemented out of the box 
methods for higher security.


BR, Erik

--
Erik Nørgaard
Ph: +34.666334818/+34.915211157  http://www.locolomo.org
___
freebsd-questions@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-questions
To unsubscribe, send any mail to "freebsd-questions-unsubscr...@freebsd.org"

Versioning File System for FreeBSD?

[cpghost]

Hi,

is there anybody working on a versioning file system for FreeBSD
right now?

Maybe something like what's discussed here?
  http://www.pdl.cmu.edu/PDL-FTP/Secure/FAST03_abs.html

I don't care if it is native or a layer, geom-ified, fuse-based,
or even if it uses subversion as its backend, as long as it
provides some kind of transparent versioning.

Anything like that in the works?

Thanks,
-cpghost.

-- 
Cordula's Web. http://www.cordula.ws/
___
freebsd-questions@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-questions
To unsubscribe, send any mail to "freebsd-questions-unsubscr...@freebsd.org"

Re: Best practices for securing SSH server

[cpghost]

On Wed, Jun 24, 2009 at 04:50:01PM +0200, Erik Norgaard wrote:
> cpghost wrote:
> > On Wed, Jun 24, 2009 at 03:53:15PM +0200, Erik Norgaard wrote:
> > But port knocking can be useful and provide more security *if* you
> > modify the kocking sequence algorithmically and make it, e.g. a
> > function of time, source IP/range (and other factors). This could
> > prevent a whole class of replay-attacks.
> > 
> > Of course, you can modify the keys/passwords algorithmically and
> > make them a function of time, source IP etc. as well... ;-)
> 
> I don't think it's worth wasting time trying to repair a conceptually 
> bad idea, in particular when there are so many alternatives.
> 
> Whichever way you turn around this idea, it boils down to a shared 
> secret. The security of a shared secret is inversely proportional to the 
> people knowing it, while the trouble of changing it is proportional to 
> the number knowing it.
> 
> You've already got individual passwords in place. If your knock 
> sequence/shared secret is randomly chosen of say 1 million (any number 
> will do for the example) won't you get better security increasing the 
> entropy of the individual passwords equivalently?

Agreed.

> > And while we're at it: how about real OPIE? Or combining SSH keys,
> > OPIE, and port knocking?
> 
> What is the easier solution: implement port knocking or doubling the 
> length of your ssh keys?

It all boils down to this: do you login from a secure machine
or not? Each tool has its own set of uses. When I want to log in
from a public terminal, I prefer OPIE; when I log in from home,
I prefer SSH keys. Port knocking is an interesting technique, but
as you pointed out, its only useful on machines with very few
accounts.

> Each of the technologies you mention can be tuned for higher security 
> using longer passwords, checking entropy when people choose a new 
> password, more ports in the range of your combination, more knocks etc.
> 
> I don't get why you wish to combine different technologies rather than 
> tune the well tested and tried already implemented out of the box 
> methods for higher security.

I totally agree.

> BR, Erik
> 
> -- 
> Erik N?rgaard
> Ph: +34.666334818/+34.915211157  http://www.locolomo.org

-cpghost.

-- 
Cordula's Web. http://www.cordula.ws/
___
freebsd-questions@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-questions
To unsubscribe, send any mail to "freebsd-questions-unsubscr...@freebsd.org"

Re: cups&samba jailed

[Daniel Bye]

On Tue, Jun 23, 2009 at 08:07:19PM -0500, Derek Funk wrote:
> Attempting to setup cups and samba into a jail. How do you mount/add 
> device node /dev/ulpt0 within a jail.
> Essentially I would like to know, how to add device nodes within jail 
> /dev for specifically the devices I want?

You need to create some devfs rules, which live in a file called
/etc/devfs.rules in the HOST system. As an example to get you going, here
is what I use (edited for brevity):

[localrules=101]
add path 'da*'  mode 0664 group operator
add path 'acd*' mode 0666 group operator
add path 'cd*'  mode 0666 group operator

[hide_all=201]
add hide

[unhide_basic=301]
add path null unhide
add path zero unhide
add path crypto unhide
add path random unhide
add path urandom unhide
add path net unhide
add path net/lo0 unhide
add path net/nfe0 unhide

[unhide_login=401]
add path 'ptyp*' unhide
add path 'ptyq*' unhide
add path 'ptyr*' unhide
..

# Devices usually found in a jail.
#
[devfsrules_jail=501]
add include $hide_all
add include $unhide_basic
add include $unhide_login


And then in /etc/rc.conf, you'll need a couple of extra settings:

devfs_system_ruleset="localrules"

jail_jailname_devfs_ruleset="devfsrules_jail"

In your case, you'd want to put the printer device node in either one of
the already defined rulesets, or in a new set which you then include in 
the [devfsrules_jail=501] section.

Dan

-- 
Daniel Bye
 _
  ASCII ribbon campaign ( )
 - against HTML, vCards and  X
- proprietary attachments in e-mail / \


pgpSjwZEYDpx7.pgp
Description: PGP signature

Isolating high cpu load at function level

[Gary Gatten]

Hello,

 

I have a process with several threads - the main "worker" threads
typically use < 20% CPU - but after upgrading to a new version they're
now using > 90% cpu.  I'm trying to determine what function these
threads are performing that's requiring so much more cpu.  Is it bad
code? I bug in a library I linked against?  What?

 

I've tried gdb with list, info threads, info stack, bt full.  I can make
sense of some of it.  I guess what I'm hoping for is something like
"top" at the thread level, such that functions that thread perform are
sorted highest util (time/whatever).

 

TIA for any help!

 

Gary

 









"This email is intended to be reviewed by only the intended recipient
 and may contain information that is privileged and/or confidential.
 If you are not the intended recipient, you are hereby notified that
 any review, use, dissemination, disclosure or copying of this email
 and its attachments, if any, is strictly prohibited.  If you have
 received this email in error, please immediately notify the sender by
 return email and delete this email from your system."


___
freebsd-questions@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-questions
To unsubscribe, send any mail to "freebsd-questions-unsubscr...@freebsd.org"

Re: upgrading installed ports: time to do it ?

[mfv]

On Monday, 22 June 2009 16:48:02 RW wrote:
> On Mon, 22 Jun 2009 20:58:41 +0100
>
> Chris Whitehouse  wrote:
> > I'll probably get flamed for this but since I've been using
> > ports-mgmt/portmanager I've almost forgotten
> > about /usr/ports/UPDATING and all that pkgdb -Fu stuff or whatever it
> > was. I've upgraded ports just by doing 'portmanager -u' over one or
> > two quite major changes and not had any problems that haven't been
> > down to an individual ports.
>
> You still need to read UPDATING, portmanager handles some of the
> issues automatically, but not all.
> ___
> freebsd-questions@freebsd.org mailing list
> http://lists.freebsd.org/mailman/listinfo/freebsd-questions
> To unsubscribe, send any mail to
> "freebsd-questions-unsubscr...@freebsd.org"

Hello,

Here is a perl hack I use to automatically read and parse UPDATING as part of 
my daily upgrade routine.  It is part of a larger set of five scripts which 
use:
 1. "csup" to update ports
 2. "make index" to update the /usr/ports/INDEX
 3. "pkg_version" to identify the ports that need upgrading
 4. "portfetch" to download the tarballs
 5. a script to display the relevant contents, if any, of UPDATING using the
hack shown below and the contents identified in step 3 above.

These five scripts are combined in a master script (csup-all) which I invoke 
the first thing in the morning.  After doing some other morning chores I then 
run "portconfig -a -v" to set up any configuration settings prior to running 
"portmaster -a -u".  Everything is automatic except for the configuration.

Here is the perl hack.  It can be improved by comparing the ports that need to 
be updated (step 3) with the ports specified within UPDATING (step 5).  The 
embedded ansi codes will work with the default FreeBSD console settings, 
otherwise they can be removed.

#!/usr/bin/perl 

#
# file:csup-update.pl
#   

# created: 2006-07-16   

#   

# purpose: To review update notes in /usr/ports/UPDATING

#  This program will only display those notes issued

#  since last csup  
  
#   

# algorithm: Each line of the file /usr/ports/UPDATING is scanned and if

#  it finds a date in the form ^mmdd$ the date is assigned  
   
#  to the variable $date.  Otherwise all non-date lines are printed 

#  to STDOUT.  As soon as this program finds a date older than the  

#  last update this program quits and prints an appropriate closing 

#  message. 

#   

unless ( open ( MYFILE, "/usr/ports/UPDATING" ) ) {
die ("Cannot open input file /usr/ports/UPDATING.\n") ;
}

unless ( open ( LASTUPDATE, "/root/bin/csup-lastupdate.txt" ) ) {
die ("Cannot open file csup-lastupdate.txt.\n") ;
}

$eof = '' ;
$date = $lastupdate =  ;
$line =  ;
$count = 0 ;

while ( $line ne $eof ) {
if ( $line =~ /^2\d{7}/ ) {
$date = $line ;
$date =~ tr/://d ;
$count++ ;
}

if ( ( $date - $lastupdate ) >= 0 ) {
if ( $line =~ /^2\d{7}/ ) {
print ("^[[32m$line^[[0m") ;
} else {
print ("^[[0m$line") ;
}
$line =  ;
$date = $lastupdate ;
} else {
$count-- ;
if ( $count == 0 ) {
print ( "^[[36mThere are no updates to review. ") ;
} elsif ( $count == 1 ) {
print ( "^[[36mThere is only one update to review. ") ;
} else {
print ( "^[[36mThere are $count updates to review. ") ;
}
chop  ( $lastupdate ) ;
print ( "The last run of csup was on $lastupdate.^[[0m\n\n"  ) ;

exit ;
}
}
# EoF

___
freebsd-questions@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-questions
To unsubscribe, send any mail to "freebsd-questions-unsubscr...@freebsd.org"

Re: The question of moving vi to /bin

[Chad Perrin]

On Wed, Jun 24, 2009 at 04:22:19PM +0200, Jonathan McKeown wrote:
> 
> You also suggested doing away with ed and /rescue/vi altogether. You may not 
> need statically-linked tools very often, but when you do need them, you 
> *REALLY* need them. Don't suggest throwing them away without thinking through 
> the implications.

I think the intent was to do away with /bin/ed and /rescue/vi in favor of
/bin/vi -- not to do away with /bin/ed and /rescue/vi and replace them
with nothing.

-- 
Chad Perrin [ original content licensed OWL: http://owl.apotheon.org ]
Quoth Alan Kay: "I invented the term 'Object-Oriented', and I can tell
you I did not have C++ in mind."


pgpN8iyxVmGlT.pgp
Description: PGP signature

Re: The question of moving vi to /bin

[Chad Perrin]

On Wed, Jun 24, 2009 at 06:13:49AM -0700, b. f. wrote:
> > On Tuesday 23 June 2009 15:41:48 Manish Jain wrote:
> 
> >That's the whole problem of /rescue/vi. When you suddenly find yourself
> >in single-user mode, the last thing you want to do is realise that
> >tweaking is needed for something which should work normally just when
> >you need it, and quickly too.
> 
> Yes.  But there have been some recent changes:
> 
> http://svn.freebsd.org/changeset/base/194628
> 
> that suggest that this problem is being addressed.

That's definitely good news.  There isn't much point in putting something
in /rescue that won't work when other filesystems won't mount.


> 
> >But why are we talking about a few hundred
> >kilos for such a basic utility as vi in times when everyone has hundreds
> >of GB's on the disk, and the / partition itself is 512 MB by default.
> >The BSD concept of having vi under /usr originated when resources were
> >less by a factor of thousands (<= (100 MB disks), <= (8 MB physical RAM)
> >and so on). When we are well past those kind of constraints, the concept
> >needs an rethink.
> 
> No, we're not.  A lot of people are still using old hardware, or
> embedded hardware, where efficiency in space and computational effort
> are still important, and will remain so for a while.  Please don't
> encourage bloat.

I sympathize with the desire to keep "bloat" down for the minimal default
case.  Embedded systems were the first examples that came to mind for
cases where having vi in /bin might not be ideal.

On the other hand, I don't see any reason to refuse to offer an optional
install of /bin/vi for those who prefer it and don't want to have to
brute-force "install" it by manually copying it, thus eliminating
relatively simple and easy upgrades when security concerns demand it.

-- 
Chad Perrin [ original content licensed OWL: http://owl.apotheon.org ]
Quoth Jon Postel, RFC 761: "[B]e conservative in what you do, be liberal
in what you accept from others."


pgp9tOWGypNtz.pgp
Description: PGP signature

Re: Versioning File System for FreeBSD?

[Roland Smith]

On Wed, Jun 24, 2009 at 05:04:22PM +0200, cpghost wrote:
> Hi,
> 
> is there anybody working on a versioning file system for FreeBSD
> right now?

> I don't care if it is native or a layer, geom-ified, fuse-based,
> or even if it uses subversion as its backend, as long as it
> provides some kind of transparent versioning.

You could try devel/git? It's not a file system, but a very efficient
directory content tracker/version control system. One of the things I
use it for is to keep a certain directory in sync between a desktop and
a laptop. It works equally well with text or binary files.

Or maybe http://www.nongnu.org/libsqlfs/ will do what you want? Haven't
tried that, though.

Roland
-- 
R.F.Smith   http://www.xs4all.nl/~rsmith/
[plain text _non-HTML_ PGP/GnuPG encrypted/signed email much appreciated]
pgp: 1A2B 477F 9970 BA3C 2914  B7CE 1277 EFB0 C321 A725 (KeyID: C321A725)


pgp2oszWbtvQL.pgp
Description: PGP signature

error when install plplot - lasi

[cblasius]

Hello,

I see this error on two machines i386 and amd64 on FreeBSD-7.2-RELEASE
Is this error also present to you?


# portmaster /usr/ports/math/plplot

...
[ 77%] Built target example0
[ 88%] Built target example1
[100%] Built target example2
Installing the project stripped...
-- Install configuration: ""
-- Installing: /usr/local/libdata/pkgconfig/lasi.pc
-- Installing: /usr/local/include/LASi.h
-- Installing: /usr/local/share/lasi/doc/libLASi-1.1.0/html
-- Installing: /usr/local/share/lasi/doc/libLASi-1.1.0/html/user
-- Installing: /usr/local/share/lasi/doc/libLASi-1.1.0/html/user/html
-- Installing: /usr/local/share/lasi/doc/libLASi-1.1.0/html/user/html/classLASi_
1_1setFont-members.html
-- Installing: /usr/local/share/lasi/doc/libLASi-1.1.0/html/user/html/classLASi_
1_1PostscriptDocument_1_1GlyphId-members.html
-- Installing: /usr/local/share/lasi/doc/libLASi-1.1.0/html/user/html/tab_l.gif
-- Installing: /usr/local/share/lasi/doc/libLASi-1.1.0/html/user/html/classLASi_
1_1PostscriptDocument-members.html
-- Installing: /usr/local/share/lasi/doc/libLASi-1.1.0/html/user/html/classLASi_
1_1oPostscriptStream.html
-- Installing: /usr/local/share/lasi/doc/libLASi-1.1.0/html/user/html/namespacem
embers.html
-- Installing: /usr/local/share/lasi/doc/libLASi-1.1.0/html/user/html/tab_b.gif
-- Installing: /usr/local/share/lasi/doc/libLASi-1.1.0/html/user/html/classLASi_
1_1setFontSize.html
-- Installing: /usr/local/share/lasi/doc/libLASi-1.1.0/html/user/html/doxygen.cs
s
-- Installing: /usr/local/share/lasi/doc/libLASi-1.1.0/html/user/html/classLASi_
1_1PostscriptDocument_1_1write__glyph__routine__to__stream-members.html
-- Installing: /usr/local/share/lasi/doc/libLASi-1.1.0/html/user/html/tabs.css
-- Installing: /usr/local/share/lasi/doc/libLASi-1.1.0/html/user/html/namespacem
embers_eval.html
-- Installing: /usr/local/share/lasi/doc/libLASi-1.1.0/html/user/html/classLASi_
1_1oPostscriptStream-members.html
-- Installing: /usr/local/share/lasi/doc/libLASi-1.1.0/html/user/html/dir_ced8ec
04faf1f39c38b8acccde1582aa.html
-- Installing: /usr/local/share/lasi/doc/libLASi-1.1.0/html/user/html/LASi_8h.ht
ml
-- Installing: /usr/local/share/lasi/doc/libLASi-1.1.0/html/user/html/classLASi_
1_1show.html
-- Installing: /usr/local/share/lasi/doc/libLASi-1.1.0/html/user/html/LASi_8h-so
urce.html
-- Installing: /usr/local/share/lasi/doc/libLASi-1.1.0/html/user/html/functions_
type.html
-- Installing: /usr/local/share/lasi/doc/libLASi-1.1.0/html/user/html/globals.ht
ml
-- Installing: /usr/local/share/lasi/doc/libLASi-1.1.0/html/user/html/globals_de
fs.html
-- Installing: /usr/local/share/lasi/doc/libLASi-1.1.0/html/user/html/files.html
-- Installing: /usr/local/share/lasi/doc/libLASi-1.1.0/html/user/html/classLASi_
1_1PostscriptDocument_1_1write__glyph__routine__to__stream.html
-- Installing: /usr/local/share/lasi/doc/libLASi-1.1.0/html/user/html/classLASi_
1_1show-members.html
-- Installing: /usr/local/share/lasi/doc/libLASi-1.1.0/html/user/html/tab_r.gif
-- Installing: /usr/local/share/lasi/doc/libLASi-1.1.0/html/user/html/doxygen.pn
g
-- Installing: /usr/local/share/lasi/doc/libLASi-1.1.0/html/user/html/functions_
func.html
-- Installing: /usr/local/share/lasi/doc/libLASi-1.1.0/html/user/html/dirs.html
-- Installing: /usr/local/share/lasi/doc/libLASi-1.1.0/html/user/html/classLASi_
1_1PostscriptDocument.html
-- Installing: /usr/local/share/lasi/doc/libLASi-1.1.0/html/user/html/functions_
rela.html
-- Installing: /usr/local/share/lasi/doc/libLASi-1.1.0/html/user/html/annotated.
html
-- Installing: /usr/local/share/lasi/doc/libLASi-1.1.0/html/user/html/classLASi_
1_1setFontSize-members.html
-- Installing: /usr/local/share/lasi/doc/libLASi-1.1.0/html/user/html/namespacem
embers_enum.html
-- Installing: /usr/local/share/lasi/doc/libLASi-1.1.0/html/user/html/classLASi_
1_1PostscriptDocument_1_1GlyphId.html
-- Installing: /usr/local/share/lasi/doc/libLASi-1.1.0/html/user/html/index.html
-- Installing: /usr/local/share/lasi/doc/libLASi-1.1.0/html/user/html/classLASi_
1_1setFont.html
-- Installing: /usr/local/share/lasi/doc/libLASi-1.1.0/html/user/html/namespacem
embers_func.html
-- Installing: /usr/local/share/lasi/doc/libLASi-1.1.0/html/user/html/functions.
html
-- Installing: /usr/local/share/lasi/doc/libLASi-1.1.0/html/user/html/namespaces
.html
-- Installing: /usr/local/share/lasi/doc/libLASi-1.1.0/html/user/html/namespaceL
ASi.html
-- Installing: /usr/local/share/lasi/doc/libLASi-1.1.0/html/developer
-- Installing: /usr/local/share/lasi/doc/libLASi-1.1.0/html/developer/html
-- Installing: /usr/local/share/lasi/doc/libLASi-1.1.0/html/developer/html/class
LASi_1_1setFont-members.html
-- Installing: /usr/local/share/lasi/doc/libLASi-1.1.0/html/developer/html/class
LASi_1_1PostscriptDocument_1_1GlyphId-members.html
-- Installing: /usr/local/share/lasi/doc/libLASi-1.1.0/html/developer/html/class
StringDimensions.html
-- Installing: /usr/local/share/lasi/doc/libLASi-1.1.0/html/developer/html/tab_l
.gif
-- Installing: /usr/local/share/

Re: ~/.ssh directory permissions

[Brent Bloxam]

Chris Rees wrote:


Although I think it's not a big deal, as long as your id_?sa has
permissions 600 like mine, or even 400.

Chris



The man page for ssh(1) provides a lot of detail about the sensitivity 
of the various files related to ssh. To quote it regarding a few of them:



 ~/.ssh/
 This directory is the default location for all user-specific 
configuration and authentication information.  There is no
 general requirement to keep the entire contents of this directory 
secret, but the recommended permissions are
 read/write/execute for the user, and not accessible by others.


So as you can see, 700 is recommended (but not necessary).


 ~/.ssh/identity
 ~/.ssh/id_dsa
 ~/.ssh/id_rsa
 Contains the private key for authentication.  These files contain 
sensitive data and should be readable by the user but not
 accessible by others (read/write/execute).  ssh will simply ignore 
a private key file if it is accessible by others.  It is
 possible to specify a passphrase when generating the key which 
will be used to encrypt the sensitive part of this file
 using 3DES.


However, identity, id_dsa and id_rsa _must_ be 700 at a maximum. It's 
best to follow the recommendations from the man page unless you have 
very specific reasons for needing more lax permissions on these files.


Regards,
Brent
___
freebsd-questions@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-questions
To unsubscribe, send any mail to "freebsd-questions-unsubscr...@freebsd.org"

Re: Best practices for securing SSH server

[RW]

On Wed, 24 Jun 2009 17:12:59 +0200
cpghost  wrote:


> It all boils down to this: do you login from a secure machine
> or not? Each tool has its own set of uses. When I want to log in
> from a public terminal, I prefer OPIE; 

OPIE is probably fine in almost all cases, but you may wish to read the
following thread:

http://comments.gmane.org/gmane.os.freebsd.security.general/9272

___
freebsd-questions@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-questions
To unsubscribe, send any mail to "freebsd-questions-unsubscr...@freebsd.org"

Re: Versioning File System for FreeBSD?

[cpghost]

On Wed, Jun 24, 2009 at 06:37:55PM +0200, Roland Smith wrote:
> On Wed, Jun 24, 2009 at 05:04:22PM +0200, cpghost wrote:
> > Hi,
> > 
> > is there anybody working on a versioning file system for FreeBSD
> > right now?
> 
> > I don't care if it is native or a layer, geom-ified, fuse-based,
> > or even if it uses subversion as its backend, as long as it
> > provides some kind of transparent versioning.
> 
> You could try devel/git? It's not a file system, but a very efficient
> directory content tracker/version control system. One of the things I
> use it for is to keep a certain directory in sync between a desktop and
> a laptop. It works equally well with text or binary files.

Yes, that's one possibility. But just like Subversion (which I'm
using extensively here), it's not really transparent.

> Or maybe http://www.nongnu.org/libsqlfs/ will do what you want? Haven't
> tried that, though.

But does it really support versioning?

I was actually thinking of a real versioning file system, with an
extended POSIX API (yet to be defined), to access all revisions of
a file system, just like with Subversion revisions.

As an example: opendir(2) would grow an additional and optional
argument "revision" to select either HEAD or some revision of the
directory:

DIR *dirp;
dirp = opendir("/path/to/dir", 0);   /* open /path/to/file at HEAD */
dirp = opendir("/path/to/dir");  /* same as above, POSIX compat */
dirp = opendir("/path/to/dir", 323); /* open dir at revision 323 */

/* From here on, readdir() would retrieve /path/to/dir entries
   at the specified revision. */

open(2) could open a file at an earlier revision:

FILE *filep;

/* open file in HEAD */
filep = open("/path/to/file", O_RDONLY);

/* open same path, but at revision 323 */
filep = open("/path/to/file", O_RDONLY, /* 0666 */, 323);

unlink(2) would remove an entry from a directory, and bump the revision
of the directory. Accessing that path from the new revision wouldn't be
possible, but the file would still be there in an earlier revision.

Modifying a file would also create new revisions (e.g. at each
write(2), or at each close(2), that should be selectable).

Of course, there would be additional API calls to traverse the
list of revisions, to access meta data (properties?, tags?,
commit logs?, ...) etc., so that the file system remains manageable.

I didn't try them (yet), but on Linux, there are some experimental
versioning file systems like:
  http://www.ext3cow.com/Welcome.html
  http://tux3.org/

and there's a (unmaintained?) FUSE file system at:
  http://wayback.sourceforge.net/

all of which differ in the way POSIX API should be extended and
the semantics for versioning. But there's apparently nothing yet
in the works for FreeBSD. Perhaps some layer on top of existing
file systems, or an extension of UFS/FFS that stores versioning
meta data directly at the block level?

> Roland
> -- 
> R.F.Smith   http://www.xs4all.nl/~rsmith/
> [plain text _non-HTML_ PGP/GnuPG encrypted/signed email much appreciated]
> pgp: 1A2B 477F 9970 BA3C 2914  B7CE 1277 EFB0 C321 A725 (KeyID: C321A725)

-cpghost.

-- 
Cordula's Web. http://www.cordula.ws/
___
freebsd-questions@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-questions
To unsubscribe, send any mail to "freebsd-questions-unsubscr...@freebsd.org"

Re: Versioning File System for FreeBSD?

[cpghost]

On Wed, Jun 24, 2009 at 07:59:18PM +0200, cpghost wrote:
> open(2) could open a file at an earlier revision:
> 
> FILE *filep;

s/FILE */int /;

-cpghost.

-- 
Cordula's Web. http://www.cordula.ws/
___
freebsd-questions@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-questions
To unsubscribe, send any mail to "freebsd-questions-unsubscr...@freebsd.org"

7.2 system stuck trying at boot, trying to mount root device

[Forrest Aldrich]

I'm running a modest PC that has FreeBSD-7.2 installed (fairly current 
build from CVS).


Today, I did a "shutdown -r" to reboot the system.   When it returned, 
the console is reporting:


"Trying to mount root from ufs:/dev/ad4s1a"

I've gone through and restored the boot loader, this works fine (it's 
back to F1 or F2) -- it continues to do this.


I also did a proper mount, fsck, and umount under the LiveFS shell, 
which made no difference.


Then I tried a modest binary "upgrade" just in case.  No luck.

After Googling around, and not finding much more info than what I did, I 
figured I would ask here.   If I have to, I can ship off the data to 
another system (after I rebuild) and try to bring all it's functions 
back (but it's a lot, cyrus, etc).


The other messages I see on the console include GEOM output:

GEOM_LABEL:  Label for provider ad4s1a is ufsid/blahblah

then

GEOM_LABEL: Label for ufsid/blahblah removed.

Anyone know how I can rescue this?


Thanks.

___
freebsd-questions@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-questions
To unsubscribe, send any mail to "freebsd-questions-unsubscr...@freebsd.org"

Re: you're not going to believe this.

[Charlie Kester]

On Wed 24 Jun 2009 at 02:32:24 PDT free...@t41t.com wrote:


The lifetime and reliability of SSDs are less-than-or-equal-to the
lifetime and reliability of spinning magnetic drives, so don't buy an SSD
for that. Whether SSDs use less power is an open question. There's a lot
of data going either way. The last comparison I saw suggested spinning
drives average less power than their SSD counterparts. In any event, it's
not clear-cut yet. SSDs probably do generate less heat (but I've not seen
data on that). Of course, the access time on an SSD is order(s) of
magnitude less than for a spinning drive, and that's cause enough for
lots of people to buy one.


SSD's are/should also be favored in devices that are prone to mechanical
shocks.  E.g., tablet PC's, and handheld devices like cellphones, music
players or game players.
___
freebsd-questions@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-questions
To unsubscribe, send any mail to "freebsd-questions-unsubscr...@freebsd.org"

Re: 7.2 system stuck trying at boot, trying to mount root device

[Polytropon]

On Wed, 24 Jun 2009 14:13:41 -0400, Forrest Aldrich  wrote:
> I also did a proper mount, fsck, and umount under the LiveFS shell, 
> which made no difference.

I hope I'm just reading it in the wrong order. The correct
order is to 1st fsck, then mount, not vice versa. Never
fsck a mounted file system.



> The other messages I see on the console include GEOM output:
> 
> GEOM_LABEL:  Label for provider ad4s1a is ufsid/blahblah
> 
> then
> 
> GEOM_LABEL: Label for ufsid/blahblah removed.

This is completely normal today. As long as a file system is
not mounted, the label is provided. When it gets mounted, this
label is being removed. You see this on your console.



> Anyone know how I can rescue this?

Does /var/log/messages show something strange looking?



-- 
Polytropon
>From Magdeburg, Germany
Happy FreeBSD user since 4.0
Andra moi ennepe, Mousa, ...
___
freebsd-questions@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-questions
To unsubscribe, send any mail to "freebsd-questions-unsubscr...@freebsd.org"

Re: Versioning File System for FreeBSD?

[Roland Smith]

On Wed, Jun 24, 2009 at 07:59:18PM +0200, cpghost wrote:
> On Wed, Jun 24, 2009 at 06:37:55PM +0200, Roland Smith wrote:
> > On Wed, Jun 24, 2009 at 05:04:22PM +0200, cpghost wrote:
> > > Hi,
> > > 
> > > is there anybody working on a versioning file system for FreeBSD
> > > right now?
> > 
> > > I don't care if it is native or a layer, geom-ified, fuse-based,
> > > or even if it uses subversion as its backend, as long as it
> > > provides some kind of transparent versioning.
> > 
> > You could try devel/git? It's not a file system, but a very efficient
> > directory content tracker/version control system. One of the things I
> > use it for is to keep a certain directory in sync between a desktop and
> > a laptop. It works equally well with text or binary files.
> 
> Yes, that's one possibility. But just like Subversion (which I'm
> using extensively here), it's not really transparent.

What is? If you have to extend the API like you propose below, all
programs that want to use that feature have to be changed. So if you're
going around changing your program, why not have it interface to an existing
revision control that you are already familiar with? That seems a lot
easier that tacking revision control onto a filesystem!

Git is very good at efficiently storing the differences between
commits. And every copy of a directory under git control is a full-blown
repository, so you can experiment with a copy without fear of fouling up
your precious repository.

> I was actually thinking of a real versioning file system, with an
> extended POSIX API (yet to be defined), to access all revisions of
> a file system, just like with Subversion revisions.
> 
> As an example: opendir(2) would grow an additional and optional
> argument "revision" to select either HEAD or some revision of the
> directory:
> 
> DIR *dirp;
> dirp = opendir("/path/to/dir", 0);   /* open /path/to/file at HEAD */
> dirp = opendir("/path/to/dir");  /* same as above, POSIX compat */
> dirp = opendir("/path/to/dir", 323); /* open dir at revision 323 */
> 
> /* From here on, readdir() would retrieve /path/to/dir entries
>at the specified revision. */
> 
> open(2) could open a file at an earlier revision:
> 
> FILE *filep;
> 
> /* open file in HEAD */
> filep = open("/path/to/file", O_RDONLY);
> 
> /* open same path, but at revision 323 */
> filep = open("/path/to/file", O_RDONLY, /* 0666 */, 323);

There is some ambiguity here. Does 323 refer to a single file, or to the
state of its parent directory? If changing a file doesn't update the
version of its parent directory, then why have version numbers for
directories? On the other hand, if changing a file updates the revision
for the file and its parent directory, the revision for the root
directory will increase quite rapidly!

> unlink(2) would remove an entry from a directory, and bump the revision
> of the directory. Accessing that path from the new revision wouldn't be
> possible, but the file would still be there in an earlier revision.
> 
> Modifying a file would also create new revisions (e.g. at each
> write(2), or at each close(2), that should be selectable).

I don't know what you want to do use this for, but a simple trick (used
e.g. by Pro/Engineer) is to have your application append a version
number after the filename (e.g. "foo.prt.1") that is incremented every
time the file is saved. This does waste some disk space (or provides
redundancy, take your pick).
 
> Of course, there would be additional API calls to traverse the
> list of revisions, to access meta data (properties?, tags?,
> commit logs?, ...) etc., so that the file system remains manageable.

VMS had a filesystem that uses versioning: 
[http://en.wikipedia.org/wiki/Files-11]

> I didn't try them (yet), but on Linux, there are some experimental
> versioning file systems like:
>   http://www.ext3cow.com/Welcome.html
>   http://tux3.org/
> 
> and there's a (unmaintained?) FUSE file system at:
>   http://wayback.sourceforge.net/
> 
> all of which differ in the way POSIX API should be extended and
> the semantics for versioning. But there's apparently nothing yet
> in the works for FreeBSD. Perhaps some layer on top of existing
> file systems, or an extension of UFS/FFS that stores versioning
> meta data directly at the block level?
> 
> > Roland
> 
> -cpghost.
> 

-- 
R.F.Smith   http://www.xs4all.nl/~rsmith/
[plain text _non-HTML_ PGP/GnuPG encrypted/signed email much appreciated]
pgp: 1A2B 477F 9970 BA3C 2914  B7CE 1277 EFB0 C321 A725 (KeyID: C321A725)


pgpsKGcvW25kv.pgp
Description: PGP signature

Re: Versioning File System for FreeBSD?

[Polytropon]

On Wed, 24 Jun 2009 21:11:25 +0200, Roland Smith  wrote:
> VMS had a filesystem that uses versioning: 
> [http://en.wikipedia.org/wiki/Files-11]

That's the first thing that came into my mind when reading this
message. See LOGIN.COM;1 and then rm -rf /*.*;* :-)

But it's not "had", it's "has", because VMS and its file system
does still exist.



-- 
Polytropon
>From Magdeburg, Germany
Happy FreeBSD user since 4.0
Andra moi ennepe, Mousa, ...
___
freebsd-questions@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-questions
To unsubscribe, send any mail to "freebsd-questions-unsubscr...@freebsd.org"

Re: you're not going to believe this.

[Gary Kline]

On Wed, Jun 24, 2009 at 11:48:00AM -0700, Charlie Kester wrote:
> On Wed 24 Jun 2009 at 02:32:24 PDT free...@t41t.com wrote:
> >
> >The lifetime and reliability of SSDs are less-than-or-equal-to the
> >lifetime and reliability of spinning magnetic drives, so don't buy an SSD
> >for that. Whether SSDs use less power is an open question. There's a lot
> >of data going either way. The last comparison I saw suggested spinning
> >drives average less power than their SSD counterparts. In any event, it's
> >not clear-cut yet. SSDs probably do generate less heat (but I've not seen
> >data on that). Of course, the access time on an SSD is order(s) of
> >magnitude less than for a spinning drive, and that's cause enough for
> >lots of people to buy one.
> 
> SSD's are/should also be favored in devices that are prone to mechanical
> shocks.  E.g., tablet PC's, and handheld devices like cellphones, music
> players or game players.


Interesting details.  I was a hardware logic major, not software,
but I got shunted into software and went withthe flow.  To all
the comments, pro/con, it looks that my earlier projection was
right.  It will indeed be awhile before there are reliable
solid-state devs that can replace the spinning disk.  And even
then, cross-backups and even having a tape backup of critical 
data is a must.  

That said, I still want to buy one of these sub-mini notebooks
this summer.  
-- 
 Gary Kline  kl...@thought.org  http://www.thought.org  Public Service Unix
http://jottings.thought.org   http://transfinite.thought.org
   For FBSD list: http://transfinite.thought.org/slicejourney.php
The 4.98a release of Jottings: http://jottings.thought.org/index.php

___
freebsd-questions@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-questions
To unsubscribe, send any mail to "freebsd-questions-unsubscr...@freebsd.org"

panic ohci_add_done

[lysergius2001]

Hi,

Could use some pointers here.  I have an AMD64 system Gigabyte GA-MA770
motherboard, 4 GB RAM, Athlon 64 CPU.  System won't boot.  Flags error,

panic ohci_add_done : addr 0x... not found

Then it reboots.  Tried disabling everything in the bios.  (Including usb
kbd and mouse)

At wit's end... Never seen anything like it.  Bo clue where to start.  Help
please.

-- 
Lysergius says "Stay light and trust gravity"
___
freebsd-questions@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-questions
To unsubscribe, send any mail to "freebsd-questions-unsubscr...@freebsd.org"

echo in sh calls write function repeatedly in kernel driver?

[Naeem Afzal]

I used this sample echo driver listed here:

http://www.freebsd.org/doc/en/books/arch-handbook/driverbasics-char.html and 
used Example 9-2 for 5.X FreeBSD. Modifed and added a printline in write 
function to display Count value:
I am using 7.1 FreeBSD version. I compiled the driver and ran the echo command, 
I see that driver's write function is being called 11 times if I use sh shell? 
Why is that? If I use bash, then write function is only called once which seems 
to be correct. Why sh buildin echo is send 11 writes? Any idea?


thanks & regards
naeem

# echo "1234" > /dev/echo
Opened device "echo" successfully.
Count value: 0
Count value: 1
Count value: 2
Count value: 3
Count value: 4
Count value: 5
Count value: 6
Count value: 7
Count value: 8
Count value: 9
Count value: 10
Closing device "echo."
# cat /dev/echo
Opened device "echo" successfully.
1234
Closing device "echo."


=
Driver's write function is defined as:

static int
echo_write(struct cdev *dev, struct uio *uio, int ioflag)
{
int err = 0;

   uprintf("Count value: %d\n",count);
/* Copy the string in from user memory to kernel memory */
err = copyin(uio->uio_iov->iov_base, echomsg->msg,
MIN(uio->uio_iov->iov_len, BUFFERSIZE - 1));

/* Now we need to null terminate, then record the length */
*(echomsg->msg + MIN(uio->uio_iov->iov_len, BUFFERSIZE - 1)) = 0;
echomsg->len = MIN(uio->uio_iov->iov_len, BUFFERSIZE);

if (err != 0) {
uprintf("Write failed: bad address!\n");
}
count++;
return(err);
}

___
freebsd-questions@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-questions
To unsubscribe, send any mail to "freebsd-questions-unsubscr...@freebsd.org"

Re: Versioning File System for FreeBSD?

[Morten Grunnet Buhl]

* cpghost  [2009-06-24 17:04 +0200]:
> Hi,
> 
> is there anybody working on a versioning file system for FreeBSD
> right now?
- I don't know how fare along hammerfs is in being ported to FreeBSD.
  But from what I have heard, feature-wise, it might be something that
  meets your needs.

  An alternative could be ZFS with its snapshot ability.

-- 
I have no signature!
___
freebsd-questions@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-questions
To unsubscribe, send any mail to "freebsd-questions-unsubscr...@freebsd.org"

Re: Versioning File System for FreeBSD?

[cpghost]

On Wed, Jun 24, 2009 at 09:11:25PM +0200, Roland Smith wrote:
> > Yes, that's one possibility. But just like Subversion (which I'm
> > using extensively here), it's not really transparent.
> 
> What is? If you have to extend the API like you propose below, all
> programs that want to use that feature have to be changed. So if you're
> going around changing your program, why not have it interface to an existing
> revision control that you are already familiar with? That seems a lot
> easier that tacking revision control onto a filesystem!

Yep, you're right. I thought about a way to extend the API in a
backwards compatible way, but that's not as easy or straight
forward as it seems. In fact, it opens a whole can of worms.

If the versioned file system isn't also POSIX compatible (where
everything happens in HEAD unless specified otherwise), it's
practically useless.

> Git is very good at efficiently storing the differences between
> commits. And every copy of a directory under git control is a full-blown
> repository, so you can experiment with a copy without fear of fouling up
> your precious repository.

That's true as well. I'm not very familiar with git (as opposed
to subversion), but I clearly see its advantages.

> > I was actually thinking of a real versioning file system, with an
> > extended POSIX API (yet to be defined), to access all revisions of
> > a file system, just like with Subversion revisions.
> > 
> > As an example: opendir(2) would grow an additional and optional
> > argument "revision" to select either HEAD or some revision of the
> > directory:
> > 
> > DIR *dirp;
> > dirp = opendir("/path/to/dir", 0);   /* open /path/to/file at HEAD */
> > dirp = opendir("/path/to/dir");  /* same as above, POSIX compat */
> > dirp = opendir("/path/to/dir", 323); /* open dir at revision 323 */
> > 
> > /* From here on, readdir() would retrieve /path/to/dir entries
> >at the specified revision. */
> > 
> > open(2) could open a file at an earlier revision:
> > 
> > FILE *filep;
> > 
> > /* open file in HEAD */
> > filep = open("/path/to/file", O_RDONLY);
> > 
> > /* open same path, but at revision 323 */
> > filep = open("/path/to/file", O_RDONLY, /* 0666 */, 323);
> 
> There is some ambiguity here. Does 323 refer to a single file, or to the
> state of its parent directory? If changing a file doesn't update the
> version of its parent directory, then why have version numbers for
> directories? On the other hand, if changing a file updates the revision
> for the file and its parent directory, the revision for the root
> directory will increase quite rapidly!

Quite true!

I see even more ambiguity here: What about a versioned file pointed
to by hard links from two versioned directories?

And even if the semantics were absolutely sound (can they be?), all
this meta data really needs to happen on a block level, e.g. how
described in that paper.

> > unlink(2) would remove an entry from a directory, and bump the revision
> > of the directory. Accessing that path from the new revision wouldn't be
> > possible, but the file would still be there in an earlier revision.
> > 
> > Modifying a file would also create new revisions (e.g. at each
> > write(2), or at each close(2), that should be selectable).
> 
> I don't know what you want to do use this for, but a simple trick (used
> e.g. by Pro/Engineer) is to have your application append a version
> number after the filename (e.g. "foo.prt.1") that is incremented every
> time the file is saved. This does waste some disk space (or provides
> redundancy, take your pick).

Yes, that's always possible. But that would defeat transparency.

And there's another problem here: what if two processes concurrently
save (commit?) the same file, and there's a merging conflict?

> > Of course, there would be additional API calls to traverse the
> > list of revisions, to access meta data (properties?, tags?,
> > commit logs?, ...) etc., so that the file system remains manageable.
> 
> VMS had a filesystem that uses versioning: 
> [http://en.wikipedia.org/wiki/Files-11]

I was thinking about this before starting this thread. But file
versioning (as opposed to full versioning that also includes
directory versioning) is probably relatively easy to implement.
At least, its semantics are unambiguous.

> > I didn't try them (yet), but on Linux, there are some experimental
> > versioning file systems like:
> >   http://www.ext3cow.com/Welcome.html
> >   http://tux3.org/
> > 
> > and there's a (unmaintained?) FUSE file system at:
> >   http://wayback.sourceforge.net/
> > 
> > all of which differ in the way POSIX API should be extended and
> > the semantics for versioning. But there's apparently nothing yet
> > in the works for FreeBSD. Perhaps some layer on top of existing
> > file systems, or an extension of UFS/FFS that stores versioning
> > meta data directly at the block level?

-cpghost.

-- 
Cordula's Web. http://www.cordula.ws/
___

Re: Versioning File System for FreeBSD?

[cpghost]

On Wed, Jun 24, 2009 at 11:26:50PM +0200, Morten Grunnet Buhl wrote:
> * cpghost  [2009-06-24 17:04 +0200]:
> > Hi,
> > 
> > is there anybody working on a versioning file system for FreeBSD
> > right now?
>
> - I don't know how fare along hammerfs is in being ported to FreeBSD.
>   But from what I have heard, feature-wise, it might be something that
>   meets your needs.

Ah, yes, that's interesting too. I'll investigate it. Thanks for
the hint!

>   An alternative could be ZFS with its snapshot ability.

IMHO, ZFS snapshots are a little bit too coarse versioning for what
I have in mind. I'm seeking something more precise. Not entirely
a subversion-on-filesystem replacement, but rather close, if possible.

Thanks,
-cpghost.

-- 
Cordula's Web. http://www.cordula.ws/
___
freebsd-questions@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-questions
To unsubscribe, send any mail to "freebsd-questions-unsubscr...@freebsd.org"

Re: Versioning File System for FreeBSD?

[Polytropon]

On Wed, 24 Jun 2009 23:57:34 +0200, cpghost  wrote:
> Yep, you're right. I thought about a way to extend the API in a
> backwards compatible way, but that's not as easy or straight
> forward as it seems. In fact, it opens a whole can of worms.
> 
> If the versioned file system isn't also POSIX compatible (where
> everything happens in HEAD unless specified otherwise), it's
> practically useless.

The question is: Do you want to take versioning support into
the file system intendedly? FreeBSD keeps most things on a
per-file basis (ordinary files, devices, processes etc.).
Versioning can always be added as a separate solution
(using versioning systems as separate programs) that does
not make any assumptions on the file system used. As you
concluded, the file system's complexity would of course
grow with those requirements. In addition to your arguments,
just imagine how a fsck for such a file system would have
to be implemented...




-- 
Polytropon
>From Magdeburg, Germany
Happy FreeBSD user since 4.0
Andra moi ennepe, Mousa, ...
___
freebsd-questions@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-questions
To unsubscribe, send any mail to "freebsd-questions-unsubscr...@freebsd.org"

Re: The question of moving vi to /bin

[Bruce Cran]

On Wed, 24 Jun 2009 06:13:49 -0700
"b. f."  wrote:

> ??? Who is giving them that credit?  This isn't new.  You already have
> some control over swapping via several oids:
> 
> vm.swap_enabled
> vm.disable_swapspace_pageouts
> vm.defer_swapspace_pageouts
> vm.swap_idle_enabled
> vm.swap_idle_threshold1
> vm.swap_idle_threshold2
> etc.
> 
> See, for example, tuning(7).  These have been around for ages (well,
> at least since June 1996).  You can also build your kernel with:
> 
> options NO_SWAPPING
> 
> which takes precedence over these settings.  That option has been
> around even longer. Linux has corresponding features, although they
> didn't always work well on older kernels.

It looks like the best explanation of NO_SWAPPING is 
http://docs.freebsd.org/cgi/getmsg.cgi?fetch=1067315+0+archive/2003/freebsd-current/20030413.freebsd-current

I found it after attempting to trim a powerpc kernel to see just how
much I could leave out - it looks like it's not possible to leave out
support for swapping.

-- 
Bruce Cran
___
freebsd-questions@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-questions
To unsubscribe, send any mail to "freebsd-questions-unsubscr...@freebsd.org"

Re: Versioning File System for FreeBSD?

[Roland Smith]

On Wed, Jun 24, 2009 at 11:57:34PM +0200, cpghost wrote:
> Quite true!
> 
> I see even more ambiguity here: What about a versioned file pointed
> to by hard links from two versioned directories?

The more I think about it, the more problems I can see. Look e.g. at
symbolic links. Or looking from the vc side, what about branches
(checking out an older version of a file and editing it). Does it
automatically become the new head, or are concurrent branches allowed?
 
> And even if the semantics were absolutely sound (can they be?), all
> this meta data really needs to happen on a block level, e.g. how
> described in that paper.

I really wonder if combining a filesystem and a version control system
is a good idea?

> > > unlink(2) would remove an entry from a directory, and bump the revision
> > > of the directory. Accessing that path from the new revision wouldn't be
> > > possible, but the file would still be there in an earlier revision.
> > > 
> > > Modifying a file would also create new revisions (e.g. at each
> > > write(2), or at each close(2), that should be selectable).
> > 
> > I don't know what you want to do use this for, but a simple trick (used
> > e.g. by Pro/Engineer) is to have your application append a version
> > number after the filename (e.g. "foo.prt.1") that is incremented every
> > time the file is saved. This does waste some disk space (or provides
> > redundancy, take your pick).
> 
> Yes, that's always possible. But that would defeat transparency.

Why? Larger number==later file. How more transparent could it be?
 
> And there's another problem here: what if two processes concurrently
> save (commit?) the same file, and there's a merging conflict?

I'd say that two processes should _never_ open the same file for writing
at the same time. Since the contents of the file are opaque to the file
system but not to the programs, it is impossible for the filesystem to
fix merge conflicts. 

If you have multiple programs working together only one should write to
the file in question. The others should communicate with the writing
program via IPC.

> > > Of course, there would be additional API calls to traverse the
> > > list of revisions, to access meta data (properties?, tags?,
> > > commit logs?, ...) etc., so that the file system remains manageable.
> > 
> > VMS had a filesystem that uses versioning: 
> > [http://en.wikipedia.org/wiki/Files-11]
> 
> I was thinking about this before starting this thread. But file
> versioning (as opposed to full versioning that also includes
> directory versioning) is probably relatively easy to implement.
> At least, its semantics are unambiguous.

Indeed. It seems the VMS filesystem just tacks a semicolon and a nummer
on to the filename.

Roland
-- 
R.F.Smith   http://www.xs4all.nl/~rsmith/
[plain text _non-HTML_ PGP/GnuPG encrypted/signed email much appreciated]
pgp: 1A2B 477F 9970 BA3C 2914  B7CE 1277 EFB0 C321 A725 (KeyID: C321A725)


pgpEkArHkSmA6.pgp
Description: PGP signature

cc1: error: unrecognized command line option "-mfdpic"

[Jin Guojun]

This option "-mfdpic" is shown in manual page for gcc 4.1 or later

  -mfdpic
  Select the FDPIC ABI, that uses function descriptors to represent
  pointers to functions.  Without any PIC/PIE-related options, it
  implies -fPIE.  With -fpic or -fpie, it assumes GOT entries and
  small data are within a 12-bit range from the GOT base address;
  with -fPIC or -fPIE, GOT offsets are computed with 32 bits.  
With a

  bfin-elf target, this option implies -msim.

However, tried all gcc 4.1.x, 4.2.x and 4.3.x with following test, and 
no one of them accept this

option:

%: echo "#include " | gcc43 -mfdpic - -E
cc1: error: unrecognized command line option "-mfdpic"
# 1 ""

%: echo "#include " | gcc43 -fdpic - -E
cc1: error: unrecognized command line option "-fdpic"
# 1 ""

where "-dpic" option is a voild option.
Does anyone know why "-mfdpic" option is missing from gcc4.x in FreeBSD 
distribution?

Is this due to some license issues?
If so, what is the other option to subtitute it?

Thanks,
-Jin

___
freebsd-questions@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-questions
To unsubscribe, send any mail to "freebsd-questions-unsubscr...@freebsd.org"

Re: The question of moving vi to /bin

[Manish Jain]

If you want to make a case for replacing ed(1), you're going to have
to come up with some concrete reasons for doing so, not just make a
(long and hyperbolic) statement that you don't like it.
  


Any Unix tool has to clearly fall either under the category of 
non-interactive (grep, sed, ex) or interactive (vi, wget, sysinstall). 
The case of non-interactive tools is simple : just do what you are told 
on the commandline and exit. For interactive tools, at a minimum, the 
application has to be show what data it is working on and what it does 
with the data when the user presses a key (or a series of them). ed was 
never meant to be non-interactive, and it does not fulfil the basic 
requirements of being interactive. That's one reason. Secondly, how many 
times does an average commandline user even think of using ed when he 
needs to edit a file, even in the extreme case where there are no 
alternatives ?



There have been some recent changes:

http://svn.freebsd.org/changeset/base/194628 



that suggest that this problem is being addressed.


Till the improvements are in place, we need the alternative of having vi 
under /bin rather than /usr/bin.


Actually, it surprises me to what extent the core of the FreeBSD 
community is enamoured with this idea of a micro-minimalistic base, in 
which it is practically impossible to do anything except run fsck. 
Matters don't stop there. Seeing the limitations of this approach, the 
community churns up wierd workarounds like /rescue/vi, when all that was 
needed was shift vi from /usr. You talk about the need for compliance 
with old hardware and embedded systems to save a few kilos. How old is 
the hardware that you have in mind ? The oldest system running FreeBSD I 
know of is a 1997 Pentium with a 2 GB disk, and even that can easily 
withstand the change I am suggesting. Machines older than that are 
actually DEAD and don't have to be factored in. As for embedded systems, 
the primary target of FreeBSD is servers, workstations and *tops. The 
embedded world hasn't survived riding on FreeBSD, nor the other way 
round. So from the viewpoint of the greatest good of the largest number, 
over-indulging a mindset fixed around minimizing the base only leads to 
degradation, not improvement. Getting to boast of a 900K / won't do any 
good when people are thinking of having decent firepower (even while in 
single-user mode) and its ease of use.


But I guess my words are of no use when the people who matter just won't 
listen. So I give any hopes in this regard.


--
Regards
Manish Jain
invalid.poin...@gmail.com
+91-96500-10329

Laast year I kudn't spell Software Engineer. Now I are won.

___
freebsd-questions@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-questions
To unsubscribe, send any mail to "freebsd-questions-unsubscr...@freebsd.org"

Re: The question of moving vi to /bin

[John L. Templer]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Manish Jain wrote:
>>
>> If you want to make a case for replacing ed(1), you're going to have
>> to come up with some concrete reasons for doing so, not just make a
>> (long and hyperbolic) statement that you don't like it.
>>   
> 
> Any Unix tool has to clearly fall either under the category of
> non-interactive (grep, sed, ex) or interactive (vi, wget, sysinstall).

Oh really?  Many Unix programs have traditionally had both a command
line mode of operation and an interactive mode, and that's still pretty
much still true.  Usually when you run a program you put arguments on
the command line, and the program does what those arguments tell it to
do.  But for many programs, if you run them with no arguments they run
in interactive mode and wait for the user to issue commands telling the
program what to do.

> The case of non-interactive tools is simple : just do what you are told
> on the commandline and exit. For interactive tools, at a minimum, the
> application has to be show what data it is working on and what it does
> with the data when the user presses a key (or a series of them). ed was
> never meant to be non-interactive, and it does not fulfil the basic
> requirements of being interactive. That's one reason. Secondly, how many
> times does an average commandline user even think of using ed when he
> needs to edit a file, even in the extreme case where there are no
> alternatives ?

ed is an interactive program, and it has always been considered as such,
at least since BSD 4.2.  Way back then there were three main editors,
ex, vi, and ed.  If you had a nice video terminal then you used vi.  But
if you were stuck using a hard copy terminal like a Decwriter, then you
used ex.  And ed was the simplified (dumbed down) editor for newbies.

ed is an interactive program because the user "interacts" with it.  You
give it command, it does something, you give it some more commands, it
does more stuff, etc.  Interactive does not mean screen based.

> 
> Till the improvements are in place, we need the alternative of having vi
> under /bin rather than /usr/bin.
> 
> Actually, it surprises me to what extent the core of the FreeBSD
> community is enamoured with this idea of a micro-minimalistic base, in
> which it is practically impossible to do anything except run fsck.
> Matters don't stop there. Seeing the limitations of this approach, the
> community churns up wierd workarounds like /rescue/vi, when all that was
> needed was shift vi from /usr. You talk about the need for compliance
> with old hardware and embedded systems to save a few kilos. How old is
> the hardware that you have in mind ? The oldest system running FreeBSD I
> know of is a 1997 Pentium with a 2 GB disk, and even that can easily
> withstand the change I am suggesting. Machines older than that are
> actually DEAD and don't have to be factored in. As for embedded systems,
> the primary target of FreeBSD is servers, workstations and *tops. The
> embedded world hasn't survived riding on FreeBSD, nor the other way
> round. So from the viewpoint of the greatest good of the largest number,
> over-indulging a mindset fixed around minimizing the base only leads to
> degradation, not improvement. Getting to boast of a 900K / won't do any
> good when people are thinking of having decent firepower (even while in
> single-user mode) and its ease of use.

It's not just keeping the core system small, it's ensuring that if the
disk containing /usr fails to mount, then you still have enough of the
system to fix the problem.  Admittedly this isn't as much of a concern
now, what with rescue disks and CDs with bootable live systems, but it's
still nice to have.

John L. Templer
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.9 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iEYEARECAAYFAkpDDM0ACgkQjkAlo11skePG4wCgjq4plp71Yattn34UP9YIyv4k
VagAoKDcLGVPQBxae6FABGa5hLI9w4gM
=+Ed7
-END PGP SIGNATURE-
___
freebsd-questions@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-questions
To unsubscribe, send any mail to "freebsd-questions-unsubscr...@freebsd.org"

Re: cc1: error: unrecognized command line option "-mfdpic"

[Mel Flynn]

On Wednesday 24 June 2009 18:09:36 Jin Guojun wrote:
> This option "-mfdpic" is shown in manual page for gcc 4.1 or later
>
>-mfdpic
>Select the FDPIC ABI, that uses function descriptors to
> represent pointers to functions.  Without any PIC/PIE-related options, it
> implies -fPIE.  With -fpic or -fpie, it assumes GOT entries and small data
> are within a 12-bit range from the GOT base address; with -fPIC or -fPIE,
> GOT offsets are computed with 32 bits. With a
>bfin-elf target, this option implies -msim.
>

This applies to FRV options, which is a specific processor, so it's not 
available for your architecture.

http://en.wikipedia.org/wiki/FR-V
-- 
Mel
___
freebsd-questions@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-questions
To unsubscribe, send any mail to "freebsd-questions-unsubscr...@freebsd.org"

Re: Isolating high cpu load at function level

[Mel Flynn]

On Wednesday 24 June 2009 07:42:06 Gary Gatten wrote:

> I have a process with several threads - the main "worker" threads
> typically use < 20% CPU - but after upgrading to a new version they're
> now using > 90% cpu.  I'm trying to determine what function these
> threads are performing that's requiring so much more cpu.  Is it bad
> code? I bug in a library I linked against?  What?
>
>
>
> I've tried gdb with list, info threads, info stack, bt full.  I can make
> sense of some of it.  I guess what I'm hoping for is something like
> "top" at the thread level, such that functions that thread perform are
> sorted highest util (time/whatever).

You'd typically turn on profiling, but sometimes less information is good, so 
you might be able to get the info you need by having your workers report the 
information.

libwp[1] has some support for reporting that you could extend with values 
you're interested in.

[1] http://www.garypennington.net/libwp/docs/html/
-- 
Mel
___
freebsd-questions@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-questions
To unsubscribe, send any mail to "freebsd-questions-unsubscr...@freebsd.org"