Re: Is FreeBSD dead ?

[Narvi]

I snipped the following from the cc: 
"Jordan K. Hubbard" <[EMAIL PROTECTED]>, 
Didier Derny <[EMAIL PROTECTED]>, 

hope they don't mind 8-)

On Fri, 10 Mar 2000, Thierry.herbelot wrote:

> "Jordan K. Hubbard" wrote:
> > 
> [SNIP]
> > 
> > If you think it's possible to bend the FreeBSD project to anyone's
> > corporate will then you've never even come close to understanding who
> > we are or what we stand for.  That's a shame since one would think 6
> > years to be more than enough time to gain such an understanding.
> > 
> > - Jordan
> 
> Then, what are the benefits for both parties ?
> 
> For the FreeBSD project :
> - many more supported platforms (Sparc, PowerPC, Arm ?)

definately.

> - better Intel SMP ?

Possibly not only intel smp, according to Wes Peters.

> - new developpers ?

I would say yes.

> - increased credibility via the support network of BSDi ?
> 

add marekting, market penetration, additional name recognition, corporate
contacts and a lot of other things.

> For BSD/OS :
> - better exposure thanks to OpenSource ?
> - Yahoo dollars ?
> - access to a greater community of **volunteer** testers ?
> 

Access to the developer pool ?

>   TfH
> 
> (This is absolutely not a flame bait : I'm very happy to imagine I could
> eventually get for-pay support for FreeBSD machines at work)
> 
> > 
> > To Unsubscribe: send mail to [EMAIL PROTECTED]
> > with "unsubscribe freebsd-hackers" in the body of the message
> 
> -- 
> Thierry Herbelot  /"\   ASCII RIBBON CAMPAIGN
>   \ /  AGAINST HTML MAIL & NEWS
> mailto:[EMAIL PROTECTED]  X PAS DE HTML
> http://perso.cybercable.fr/herbelot   / \DANS LES COURRIELS
> 
> 
> To Unsubscribe: send mail to [EMAIL PROTECTED]
> with "unsubscribe freebsd-hackers" in the body of the message
> 



To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-hackers" in the body of the message

Re: Is FreeBSD dead?

[Narvi]

On Sat, 11 Mar 2000, W Gerald Hicks wrote:

> From: Kevin M Geraci <[EMAIL PROTECTED]>
> > Maybe FreeBSD needs to "spin off" like Slackware is
> > doing and let Walnut Creek merge.
> 
> I don't see why that thought even crossed your mind.
> 
> Anyone could "spinoff" FreeBSD anytime they wanted to.
> So far, there has been no compelling reason to do so
> and it's hard to believe a splinter faction would add
> any value over the course that's been laid.
> 

And those harbouriong such thoughts should dig into the archives and find
Terry's mail on "why not TerryBSD".

> --
> Jerry Hicks
> [EMAIL PROTECTED]
> 
> 
> To Unsubscribe: send mail to [EMAIL PROTECTED]
> with "unsubscribe freebsd-hackers" in the body of the message
> 



To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-hackers" in the body of the message

Re: Is FreeBSD dead ?

[Narvi]

On Sat, 11 Mar 2000, Jordan K. Hubbard wrote:

> > I am sure of the FreeBSD Projects intentions but like the previous post
> > things can 'turn ugly fast with the greatest intentions' The fact a
> > for-profit company controlling it's movements is cause for concern.
> 
> How many different ways can we say this?  THE COMPANY DOES NOT CONTROL
> THE FREEBSD PROJECT'S MOVEMENTS.  It can't!


Heh.

Are you sure arguing with them isn't futile? For some reason, they have
taken upon to bear a banner (and a big one at that) with the lettering
"*WE* will stand up for poor little FreeBSD, if nobody else does". Not
even thinking if FreeBSD needed standing up for, was poor, or for that
matter little.

Think of them as of people who watch "Tom and Jerry" and then start
organising pickets in front of governement buildings bearing banners
"Don't let mice exterminate cats!"

> 
> - Jordan
> 




To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-hackers" in the body of the message

Re: Is FreeBSD dead ?

[Narvi]

On Sat, 11 Mar 2000, Marco van de Voort wrote:

> > > Then, what are the benefits for both parties ?
> > > 
> > > For the FreeBSD project :
> > > - many more supported platforms (Sparc, PowerPC, Arm ?)
> 
> Merced? .
>  
> > definately.
> 
> I'm not sure if that is a good thing if it is pursued by the core team,
> at least not for impopular or older targets. 
> 

Which targets would these be? ARM?

Note that for the code - when it is available for integration - needs to
be actually integrated by somebody, not to mention the userland,
maintenance, etc. 

> 
> Marco van de Voort ([EMAIL PROTECTED])
> 
> 



To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-hackers" in the body of the message

Re: Is FreeBSD dead? Well, not in theory...

[Narvi]

On Sat, 11 Mar 2000, Dennis wrote:

> [EMAIL PROTECTED] writes...
> 
> >The very fact that source is available means that you can pay any scruffy
> >unshaven hacker to fix it for you, instead of suffering at the hands and
> >whims of, say, a FreeBSD "vendor" as you are doing. I would figure that at
> >least you (of all people) realize that someone else can come in and get it
> >done, and that you could optionally pay someone to do this.
> 

[snip - paying a dropout $100/h to fix drivers]

> Another point is that Open Source is virtually synonomous with "Totally
> undocumented". The linux community, years into it, are still totally
> dependent on Alan Cox to fix drivers properly (mostly because the OS is
> completely undocumented and changes are made on a whim regularly). D.
> Becker continues to be the only one that can properly fix the ethernet
> drivers because they are such a mess and poorly documented. 

Why haven't you considered hiring somebody to document the parts you are
intersted in? Would solve at least half the problem...

[snip]

> 
> dennis
> Emerging Technologies, Inc.
> 
> -
> 
> 
> http://www.etinc.com
> ISA and PCI T1/T3/V35/HSSI Cards for FreeBSD and LINUX
> Multiport T1 and HSSI/T3 UNIX-based Routers
> Bandwidth Management Standalone Systems
> Bandwidth Management software for LINUX and FreeBSD
> 



To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-hackers" in the body of the message

Re: Dennis' inability to fix the eepro driver

[Narvi]

On Sat, 11 Mar 2000, Mike Smith wrote:

[snip]

> > Why haven't you considered hiring somebody to document the parts you are
> > intersted in? Would solve at least half the problem...
> 
> To be fair to Dennis, it's not the cost of paying the dropout to fix this 
> driver that's at issue here.  
> 
> Documentation for the eepro parts is not easy to get; I only have one 
> outdated hardcopy, and I get all sorts of weird stuff thrown at me.
> 

Nah. It wasn't in response to anything that dealt with the driver. Nothing
to do with eepro at all.

It was in response to the rant about how everything was undocumented
spaghetty code so few people could make any sense of that people were
virtually dependant on those few. 

[snip]

> 
> -- 
> \\ Give a man a fish, and you feed him for a day. \\  Mike Smith
> \\ Tell him he should learn how to fish himself,  \\  [EMAIL PROTECTED]
> \\ and he'll hate you for a lifetime. \\  [EMAIL PROTECTED]
> 
> 



To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-hackers" in the body of the message

Re: Dennis' inability to fix the eepro driver

[Narvi]

Uhhh... 

And before anybody gets all kinds of funny ideas, no, i am not trying to
blackmail Dennis.

On Sun, 12 Mar 2000, Narvi wrote:

> 
> On Sat, 11 Mar 2000, Mike Smith wrote:
> 
> [snip]
> 
> > > Why haven't you considered hiring somebody to document the parts you are
> > > intersted in? Would solve at least half the problem...
> > 
> > To be fair to Dennis, it's not the cost of paying the dropout to fix this 
> > driver that's at issue here.  
> > 
> > Documentation for the eepro parts is not easy to get; I only have one 
> > outdated hardcopy, and I get all sorts of weird stuff thrown at me.
> > 
> 
> Nah. It wasn't in response to anything that dealt with the driver. Nothing
> to do with eepro at all.
> 
> It was in response to the rant about how everything was undocumented
> spaghetty code so few people could make any sense of that people were
> virtually dependant on those few. 
> 
> [snip]
> 
> > 
> > -- 
> > \\ Give a man a fish, and you feed him for a day. \\  Mike Smith
> > \\ Tell him he should learn how to fish himself,  \\  [EMAIL PROTECTED]
> > \\ and he'll hate you for a lifetime. \\  [EMAIL PROTECTED]
> > 
> > 
> 
> 



To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-hackers" in the body of the message

Re: Unicode on FreeBSD

[Narvi]

On Mon, 20 Mar 2000, MikeM wrote:

> Has anyone thought of Unicode support on FreeBSD? 
> 

Depends on what you mean by 'Unicode support'.

If you use a suitable encoding (UTF-8?) everything should work, only it
might look strange, as userland doesn't support it. It is largely a
'application space' problem as I understand it - you need to modify each
and every utility to know that file names should be treated as strings of
wide characters. Toolkits providing a 'select file' std dialog need to be
dealt with. 

> I think that it is inevitable that eventually FreeBSD
> will *need* to support unicode if it wants to continue
> as a viable operating system in the future. This means
> that it  probably will need to be modified from the
> ground up. I am not well versed in the specifics of
> what's needed, but if someone could explain it to me
> I'd be gratefull.
>

See above for a subset.
 
> Is it possible, or is it totally out of the question?
> 
> What would it require?
> 
> Is there any way of implementing partial support,
> working in stages, untill it is fully supported?
> 
> 
> Thanks,
> Mike.
> 
> __
> Do You Yahoo!?
> Talk to your friends online with Yahoo! Messenger.
> http://im.yahoo.com
> 
> 
> To Unsubscribe: send mail to [EMAIL PROTECTED]
> with "unsubscribe freebsd-hackers" in the body of the message
> 



To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-hackers" in the body of the message

Re: Double buffered cp(1)

[Narvi]

On Sat, 22 Apr 2000, Matthew Dillon wrote:

[snip]

> disk itself is probably the bottleneck.  Disk writes tend to be
> somewhat slower then disk reads and the seeking alone (between source
> file and destination file), even when using a large block size, 
> will reduce performance drastically verses simply reading or writing
> a single file linearly.  Double buffering may help a disk-to-disk
> file copy, but I doubt it will help a disk-to-same-disk file copy.
> 

Wouldn't coping the file to another disk and then back to the original one
than just a simple copy in some cases be faster then?

After all, you are saving a lot of head seeks.

>   -Matt
>   Matthew Dillon 
>   <[EMAIL PROTECTED]>
> 



To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-hackers" in the body of the message

Re: [OT] Finding people with GSM phones (was Re: GPS heads up )

[Narvi]

On Mon, 8 May 2000, Kris Kirby wrote:

> > BTW, you do realize that in many cases "off" for your cell phone
> > doesn't really mean off, right? :)
> 
> I have strong objections to small transcievers (what cell phones
> actually are) that operate close to my body and don't let me know when
> they are transmitting. When you're talking on it, you know it's
> transmitting, but I'm talking about just about every other time when
> you've got it on your belt or clipped to your side. I know they aren't
> high power, but we don't know long term effects (actually, we do; we just
> don't know the thresholds for triggering cancer, etc.).
> 

Well, maybe we do. Just read the other day that the british are planning
to make warning signs compulsory on mobile phones... 

> I'm not thrilled at the aspect of a radio close to my head either. You can
> feel a radio after it's been transmitting for a while and think:
> "Something close to the amount of heat generated by this radio has been
> sent out over the ether and I was standing right in front of it." Yes, to
> cook your noodle you'd need a couple hundred watts but still, it's energy.
> 
> -
> Kris Kirby, KE4AHR  | TGIFreeBSD... 'Nuff said.
> <[EMAIL PROTECTED]>|
> ---
> "Fate, it seems, is not without a sense of irony."
> 



To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-hackers" in the body of the message

Re: System management with large groups

[Narvi]

On Fri, 19 May 2000, Jonathan Laventhol wrote:

> Dear FreeBSD Hackers --
> 
> I've got a technically-straightfordward but nonetheless
> business-critical problem with the groups structures in FreeBSD
> which perhaps you kind souls can help me with.
> 
> *** BACKGROUND ***
> 

[snip]

> Question 4: What do people think might break?  Would it be better,
> worse, or impossible to do this with NIS?
> 

My gut feeling says worse.

Have you looked into the ACL patches for FreeBSD?

> Question 5: Has anybody done anything like a vigr (like vipw)
> for /etc/group?  Our (locally-written) user database would be
> changing the groups all the time.
> 
> 
> Many thanks, my FreeBSD heroes, if anybody has anything to offer
> on this.
> 
> Best regards,
> Jonathan.
> -- 
> Jonathan Laventhol
> Technology Director
> 
> Imagination  25 Store Street South Crescent London WC1E 7BL England |
>  Tel +44 171 323 3300Fax +44 171 323 5801   |
>  ___|
> 



To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-hackers" in the body of the message

Re: Comments on Athlon [motherboards] sought..

[Narvi]

On Fri, 9 Jun 2000, Michael Bacarella wrote:

> 
> On Fri, 9 Jun 2000, Wilko Bulte wrote:
> 
> > On Thu, Jun 08, 2000 at 08:54:28PM +0200, Wilko Bulte wrote:
> > > I'm considering buying an Athlon based machine. Before shelling out the
> > > $ (well, fl ) I'd like to know what experiences have with Athlon and
> > > FreeBSD. And obviously which mom boards to prefer or keep away from.
> > 
> > Anybody using the Abit KA7? If yes, do you like it?
> > 
> > I appreciate the KA7 PCI/ISA combo slot instead of the useless AMR thingy Asys
> > has on their praised K7V (mind you, I like Asus as such, excellent
> > experiences with them over the years).
> 
> Ugh. I was suprised that I couldn't find an Asus K7V without a stupid AMR
> slot, especially since I only heard good things about the board
> itself. I made an honest attempt but just ended up ordering it
> anyway. I've tried to figure out what that slot does but I've only come
> across market-speak.
> 
> What does it do?
> 

If AMR == Asus Media Slot, then it's a slot that is simultaneously PCI and
ISA, so you can have a PCi video card and ISA soundcard on one card.

IIRC, that is.

> Michael Bacarella
> New York Connect Net
> 
> 



To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-hackers" in the body of the message

Re: Comments on Athlon [motherboards] sought..

[Narvi]

On Fri, 9 Jun 2000, Michael Bacarella wrote:

> 
> > > > I appreciate the KA7 PCI/ISA combo slot instead of the useless AMR thingy Asys
> > > > has on their praised K7V (mind you, I like Asus as such, excellent
> > > > experiences with them over the years).
> > > 
> > > Ugh. I was suprised that I couldn't find an Asus K7V without a stupid AMR
> > > slot, especially since I only heard good things about the board
> > > itself. I made an honest attempt but just ended up ordering it
> > > anyway. I've tried to figure out what that slot does but I've only come
> > > across market-speak.
> > > 
> > > What does it do?
> > > 
> > 
> > If AMR == Asus Media Slot, then it's a slot that is simultaneously PCI and
> > ISA, so you can have a PCi video card and ISA soundcard on one card.
> 
> They're about a third of the size of a PCI slot, so I don't see how that
> would be conveniant. :)
> 

But isn't it at the end of a PCI slot? If no, then they actually did come
with a next stupid thing that has the same abreviation. 

A switched away from asus some time before athlon came out.

> Michael Bacarella
> New York Connect Net
> 



To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-hackers" in the body of the message

Re: ACPI project progress report

[Narvi]

On Tue, 20 Jun 2000, Josef Karthauser wrote:

> On Mon, Jun 19, 2000 at 05:40:30PM -0700, Mike Smith wrote:
> > 
> > The real issue here is persistent system state across the S4 suspend; ie.
> > leaving applications open, etc.  IMO this isn't really something worth a 
> > lot of effort to us, and it has a lot of additional complications for a 
> > "server-class" operating system in that you have to worry about network 
> > connections from other systems, not just _to_ other systems.
> > 
> 
> That said TCP/IP is very resilient :).  I tried suspending to disk
> my laptop, unplugging the batteries and ether card, taking it to another
> part of the building and the firing it up.
> 
> Pccardd saw the ethernet card, Dhclient saw the dhcp server and got
> my ip address back, and my pre-existing remote terminal sessions
> continued functioning :) Excellent.
> 
> IMO if the machine is a server and you want to suspend it, who cares
> about the clients at the other end?  If you did you wouldn't suspend
> it in the first place :)
> 

You obviously haven't considered the ability to be able to near hot-swap
motherboard and cpu - or even RAM - in this way. 

> Joe
> 
> 

[EMAIL PROTECTED]



To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-hackers" in the body of the message

Re: Default (x86) floating point precision

[Narvi]

On Tue, 27 Jun 2000, Steve Kargl wrote:

> Daniel Eischen wrote:
> > 
> > Oddly, this causes problems with GNAT (Ada is a high level language)
> > because it wants/expects 64-bit extended precision.  It seems as if
> > GNAT for linux-i386 also uses 64-bit extended precision.  The only
> > other GNAT i386 platform that doesn't use 64-bit precision is NT.
> > 
> > So is the above comment still valid?
> > 
> 
> Does GNAT use the math library in /usr/lib?  I've been testing
> our math library against UCBTEST, and there appear to be some
> pecularities.  I need to dig deeper to understand all the info
> produced by UCBTEST.  The point of this note is that turning on
> 64-bit extended precision in GNAT might be compromised by libm.a.
> 

Well, some things can easily depend on there being no double rounding to
get the correct results. 

> -- 
> Steve
> 



To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-hackers" in the body of the message

Re: bridging

[Narvi]

On Thu, 6 Jul 2000, Nick Rogness wrote:

> On Thu, 6 Jul 2000, Sean Lutner wrote:
> 
> > 
> > Bridges create a broadcast zone. broadcast packets will cross the bridge
> > unobstructed.
> 
>   OK.  So do bridged interfaces fall within the same collision
>   domain?... or are they just members of the same broadcast domain?
> 

They can't be in the same collison domain - you'll realise it if you
think about it for a second.

> 
> Nick Rogness
> - Speak softly and carry a Gigabit switch.
> 



To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-hackers" in the body of the message

Re: Code Pal VMS

[Narvi]

No. A real low would be 'what does Visual C++ do or Where do I get cracks 
for Visual Basic'.

And damn it, dare anybody not head over to -chat with this thread! 

On Fri, 7 Jul 2000, Andrew Reiter wrote:

> 
> I believe we've all hit a real low aftrer this.
> 
> On Fri, 7 Jul 2000, lgrajales wrote:
> 
> |> 
> |> What is a Code Pal for VMS?
> |> thnxs.
> |> 

[snip - sigs]



To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-hackers" in the body of the message

Re: Some proposals to FreeBSD kernel

[Narvi]

[i think this might just as well belong in -questions]

On 10 xxx -1 [EMAIL PROTECTED] wrote:

> Hello 
> 
> I'm 18-year-old newbie UNIX programmer that currently use 
> FreeBSD and is really thankfull of it.I run it on DUAL PII/333.
> 
> Some days ago my friend tell me that with simple user rights
> and whit only 1 line of code he could crash my machine. I laught
> but he did it :(.
> 
> What he wrote was ' int main(void) {while(1) fork(); }'  compiled it
> and run it. Within a second /kernel said "proc: table is full" and 
> died. I tried this on some other BSD unixes and the result was 
> same. (BTW Minix 2.0 seem unaffected and probably other SVR4
> variants, because you can limit the number of  system processes
> and system still have resources to work fine(although slow))
> 

And you can do the same with BSD. See limits(1), csh(1), sh(1),
login.conf(5)

> With sysctl() I found that my system can work with up to 532 procs
> simulanteously, but didnt found where this value is set in the src/
> or probably where it is computed.
> 

See LINT - it is computed from maxusers.

> So I sit down and wrote a static library that introduse a new fork()
> (nfork()) and _exit() (nexit()) whose only purpose is to lower the 
> effect ot fast fork()s by sleeping accordingly to the number of times
> fork() was called.I tend to make some more things with that piece 
> of code (in the attachment) and probably to add it to the kenel src
> but for now it is easier to use it as a library.
> 

I'm not really sure how usefull this is in general.

> Any suggestions about tarball included are welcome.
> Looking forward to hearing from you.
>   Thanks for reading my letterIx
> 



To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-hackers" in the body of the message

Re: Pointer to people `in charge' of FreeBSD make ?

[Narvi]

Ouch!

Don't mangle VPATH use. 

If you want to get the other behaviour, leave the thing in place and
provide a switch to get the other one. 

And no, I am not in charge of FreeBSD make. 



To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-hackers" in the body of the message

Re: 4.1 ISO CRC

[Narvi]

On Wed, 2 Aug 2000, Dimitar Peikov wrote:

> Hi,
> 
> Could someone send me CRC code for the 4.1 ISO image or to be available on ftp
> server for downloading?
> 

What will CRC give you that MD5 checksums (available) doesn't give you?

> -- 
> Dimitar Peikov
> 
> 
> To Unsubscribe: send mail to [EMAIL PROTECTED]
> with "unsubscribe freebsd-hackers" in the body of the message
> 



To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-hackers" in the body of the message

Re: Discussion on the future of floppies in 5.x and 6.x

[Narvi]

On Thu, 8 Jan 2004, Matthew D. Fuller wrote:

> On Wed, Jan 07, 2004 at 11:50:59PM -0800 I heard the voice of
> Avleen Vig, and lo! it spake thus:
> >
> > While it is indeed true that most machines since 1997 will support this
> > CD format, please take in to account:
>
> And, further, some of us don't have (and don't want) CD burners, and even
> if we had 'em, don't want to burn (no pun intended ;) a CD blank just to
> install an OS, when we can just (re-)use 2 floppies and do it across the
> LAN from a local FTP mirror, which is as fast as a CD drive anyway.

Which would obviously mean that there would be lots of volunteers for the
position of floppy maintainer?

>
> --
> Matthew Fuller (MF4839)   |  [EMAIL PROTECTED]
> Systems/Network Administrator |  http://www.over-yonder.net/~fullermd/
>
> "The only reason I'm burning my candle at both ends, is because I
>   haven't figured out how to light the middle yet"
>

___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to "[EMAIL PROTECTED]"

Re: Discussion on the future of floppies in 5.x and 6.x

[Narvi]

On Thu, 8 Jan 2004, Steven Hartland wrote:

> Need necessitates effort?
>

Precicely. Or even more precicely - the RE team provided an alternative
path to eliminating floppy support which they could cope with. It follows
that people who want floppy support should work towards that because the
other option:

 you tell RE team that they had better shut up and make it work

is not workable becuase they have no compulsion to listen to your and
could just walk away any minute they bloody well want anyways. It thus
follows that some persons out of the "we want floppy support to stay
around" had better start volunteering to be floppy maintainers.

> - Original Message -
> From: "Avleen Vig" <[EMAIL PROTECTED]>
>
> > How you made the jump from "I don't want to buy a CD burner to install
> > FreeBSD" to "I will be a floppy maintainer" I'm not sure. :-)
>
> 
> This e.mail is private and confidential between Multiplay (UK) Ltd. and the person 
> or entity to whom it is addressed. In the event of misdirection, the recipient is 
> prohibited from using, copying, printing or otherwise disseminating it or any 
> information contained in it.
>
> In the event of misdirection, illegible or incomplete transmission please telephone 
> (023) 8024 3137
> or return the E.mail to [EMAIL PROTECTED]
>
>

___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to "[EMAIL PROTECTED]"

Re[2]: Where is FreeBSD going?

[Narvi]

On Fri, 9 Jan 2004, Lev Serebryakov wrote:

> Hello, Doug!
> Thursday, January 8, 2004, 8:29:34 PM, you wrote:
>
> DR> 3. Converting the repository. This is a tricky one - I tried the
> DR>current version of the migration scripts and they barfed and died
> DR>pretty quickly. Still, I'm pretty sure that the svn developers
> DR>are planning to fix most of those problems. From mailing-list
> DR>archives, it appears that they are using our cvs tree as test
> DR>material for the migration scripts.
>   Did you try my (pure-perl) vatinat ``RefineCVS''?
>
>   http://lev.serebryakov.spb.ru/refinecvs/refinecvs-0.76.783.tar.gz
>
>   But, please, read documentation carefully before reporting bugs --
>   many errors could be avoided with command-line options, sctipy is
>   paranoid by default.
>
>   Some parts of FreeBSD repository could not be converted, because
>   contains revisions like 1.2.1 and other `I don't know what I should
>   think about this' errors. If you have some good ideas -- let me know
>   :)
>

Huh? Whats wrong with revision 1.2.1 ? This is perfectly normal cvs
revision number, even if you have to use a command line option to get it.
But it should not require any kind of special treatment.

> --
>Lev Serebryakov
>

___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to "[EMAIL PROTECTED]"

Re[3]: Where is FreeBSD going?

[Narvi]

On Fri, 9 Jan 2004, Lev Serebryakov wrote:

> Hello, Narvi!
> Friday, January 9, 2004, 4:28:57 PM, you wrote:
>
> >> DR> 3. Converting the repository. This is a tricky one - I tried the
> >> DR>current version of the migration scripts and they barfed and died
> >> DR>pretty quickly. Still, I'm pretty sure that the svn developers
> >> DR>are planning to fix most of those problems. From mailing-list
> >> DR>archives, it appears that they are using our cvs tree as test
> >> DR>material for the migration scripts.
> >>   Did you try my (pure-perl) vatinat ``RefineCVS''?
> >>   http://lev.serebryakov.spb.ru/refinecvs/refinecvs-0.76.783.tar.gz
> >>   But, please, read documentation carefully before reporting bugs --
> >>   many errors could be avoided with command-line options, sctipy is
> >>   paranoid by default.
> >>   Some parts of FreeBSD repository could not be converted, because
> >>   contains revisions like 1.2.1 and other `I don't know what I should
> >>   think about this' errors. If you have some good ideas -- let me know
> >>   :)
> N> Huh? Whats wrong with revision 1.2.1 ? This is perfectly normal cvs
> N> revision number, even if you have to use a command line option to get it.
> N> But it should not require any kind of special treatment.
>
>   It is NOT perfectly normal cvs revision number. WHAT TYPE of
>   revision number is it?
>

See, the problem is that you are thinking in overly constrained terms of
revision numbers that cvs creates by default, and even so don't think
about RCS at all. CVS is not a real CM system its an half-assed one built
on top of RCS.

1.2.1 could be a branch (this would be the usual case) or it could be a
file revision created by ci(1). in fact, even old (ok, the old here is
relative) versions of cvs let you create it as file revision.

>   Normal numbers are (first level of branching is showed only):
>
>   x.y  -- TRUNK
>   x.y.0.(2n)   -- MAGIC for branch (in SYMBOLS only)

(2n) here is completely - utterly, totaly, etc - bogus.

>   x.y.(2n).z   -- Revision on branch
>   x.1.(2n+1)   -- Vendor branches (in SYMBOLS only)
>   x.1.(2n+1).z -- Vendor imports
>

see above for 2n.

>   Ok, ok, it should be some broken vendor branch. But what do you say
>   about `1.1.2'? Or even simple `1' (look into sysintall's Attic).
>

simple 1 is simple - somebody was using ci, and forgot about dots. 1.1.2
is similar to 1.2.1.

>   BTW, repo from FreeBSD 4.9 is parsed almost without such errors
>   (sysinstall, pppd + kernel part of ppp, zoneinfo).
>   Some problems are with double symbols (one symbolic name marks two
>   revisions: MAGIC one and simple one), and with symbols, which marks
>   unexistent revisions (many, many such symbols over all repository).
>
>   But my computer doesn't have enough memory to finish conversion process.
>

It may be worthwhile to collect such and have somebody do a fixup.

> --
>Lev Serebryakov
>


___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to "[EMAIL PROTECTED]"

Re: Where is FreeBSD going?

[Narvi]

On Fri, 9 Jan 2004, Gary W. Swearingen wrote:

> "M. Warner Losh" <[EMAIL PROTECTED]> writes:
>
> > Whatever.  I've consulted lawyers on this who assure me that it is
> > legal.  You've admitted to not knowing US Copyright law and are aguing
> > emotion, which is why I didn't reply to the rest of your message.
>
> You obviously don't want to discuss this, and it's easy to guess the
> real reasons.  Your main problem here, and apparently that of your
> lawyers, is that you don't understand what the issues are to which
> copyright law is to be applied.  The legality of collective copyrights
> was not my issue.  Your other problem is putting words in people's
> mouth; I would never admit to know not knowing US copyright law
> because I know it quite well enough to argue FreeBSD's IP issues with
> anybody.  If I don't write with the same seeming authority as you,
> that's more your problem than mine.
>
> I expected my comments to be ignored or brushed off, but I didn't
> expect to be brushed off in your rude and insulting manner.  Maybe
> when I've recovered, and if I haven't made my move to NetBSD yet, I'll
> write up a more complete explanation of FreeBSD's IP problems instead
> of trying to deal with the likes of you in a conversation.
>

Please do. But could you also include reasoning for use of US specific
view (if thats what you are going to use) as there is essentially no
reason why US copyright regulations and practices should preferentialy
apply to it. Especially as the licence has no such stipulations about
applicable law in it.

>
> We can all be glad that it hasn't mattered and might never matter that
> the FreeBSD IP situation is so shabby, I suppose because it sends the
> message that it's all essentially a Gentlemen's Agreement, with only a
> few violators who are more-or-less tolerated.
>

It is not clear that there is a way - as things stand - to get to a point
where this wouldnot be the case. In appears very doubtful there is such a
way unless you can get to get everybody whose code has been ever commited
to send in a real written on paper copyright transfer, the chances of
which are essentialy 0, even should you be able to trace down all
involved.

___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to "[EMAIL PROTECTED]"

Re: Where is FreeBSD going?

[Narvi]

On Fri, 9 Jan 2004, Matt Freitag wrote:

> Narvi wrote:
>
> >>"M. Warner Losh" <[EMAIL PROTECTED]> writes:
> >>
> >>
> >>
> >>>Whatever.  I've consulted lawyers on this who assure me that it is
> >>>legal.  You've admitted to not knowing US Copyright law and are aguing
> >>>emotion, which is why I didn't reply to the rest of your message.
> >>>
> >>>
> >>
> >It is not clear that there is a way - as things stand - to get to a point
> >where this wouldnot be the case. In appears very doubtful there is such a
> >way unless you can get to get everybody whose code has been ever commited
> >to send in a real written on paper copyright transfer, the chances of
> >which are essentialy 0, even should you be able to trace down all
> >involved.
> >
> >
> So there are cases of code by authors being committed into the codebase
> without their knowledge/consent? This would be a problem. If code is
> being committed against license, I definitely see an issue here.

Consider code merges from Net/OpenBSD. There is no explicit permission
involved nor needed.

> However, If you /GIVE/ your IP to the FreeBSD community, it's no longer
> yours. Either way, apparently you'll never make everyone happy, even as

Well... See, this is the place where people go wrong. Nobody is *GIVING*
their IP or code to anybody (and this includes the original sources from
Berkeley), they are simply licencing it. And unsuprisingly enough, there
is a difference - a big one - between two two. Whetever one needs to be
concerned about that is yet againan altogether different matter.

The same would by the way apply even if all of FreeBSD was GPL licenced.

> hundreds (or thousands) of people give away their time to produce
> something at no cost to you, there's still always going to be someone
> complaining. (We refer to this as a sense of entitlement - Many people
> have this, and it's an unfortunate growing fad all over.) If you don't
> want your code in FreeBSD, don't submit it. Anyone going to pursue some
> indictments against Coyote Point Systems? Since their load-balancing
> hardware runs FreeBSD, and I don't believe (I'm unsure, but from the
> info I've gotten, it doesn't sound like it.) that they give you any of
> the source with your purchase of their hardware, Hmm
>

There is no scenario at all under which they would have to give you their
code. None at all.

> -mpf
>
> +  -   -
>  |  Resistance is futile, assimilation into the FreeBSD community is
> inevitable.
>
>

___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to "[EMAIL PROTECTED]"

Re: Copyrights (was: Where is FreeBSD going?)

[Narvi]

On Fri, 9 Jan 2004, Rahul Siddharthan wrote:

> Narvi wrote:
> > > We can all be glad that it hasn't mattered and might never matter that
> > > the FreeBSD IP situation is so shabby, I suppose because it sends the
> > > message that it's all essentially a Gentlemen's Agreement, with only a
> > > few violators who are more-or-less tolerated.
> > >
> >
> > It is not clear that there is a way - as things stand - to get to a point
> > where this wouldnot be the case. In appears very doubtful there is such a
> > way unless you can get to get everybody whose code has been ever commited
> > to send in a real written on paper copyright transfer, the chances of
> > which are essentialy 0, even should you be able to trace down all involved.
>
> Copyright transfer is certainly not required if the code was released
> by the original author under a suitable free software licence
> (BSD/GPL/LGPL or others that permit FreeBSD to redistribute them).
> All that is required is that you retain the author's copyright
> statement in the source files.

Required for what? For use of the code as we are all doing, sure, no
argument.

The paragraph above was about his perception of the code being in a shoddy
situation due to apparent attribution of copyright to a body in a way that
does not actually cause the transfer of copyright to said body (whetever
it exists as a legal / physical entity anywhere or not). I just pointed
out that the reversal of such situation is essentialy impossible even if
such was desirable (which I doubt it is) or tried.

And no, IMHO there is no real reason to even try.

>
> You can of course not do this with copyrighted material in general.
> It is the free software licence that allows you to do it if you abide
> by its conditions.
>
> If the claim is that there is code in the tree whose licensing status
> is doubtful, you should point out that code.
>

I have made no such claim - and I heavily doubt there is such code. I did
not make any claims at all about code, only about the copyright ownership
and that it essentialy remains in the hands of the developers. Which is
ok. And no, I don't really think there is much point in having long
discussions over this...

[snip - "umm, yes"]

>
> Rahul
>

___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to "[EMAIL PROTECTED]"

Re: Future of RAIDFrame and Vinum (was: Future of RAIDFrame)

[Narvi]

On Sun, 11 Jan 2004, Andreas Braukmann wrote:

> On 01/11/04 12:13:36 +0100 Poul-Henning Kamp wrote:
>
> > In message <[EMAIL PROTECTED]>,
> > Alexander Leidinger writes:
> >
> >> fine, but if I got it right, do you (Greg) agree to remove it from
> >> -current?
> >
> > My proposal is to do just that with both vinum and raidframe until
> > one or possibly both are up to full strength again.
>
> and I'm pretty sure, that you'll provide means to migrate
> the vinum volumes on -current systems transparently and
> in-place to regular partitions?
>
> vinum (IMHO) is a quite valuable piece of software. I'm
> using it quite intensively; *especially* on -current-boxes
> I'm in need of most flexible storage management.
>

oh yes - and please fix disklabel to support an arbirtary number of file
system per a "disk" or "slice" in the process, because otherwise it will
not be converting many setups.

>
> -Andreas
>

___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to "[EMAIL PROTECTED]"

Re: Standard sbc and pcm support in GENERIC kernel?

[Narvi]

On Thu, 4 Mar 2004, Brandon D. Valentine wrote:

> On Wed, Mar 03, 2004 at 05:03:40PM +0100, Jorn Argelo wrote:
> >
> > I've been on the question list for some time, and I have noticed that
> > many people do not know how to get sound support up and running in
> > FreeBSD 5.X. I know that re-compiling the kernel is easy enough, but
> > there are still people not willing to do so, as I have noticed on the
> > list. Therefor I thought it might be an idea to put sound support in the
> > GENERIC kernel configuration, so that newbies will no longer find
> > themselves stuck with that.
>
> If they'd read pcm(4) they'd know how to get sound support up and
> running without recompiling their kernel.  Is there something wrong with
> requiring that a new user bother to read the documentation?
>

No, but it is also a reasonable expectation for the OS to autodetect and
load support for common hardware - which includes most of the popular
soundcards.

> [ I do not speak for the FreeBSD project. ]
>
> Brandon D. Valentine
> --
> [EMAIL PROTECTED]   http://www.geekpunk.net
> Pseudo-Random Googlism:  march is great success
> ___
> [EMAIL PROTECTED] mailing list
> http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
> To unsubscribe, send any mail to "[EMAIL PROTECTED]"
>
___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to "[EMAIL PROTECTED]"

Re: Standard sbc and pcm support in GENERIC kernel?

[Narvi]

On Fri, 5 Mar 2004, Daniel Lang wrote:

> Hi,
>
> David Raistrick wrote on Fri, Mar 05, 2004 at 08:27:56AM -0800:
> [..]
> > kldload snd_driver
> >
> > is of course the correct way to do it.  FWIW, kldunload snd_driver does
> > /not/ unload all of the modules that kldload snd_driver loads.
> [..]
>
> snd_driver is a module that contains _all_ drivers,
> thus you have the best chance to get sound working.
> Unloading it, will of course unload the whole module with
> all drivers. There is no way to leave one of the drivers
> in the kernel.
>
> I agree, that there is not much documentation which driver
> module supports which sound device (or I was not successful
> to dig that up).
>
> However, you can determine the correct module, by subsequently
> loading and unloading each individual driver module. The one
> which attached to your sound device and actually works
> (check /dev/sndstat as well) is obviously the correct one.
>

And you really want this to be something somebody new to FreeBSD and
possibly unix has to go through to get sound working (afetr finding the
documentation, of course)???

> Not a very efficient way, but it works. :)
>
> Best regards,
>  Daniel
> --
> IRCnet: Mr-Spock
>  - kommst du siehst du, gehst du hast du, weisst du, krass! -
> Daniel Lang * [EMAIL PROTECTED] * +49 89 289 18532 * http://www.leo.org/~dl/
>
___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to "[EMAIL PROTECTED]"

Re: verbose device probing ?

[Narvi]

On Tue, 21 Jan 2003, Bruce A. Mah wrote:

> If memory serves me right, Arun Sharma wrote:
> > On Mon, Jan 20, 2003 at 08:33:09AM -0800, Bruce A. Mah wrote:
> > >
> > > PS.  I personally ignore the severity and priority fields of PRs.  The
> > > importance of many PRs I've dealt with is very much inflated.
> > >
> >
> > Perhaps you should change the severity field to a lower level then ? Or
> > is there a different problem (such as lack of good tools) that prevent you
> > from doing that ?
>
> The severity and priority fields can be changed manually but that
> doesn't solve the problem that relying on the user-specified severity
> and priority fields for anything meaningful just doesn't work.
>
> The only point that I was trying to make with my comment was that you
> shouldn't place much weight on the contents of the severity and priority
> fields in the database.
>

This sounds like throwing the baby out with the water - it would be better
to find a relatively clueful volutnteer(s) who would make sure the fields
are set to sensible values. This is sometimes reffered to asbug triaging.

> Bruce.
>
>
>



To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-hackers" in the body of the message

Re: verbose device probing ?

[Narvi]

On Tue, 21 Jan 2003, Terry Lambert wrote:

>
> The priority field is rather ridiculous, in a volunteer project,
> at least one that does not have some sort of scheduling enforcement
> (i.e. one could envision a system where all changes must have PR's
> associated with them, and priority was assigned by consensus
> through the email moral equivalent of a "manager's meeting", and
> people were not permitted to check in priority N items, if there
> were any PR's of priority > N+1 outstanding, etc.).
>

This is not really true - you can always use the field as a hint to
wannabee hackers and patch submitters as to what they should be spending
their time on. And while nothing can make sure they actually spend time on
those and not other things (whetever related to FreeBSD at all or not) ,
its better than a mass of largely uncategorized bugs.

> -- Terry


To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-hackers" in the body of the message

Re: verbose device probing ?

[Narvi]

On Tue, 21 Jan 2003, Terry Lambert wrote:

> Narvi wrote:
> > On Tue, 21 Jan 2003, Terry Lambert wrote:
> > > The priority field is rather ridiculous, in a volunteer project,
> > > at least one that does not have some sort of scheduling enforcement
> > > (i.e. one could envision a system where all changes must have PR's
> > > associated with them, and priority was assigned by consensus
> > > through the email moral equivalent of a "manager's meeting", and
> > > people were not permitted to check in priority N items, if there
> > > were any PR's of priority > N+1 outstanding, etc.).
> >
> > This is not really true - you can always use the field as a hint to
> > wannabee hackers and patch submitters as to what they should be spending
> > their time on. And while nothing can make sure they actually spend time on
> > those and not other things (whetever related to FreeBSD at all or not) ,
> > its better than a mass of largely uncategorized bugs.
>
> You miss the point, I think.
>
> Nothing you have said has contradicted my statement that priority
> is a group/management decision, not a bug-filer's decision.
>
> Severity means "how bad the bug is biting me personally".
>

As submited - yes. One can easily argue though that it should change to
reflect something larger once in the database.

> Priority means "how much does the group value having this
> fixed".
>
> If the problem is that the wi driver panics the kernel when
> Joe-Bob inserts a prototype card that noly he has, the severity
> is 5 (on a scale of 0-5), but the priority on fixing it for the
> project is probably 0.
>

If only Joe-Bob or some other very limited set of people have the
card, then the severity of the bug in the *FreeBSD* bug database
should probably not be 5 - orherwise the database will contain a
large amount of bugs that claim to be of high severity but only
ever affect neglible amounts of people. That inserting a prototype
card can cause a crash in one particular driver is not really a
high impact / severity bug as far as FreeBSD users/developers as a
whole is concerned.

> In any case, if the priority field is to be meaningful at all,
> there must be a group decision (of some kind) on its value.  It
> is *not* something that should be set by the person reporting
> the problem.
>

This really applies to both fields. It is a question of labelling
and application - for both what the fields and the potential
numerical values for the fields - mean. Some assignemts of meaning
are more useful (according to a metric) than others.

> I'll admit that there is some value for newly arrived uncommitted
> resources to a priority field.  On the other hand, realize that
> in most cases, if the priority is really that high, trivial things
> will be fixed, and it will leave only non-trivial problems, which
> are not really in the scope of ability of a "newby off the street"
> who is looking for some way to start contributing.  For that, you
> almost need a third field "complexity"... which implies analysis
> of problems, which implies scheduling of unschedulable resources,
> etc..  It's a hard problem, with only volunteer resources available;
> I would argue it was intractable, except on an individual basis, in
> fact.
>

And complexity need not be always determinably until the problem is
largely fixed either. But it would be of a large relevenace only if
hard rules were associated with the bug categorisations, instead of
being merely indicators of a sort of the state of the codebase.
Knowing how many 'complex' problems there are with a codebase is
normaly less useful information than knowing how many reported
problems have a large impact or need application of otherwise
unallocated resources.

At least with FreeBSD the meaning of the fields can be just technical
and doesn't need an additional layer for marketing.

> -- Terry
>



To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-hackers" in the body of the message

Re: Lower power SMP boxes?

[Narvi]

On Sat, 1 Feb 2003, Kurt J. Lidl wrote:

> On Sat, Feb 01, 2003 at 11:21:49AM -0800, Matthew Dillon wrote:
> > :On Sat, Feb 01, 2003 at 10:17:23AM +0100, Mats Larsson wrote:
> > :> Via just recently announced their new Nehemiah processor capable of smp,
> > :> presumably slow as its precursor but also the lowest power consuming
> > :> processor at the market (at least with standard socket fcpga motherboard)
> > :[...]
> > :> http://www.via.com.tw/en/viac3/c3.jsp
> > :
> > :It says "IO/APIC support in future versions".  So, it's not an SMP option
> > :today, as I understand it.
> > :
> > :-Kurt
> >
> > Although, this is more a deficiency in the way FreeBSD is designed.  Using
> > an APIC is nice, but not absolutely necessary.  All we need are good
> > specs on how VIA's SMP cpus interact with each other and we could
> > support it.
>
> How else are you going to do the physical interrupt steering?
> Unless they have gone through the effort of implementing a whole
> new and different steering mechanism -- which would fly in the face
> of having off-the-shelf OS support from the people in Redmond, at
> the very least.
>

At least at some point there was a thing called OpenPIC which the then big
two alternative x86 processor vendors AMD and Cyrix promised to support.
In practice I believe it ever only got used on one or two PPC boards.

> > I like the 11 watts specified in the paper.  That *is* low power for
> > the class of system they are selling.  I don't see a clock specification
> > but I assume it is going to be at least as fast as the ~900MHz M-9000.
>
> It says "the new generation VIA C3 processor is available at speeds starting
> at 1GHz" in the paragraph under "Enhanced Digital Media Performance".
>
> -Kurt
>
> To Unsubscribe: send mail to [EMAIL PROTECTED]
> with "unsubscribe freebsd-hackers" in the body of the message
>


To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-hackers" in the body of the message

Re: Lower power SMP boxes?

[Narvi]

On 5 Feb 2003, Benno Rice wrote:

> On Wed, 2003-02-05 at 07:25, Narvi wrote:
> > On Sat, 1 Feb 2003, Kurt J. Lidl wrote:
>
> [snip]
>
> > > How else are you going to do the physical interrupt steering?
> > > Unless they have gone through the effort of implementing a whole
> > > new and different steering mechanism -- which would fly in the face
> > > of having off-the-shelf OS support from the people in Redmond, at
> > > the very least.
> > >
> >
> > At least at some point there was a thing called OpenPIC which the then big
> > two alternative x86 processor vendors AMD and Cyrix promised to support.
> > In practice I believe it ever only got used on one or two PPC boards.
>
> One or two like every new world Macintosh. =)
>
> In fact quite a lot of PowerPC boards use OpenPIC as it's specified in
> the CHRP spec, which IBM and Apple follow for the most part.  I know
> that Motorola's MPC10x host-pci bridge chipsets also have an
> OpenPIC-compatible PIC in them.  I also wouldn't be surprised if the Mai
> Logic chipset used on the Teron CX motherboards has one as well.


Ah, well, I didn't know that it migrated to the PPC mainstream - these are
very much 95/96/97 memories. So by virtue of ppc mp support freebsd would
also get nearer to x86 openpic mp support (should any such ever show up)?

>
> --
> Benno Rice <[EMAIL PROTECTED]>
>


To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-hackers" in the body of the message

Re: Network block device.

[Narvi]

On Wed, 29 Jan 2003, Matthew N. Dodd wrote:

> On Wed, 29 Jan 2003, Brandon D. Valentine wrote:
> > IMO NBD is less of a hack than you think it is.  It is one of the
> > necessary components for creating a single system image from a cluster
> > of commodity hardware and this is something Linux developers are working
> > earnestly on.  They're targeting a poor man's NUMA.
>
> Sorry, it still sounds dumb.
>
> They should really look at Sprite.  (And anyone thats doing clustering and
> not looking at VMS deserves what they get.)
>
> On a real cluster running a single image all all the drives would just
> show up.  There wouldn't be any hacking going on.  Stuff like this kind of
> requires 64 bit machines to be at all useful.
>

Only as long as only clusters with some level of single system image (for
various values of it) are allowed to be real clusters. But calling NBD a
necessary component of a single system image is very probably wrong - its
almost at cross purposes to getting to a single system image cluster. NBD
is neither needed (you could use say transaction based function shipping
for one example) nor sufficent.

> --
> | Matthew N. Dodd  | '78 Datsun 280Z | '75 Volvo 164E | FreeBSD/NetBSD  |
> | [EMAIL PROTECTED] |   2 x '84 Volvo 245DL| ix86,sparc,pmax |
> | http://www.jurai.net/~winter |  For Great Justice!  | ISO8802.5 4ever |
>
> To Unsubscribe: send mail to [EMAIL PROTECTED]
> with "unsubscribe freebsd-hackers" in the body of the message
>



To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-hackers" in the body of the message

Re: Network block device.

[Narvi]

[cc: reduced]

On Wed, 29 Jan 2003, Brandon D. Valentine wrote:

> On Wed, Jan 29, 2003 at 06:06:20PM -0500, Matthew N. Dodd wrote:
> >
> > What you really want is SCSI over IP.  Anything else is just a hack and
> > not to be trusted.  I think that NFS is less of a hack than NBD though.
>
> IMO NBD is less of a hack than you think it is.  It is one of the
> necessary components for creating a single system image from a cluster
> of commodity hardware and this is something Linux developers are working
> earnestly on.  They're targeting a poor man's NUMA.  In this case the

A cluster - no matter how transparently it has a single system image - is
not a NUMA. DSM is not really NUMA either, and not all that many things
really benefit from DSM - most things aplicable to DSM run better if you
use a combination of messgae passing and io/function shipping instead.

But going to NBD is a flawed idea in that unless you are planning to use
it for a database that can manage its own locking you are better off with
a file system instead.

> idea is that each node [network] boots a very minimal operating system
> image which acts as a slave to the master node, making its hardware
> (disks in this case) available via some interconnect using network block
> devices.  Then the operating system on the master node can mount the
> devices under one unified /.  OpenMosix is working on solving the other
> parts of the puzzle, which are scheduling and cache/memory coherency.
> Myrinet is rapidly converging on SGI's CrayLink interconnect as a
> low-latency memory bus, making this possible in the next few years on PC
> hardware.
>

MyriNet is not a memory bus - its a fast message passing interface. You
can use it to imnplement DSM (big suprise, you can with 10Mbit ethernet
aswell) but it doesn't have the hardware you would need to actually make
use of it as ccNUMA.

> Brandon D. Valentine
> --
> [EMAIL PROTECTED] http://www.geekpunk.net
>
> "We've been raised on replicas of fake and winding roads, and day after day up
> on this beautiful stage we've been playing tambourine for minimum wage, but we
> are real; I know we are real."  -- David Berman
>
> To Unsubscribe: send mail to [EMAIL PROTECTED]
> with "unsubscribe freebsd-hackers" in the body of the message
>



To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-hackers" in the body of the message

Re: gcc problem/openoffice failure

[Narvi]

On Tue, 27 May 2003, Don Lewis wrote:

> On 27 May, Julian Elischer wrote:
> >
> > For the last month (more actually)(and after completely rebuilding my
> > system and all the ports on it) I have not been able to compile
> > the openoffice port due to gcc failures.
> > (I have posted the message earlier several times)
> > Has anyone been able to compile the openoffice port recently?
> >
> > somewhere in it's private compilation of mozilla (why does it do that? I
> > already have mozilla running?) gcc (doing c++) has a heart attach and
> > keels over dead.
>
> I think the reason to make the build take longer.  Lots of fun on 400
> MHz PII.
>

the mozilla addresbook <-> OOo integration part of OOo needs a patch
that continues suffer the sad fate of many uncomitted mozilla patches. if
you change the main mozilla port to use it, you could just use the main
one and no longer need the separate build.


___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to "[EMAIL PROTECTED]"

Re: HEADS UP! Major commits in the tree coming soon

[Narvi]

On Thu, 29 May 2003, [iso-8859-1] Thorsten Futrega wrote:

> Dear users,
>
> The most important changes I'm going to commit today:
>
> - Remove gcc and replace it with a new TenDRA
> snapshot.

yay! but what about c++ support?

> - Remove GNU tar.

double yay!

> - Fix httpd.ko to make it work on buggy AMD
> processors.
> - Drop support for 386 and 486 cpus.
> - Remove ext2 support (GPL encumbered).
> - Add perl 5.8 *and* python 2.2 to base.
> - Remove Sendmail and replace it with Postfix.
>

mostly yawn...

> If anyone has any reason why these should not be
> committed, I'll give a 5 hours grace time. Send
> replies
> to the list.
>
> Thank you.
>
>  Thorsten and the rest or the release engineering team.
>

___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to "[EMAIL PROTECTED]"

Re: HEADS UP! Major commits in the tree coming soon

[Narvi]

On Fri, 30 May 2003, Narvi wrote:

[snip]

Ahem.. i am very embarrassed about having sent the reply, everybody please
pretend I was nowhere near the thread, pretty please?


___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to "[EMAIL PROTECTED]"

Re: Disk reliability (was: Tagged Command Queuing or Larger Cache?)

[Narvi]

On Wed, 30 Oct 2002, Greg 'groggy' Lehey wrote:

> On Tuesday, 29 October 2002 at  2:03:50 +, Daniel O'Connor wrote:
> > On Tue, 2002-10-29 at 01:54, Kenneth Culver wrote:
> >>> I haven't had any trouble with the WDxxxBB drives - the WDxxxAA drives
> >>> are pretty unreliable though.
> >>>
> >> Hrmm, I havn't tried those, but just about every WD drive I've used has
> >> ended up with problems which were of course handled by the warranty, but
> >> even then, I still had to reinstall the os and pull a bunch of stuff from
> >> my backups which was a pain to do for each failure. Like I said, just my
> >> personal experience. I don't think the new 8MB cache drives have been out
> >> long enough to actually develop the problems I've seen on WD drives
> >> though.
> >
> > Yes, but my point is that the AA drives are bad, but the BB drives seem
> > good. I have been using them for a while (~1 year) without trouble.
>
> I've had trouble with BB drives.  Given that they have (or had) a 3
> year warranty, 1 year of experience isn't very much to go by.
>
> > Personally I find that no HD manufacturer has a good reputation -
> > they have all made trashy drives at one point. Give the general time
> > it takes for problems to surface vs product lifetimes makes deciding
> > what to buy a PITA :(
>
> That's a more valid point.
>
> Note that WD and Seagate have dropped their warranty on IDE drives
> from 3 years to 1 year.  What does this say to you?

That the cost cutting and pricewars on IDE drives are close to the point
where the drives are essentially disposables - buy it, use until fails,
throw away and buy a new(er) model.

>
> Greg
> --
> See complete headers for address and phone numbers
>


To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-hackers" in the body of the message

Re: Swap overcommit (was Re: Replacement for grep(1) (part 2))

[Narvi]

[cc: list trimmed]

On Thu, 15 Jul 1999 lyn...@orthanc.ab.ca wrote:

> > In that scenario, the 512MB of swap I assigned to this machine would be
> > dangerously low.
> 
> With 13GB disks available for a couple of hundred bucks, my machines aren't
> going to run out of swap space any time soon, even if I commit to disk.
> 
> All I want for Christmas is a knob to disable overcommit.
> 
> --lyndon
> 

CVSup the source repository and start writing.

Sander

There is no love, no good, no happiness and no future -
all these are just illusions.



To Unsubscribe: send mail to majord...@freebsd.org
with "unsubscribe freebsd-hackers" in the body of the message

Re: Threaded X libraries

[Narvi]

On Fri, 13 Aug 1999, Stephen Hocking-Senior Programmer PGS Tensor Perth wrote:

> I'm attempting to build the X11 libs with the thread safety stuff (I beleive 
> Linux can already be built like this) and have discovered when linking that 
> we 
> don't have the getpwnam_r & getpwuid_r functions in out libc_r. Is anyone 
> planning on adding these?
> 
> 
>   Stephen
> 

See the archives - I think it has already come up at least once.

Sander

There is no love, no good, no happiness and no future -
all these are just illusions.

> It's all part of my plan to make SDL (Sam Lantinga's Simple Direct Media 
> Layer) work. It dies quite frequently when starting sound & graphics in some 
> of the test apps. I am suspicious that it requires a threadsafe libX11.
> -- 
>   The views expressed above are not those of PGS Tensor.
> 
> "We've heard that a million monkeys at a million keyboards could produce
>  the Complete Works of Shakespeare; now, thanks to the Internet, we know
>  this is not true."Robert Wilensky, University of California



To Unsubscribe: send mail to majord...@freebsd.org
with "unsubscribe freebsd-hackers" in the body of the message

Re: SRA+IDEA Telnet

[Narvi]

How exactly do you plan to get this to the FreeBSD internationsl
server that has the crypto repository?

Sander

There is no love, no good, no happiness and no future -
all these are just illusions.

On Thu, 12 Aug 1999, Nick Sayer wrote:

> Ok. I have put up a rough cut of my proposed src/crypto/telnet stuff
> with SRA
> authentication and IDEA encryption. It requires the libutil from 3.2 (or
> better),
> but it appears to work pretty well.
> 
> Please don't download it if you're outside the US.
> 
> But if you are in the US, you can grab it from
> ftp://ftp.kfu.com/pub/sra-idea.FreeBSD-32.tgz
> 
> Move your existing /usr/src/crypto/telnet out of the way and unpack the
> tgz into /usr/src/crypto.
> 
> Then cd into telnet and make.
> 
> In particular, anyone who sees any stupid stuff in the Makefiles (I had
> to guess a lot) or
> anything that would break existing (kerberos) functionality, please let
> me know.
> It seems to me, though, that since there were no Makefiles in there
> before the kerberos stuff
> must be using its own Makefiles with these source files or some such
> magic.



To Unsubscribe: send mail to majord...@freebsd.org
with "unsubscribe freebsd-hackers" in the body of the message

Re: SRA+IDEA Telnet

[Narvi]

On Sat, 14 Aug 1999, Mark Murray wrote:

> > Couldn't you work the code so it obtains all its' encryption functions
> > from an external library, such as the system's libdes? That would let you
> > export the code, since it doesn't provide any encryption functions itself,
> > and international people could use the international DES library (for
> > other encryption algorithms, pick a freely available implmenetation such
> > as the one from openssl).
> 
> This makes the most sense. Thrash it out as a port, and if that works,
> we can bring it into both repositories.
> 

Why not just wait and bring the openssl library in? 

A new telnet authentifications method that just we used is not terribly
usefull.

> M
> --
> Mark Murray
> Join the anti-SPAM movement: http://www.cauce.org
> 
> 
Sander

There is no love, no good, no happiness and no future -
all these are just illusions.




To Unsubscribe: send mail to majord...@freebsd.org
with "unsubscribe freebsd-hackers" in the body of the message

Re: Whither makefiles for src/crypto/telnet/* ?

[Narvi]

On Sat, 14 Aug 1999, Kris Kennaway wrote:

> On Fri, 13 Aug 1999, Dave Walton wrote:
> 
> > If you really want to work on an encrypted telnet, check out The 
> > Stanford SRP Authentication Project (http://srp.stanford.edu/srp/).  
> > I'd love to see SRP integrated into the FreeBSD telnet/telnetd.
> 
> I got started on this, to the extent of storing the SRP data in the passwd
> file as an additional password crypt() method (using my modified libcrypt
> - see http://www.physics.adelaide.edu.au/~kkennawa/crypt-990725.tar.gz),
> but ran out of time. I hope to be able to work on it again in a few weeks
> once I get my computer back, now that I'm in the US.
> 

Now taht you are in the US, you have to give it up (until you aren't) or
keep a separate versions and describe to others in broad terms what you
did to it.

You can't save it back there, 'cause that would be exporting 8-)

> Kris
> 

Sander

There is no love, no good, no happiness and no future -
all these are just illusions.




To Unsubscribe: send mail to majord...@freebsd.org
with "unsubscribe freebsd-hackers" in the body of the message

Re: BSD XFS Port & BSD VFS Rewrite

[Narvi]

On Mon, 16 Aug 1999, Terry Lambert wrote:

> > > > On Fri, 13 Aug 1999, Terry Lambert wrote:
> > > > 
> > > > > Has anyone mentioned to them that they will be unable to incorporate
> > > > > changes made to the GPL'ed version of XFS back into the IRIX version
> > > > > of XFS, without IRIX becoming GPL'ed?
> > > > 
> > > > Given that they say they're dropping IRIX and going with Linux, I don't
> > > > think it'll be a problem.
> > > 
> > > Can you please site a reference for this, other than wishful
> > > thinking by the Linux camp?
> > 
> > Here's one:
> > http://www.zdnet.com/pcweek/stories/news/0,4153,1015908,00.html
> > 
> > But just about every trade rag covered it.
> 
> 
> Begging your pardon, but:
> 
> 
> | --- With the help of Veritas Software Corp., SGI will work to add
> | key features of its Irix operating system to the Linux platform.
> | Currently, Irix runs on the MIPS platform. Once SGI switches
> | entirely to Intel Corp.'s IA/64 platform, that will be the end of
> | Irix. 
> |

Why would switch to IA/64 mean end of IRIX? SGI has long planned to switch
to IA/64, but with IRIX. If SGI wants to continue building Origins, esp
the high CPU count ones, IRIX is to stay for a long time.

> | SGI is also forming an alliance with NEC Corp. to increase its
> | market share in Japan.
> 
> These paragraphs are contradictory.  It implies an end to MIPS.
> 

An end to high-end MIPS may come ... if Merced, etc. peform well enough.
As this is a topic beaten to death on comp.arch, everybody interested
should look there.

> Nintendo 64 uses MIPS.
> 

Which doesn't matter all that much. MIPS cpus for nintendo could be made
by say MISP, not SGI (and SGI sold/is trying to sell MIPS).

> It also seems a bit overzealous.
> 

You bet. It seems it is to hard foir the journalists to actually read the
press releases.

> 
>   Terry Lambert
>   te...@lambert.org
> ---
> Any opinions in this posting are my own and not those of my present
> or previous employers.
> 

Sander

There is no love, no good, no happiness and no future -
all these are just illusions.




To Unsubscribe: send mail to majord...@freebsd.org
with "unsubscribe freebsd-hackers" in the body of the message

Re: anybody love qsort.c?

[Narvi]

Doesn't the qsort just switch to isort *if* the partition to sort is short
enough? 

Got to check it out, but afaik the size at that qsorts switch to isort is
usually between 8 and 24, with 16 being most common - both halfs are
shorter than 16, so they get isorted.

Sander

There is no love, no good, no happiness and no future -
all these are just illusions.

On Wed, 18 Aug 1999, Christopher Seiwald wrote:

> The FreeBSD qsort implementation has a rather nasty degenerate case.
> If you have data that partitions exactly about the median pivot, yet
> which is unsorted in either partition, you get get treated to an insertion
> sort.  Example:
> 
>   1 2 3 4 5 6 7 8 9 10 19 18 17 16 14 14 13 12 11
> 
> qsort picks 10 as the median, does no swaps on its first pass, and so
> decides to switch to an insertion sort.   The idea is that if no swaps
> occur, the data is likely to be nearly already sorted and a good candidate
> for insertion sort.  This turns out to be a (very) bad idea if you have
> some unsorted data buried in the middle of a (very) large dataset.
> 
> The implementation claims to come from Bentley and McIlroy's paper,
> "Engineering a Sort Function," and this is largely true, but the insertion
> sort optimization(?) isn't in that paper.  The GNU qsort.c only does an
> insertion sort if it is below a certain threshhold in size, and so never
> attempts such a sort on the whole dataset.  (The GNU qsort does a number
> of other things pooh-poohed in the Bentley paper.)
> 
> It's a pretty straightforward change to bypass the insertion sort for
> large subsets of the data.  If no one has a strong love for qsort, I'll
> educate myself on how to make and contribute this change.
> 
> Christopher
> 
> Christopher Seiwald Perforce Software  1-510-864-7400
> seiw...@perforce.com f-f-f-fast SCM   http://www.perforce.com
> 
> 
> 
> To Unsubscribe: send mail to majord...@freebsd.org
> with "unsubscribe freebsd-hackers" in the body of the message
> 



To Unsubscribe: send mail to majord...@freebsd.org
with "unsubscribe freebsd-hackers" in the body of the message

Re: SPARC?

[Narvi]

On Mon, 23 Aug 1999, Dennis wrote:

> I heard a rumor that freebsd runs on a sparc, but I dont see any backing
> for that. Is it in the works?
> 
> dennis
> 

It is more correct to say that it passes in and out of the thoughts of
people from time to time, with very little code that has actually
materialised.

Sander

There is no love, no good, no happiness and no future -
all these are just illusions.




To Unsubscribe: send mail to majord...@freebsd.org
with "unsubscribe freebsd-hackers" in the body of the message

Re: CS Project

[Narvi]

On Thu, 9 Sep 1999, Julian Elischer wrote:

> I think he wants something like an "inverted chroot"
> (you can see out but others can't see in?
> (into all facets, e.g. process stats, etc.)
> 

It sounds like a "FreeBSD VM", VM taken to mean virtual machine. Anybody
in such a 'jar' would not notice (be able to notice) the existence of
others at all. 

With somedata hiding and given file systems mounted only in such a 'jar'
the ones in it would have no way of telling.

> julian
> 



To Unsubscribe: send mail to majord...@freebsd.org
with "unsubscribe freebsd-hackers" in the body of the message

Re: ifconfig: changing mac address

[Narvi]

On Sat, 15 May 1999, Greg Lehey wrote:

> On Friday, 14 May 1999 at 21:15:33 -0500, Dan Nelson wrote:
> > In the last episode (May 14), David Scheidt said:
> >> On Sat, 15 May 1999, Greg Lehey wrote:
> >> :It seems there's a need, and the possibility.  Would somebody like
> >> :to suggest a syntax?
> >>
> >> ifconfig interface ether ab:cd:ef:fe:dc:ab  [options]
> >>
> >> makes sense to me.
> >
> > And the next step would be to make the kernel realize that two cards
> > ifconfig'd with the same MAC address are meant to be bonded together as
> > one route (lots of switches support this).  I have some machines that
> > I'd love to be able to get 20MB/sec bandwidth between transparently.
> 
> I think you need to reconsider that idea.  How are you going to double
> the bandwidth of the wire?
> 

The cards don't have to be on the same wire, they just need to connect to
the same switch.

Indeed, I don't think two cards can be on the same wire with 10/100BaseT/TX.

> Greg
> --
> See complete headers for address, home page and phone numbers
> finger g...@lemis.com for PGP public key
> 


There is no love, no good, no happiness and no future -
all these are just illusions.




To Unsubscribe: send mail to majord...@freebsd.org
with "unsubscribe freebsd-hackers" in the body of the message

Re: BSD, GPL, the world today.

[Narvi]

On Fri, 14 May 1999, Wes Peters wrote:

> Matt Curtin wrote:
> > 
> > > On Thu, 13 May 1999 10:25:21 -0400, Dennis  said:
> > 
> > Dennis> All software has bugs
> > 
> > TeX has no bugs.
> 
> TeX has no *known* bugs.  To the best of my knowlege, even Dr. Knuth
> has not yet been able to *prove* it is correct.
> 
> > But it's the exception, not the rule.
> 
> It certainly is, but perhaps it shouldn't be.
> 
> I've worked on a few carefully verified systems, and they are quite
> expensived to create.  They're the kind of systems that you hope
> would be carefully checked, though, since they involve flinging
> nuclear bombs at people.
> 
> Anyone want to pony up a few dozen million dollars to do an NSCCA
> on FreeBSD?
> 

Would somebody use such a version even if somebody did come up with the
money? After all the months spent at verifing the correctness of FreeBSD,
they would wake up in the world where FreeBSD has meanwhile moved on by
some version numbers and has tons of new features everybody wants.

IMHO we have some years till we have enough stability that such a thing
would be even a sensible thing to do (as in - there are enough people who
will want to run it and parts can be merged back).

> -- 
>"Where am I, and what am I doing in this handbasket?"
> 
> Wes Peters Softweyr LLC
> http://www.softweyr.com/~softweyr  w...@softweyr.com
> 

Sander

There is no love, no good, no happiness and no future -
all these are just illusions.




To Unsubscribe: send mail to majord...@freebsd.org
with "unsubscribe freebsd-hackers" in the body of the message

Re: Database holywars?

[Narvi]

On Thu, 20 May 1999, Dan Moschuk wrote:

> 
> | ¿Have you considered PostgreSQL? It is on the ports collection, and is a
> | heavy duty database engine, with transactions, subqueries (only partial
> | support), etc. Version 6.5 will be released in about two weeks, and it
> | adds MVCC (multi-version concurrency control), which will improve a lot
> | its multi-user capabilities. And, I know of some projects that are using
> | it for multi-GB databases. I've been using it for or student database
> | for more than two years (since version 6.0), and am quite happy with
> | it. See www.postgresql.org for more information.
> 
> If I recall correctly, isn't postgresql *based* off of the Berkeley DB 
> engine?
> 
> -Dan
> 
No. At least I really don't think so. the lineage of postgresql is 
postgres->postgres95->postgresql

Sander

There is no love, no good, no happiness and no future -
all these are just illusions.





To Unsubscribe: send mail to majord...@freebsd.org
with "unsubscribe freebsd-hackers" in the body of the message

Re: SGI releases source code of OpenVault

[Narvi]

On Thu, 3 Jun 1999, Pavel Narozhniy wrote:

> Hello
> Free downloads of source code of OpenVault here:
> http://www.sgi.com/software/opensource/openvault/
> 
> Does anybody want to port it to FreeBSD?
> 
> -- 
> Pavel Narozhniy
> nic-hdl: PN395-RIPE
> http://www.sumy.net
> 

I guess there might be those who want to port it. But it's complex and
most people don't have tape libraries. 

Depending on the fate of OpenVault and it's spread, it may well be
beneficial to have OpenVault included in the FreeBSD base after some time.

Sander

There is no love, no good, no happiness and no future -
all these are just illusions.



To Unsubscribe: send mail to majord...@freebsd.org
with "unsubscribe freebsd-hackers" in the body of the message

Re: vinum performance

[Narvi]

On Thu, 17 Jun 1999, David E. Cross wrote:

> I have a drive that is rated at ~16 Meg/second, and indeed it delivers on the
> order of 15+ Meg/second.  If I use Vinum to create a concatinated device
> of 2 such units performance drops to 2.5 Meg/sec.  This seems like a 
> drastic drop in performance.  Any ideas what I am doin incorrectly?
> 

Try changing stripe size. How big is it right now?

> --
> David Cross   | email: cro...@cs.rpi.edu 
> Systems Administrator/Research Programmer | Web: 
> http://www.cs.rpi.edu/~crossd 
> Rensselaer Polytechnic Institute, | Ph: 518.276.2860
> Department of Computer Science| Fax: 518.276.4033
> I speak only for myself.  | WinNT:Linux::Linux:FreeBSD
> 

Sander

There is no love, no good, no happiness and no future -
all these are just illusions.



To Unsubscribe: send mail to majord...@freebsd.org
with "unsubscribe freebsd-hackers" in the body of the message

Re: vinum performance

[Narvi]

On Thu, 17 Jun 1999, Greg Lehey wrote:

> On Thursday, 17 June 1999 at 11:10:08 +0300, Narvi wrote:
> >
> > On Thu, 17 Jun 1999, David E. Cross wrote:
> >
> >> I have a drive that is rated at ~16 Meg/second, and indeed it delivers on 
> >> the
> >> order of 15+ Meg/second.  If I use Vinum to create a concatinated device
> >> of 2 such units performance drops to 2.5 Meg/sec.  This seems like a
> >> drastic drop in performance.  Any ideas what I am doin incorrectly?
> >
> > Try changing stripe size. How big is it right now?
> 
> This was a concatenated plex.
> 

Do we know that for a fact? It could be concatenated by striping. 

And no, i am not sure he was using vinum terminology (and he didn't say
plex anywhere).

> Greg
> --
> See complete headers for address, home page and phone numbers
> finger g...@lemis.com for PGP public key
> 

Sander

There is no love, no good, no happiness and no future -
all these are just illusions.





To Unsubscribe: send mail to majord...@freebsd.org
with "unsubscribe freebsd-hackers" in the body of the message

Re: Swap overcommit (was Re: Replacement for grep(1) (part 2))

[Narvi]

[cc: list trimmed]

On Thu, 15 Jul 1999 [EMAIL PROTECTED] wrote:

> > In that scenario, the 512MB of swap I assigned to this machine would be
> > dangerously low.
> 
> With 13GB disks available for a couple of hundred bucks, my machines aren't
> going to run out of swap space any time soon, even if I commit to disk.
> 
> All I want for Christmas is a knob to disable overcommit.
> 
> --lyndon
> 

CVSup the source repository and start writing.

Sander

There is no love, no good, no happiness and no future -
all these are just illusions.



To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-hackers" in the body of the message

Re: Threaded X libraries

[Narvi]

On Fri, 13 Aug 1999, Stephen Hocking-Senior Programmer PGS Tensor Perth wrote:

> I'm attempting to build the X11 libs with the thread safety stuff (I beleive 
> Linux can already be built like this) and have discovered when linking that we 
> don't have the getpwnam_r & getpwuid_r functions in out libc_r. Is anyone 
> planning on adding these?
> 
> 
>   Stephen
> 

See the archives - I think it has already come up at least once.

Sander

There is no love, no good, no happiness and no future -
all these are just illusions.

> It's all part of my plan to make SDL (Sam Lantinga's Simple Direct Media 
> Layer) work. It dies quite frequently when starting sound & graphics in some 
> of the test apps. I am suspicious that it requires a threadsafe libX11.
> -- 
>   The views expressed above are not those of PGS Tensor.
> 
> "We've heard that a million monkeys at a million keyboards could produce
>  the Complete Works of Shakespeare; now, thanks to the Internet, we know
>  this is not true."Robert Wilensky, University of California



To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-hackers" in the body of the message

Re: SRA+IDEA Telnet

[Narvi]

How exactly do you plan to get this to the FreeBSD internationsl
server that has the crypto repository?

Sander

There is no love, no good, no happiness and no future -
all these are just illusions.

On Thu, 12 Aug 1999, Nick Sayer wrote:

> Ok. I have put up a rough cut of my proposed src/crypto/telnet stuff
> with SRA
> authentication and IDEA encryption. It requires the libutil from 3.2 (or
> better),
> but it appears to work pretty well.
> 
> Please don't download it if you're outside the US.
> 
> But if you are in the US, you can grab it from
> ftp://ftp.kfu.com/pub/sra-idea.FreeBSD-32.tgz
> 
> Move your existing /usr/src/crypto/telnet out of the way and unpack the
> tgz into /usr/src/crypto.
> 
> Then cd into telnet and make.
> 
> In particular, anyone who sees any stupid stuff in the Makefiles (I had
> to guess a lot) or
> anything that would break existing (kerberos) functionality, please let
> me know.
> It seems to me, though, that since there were no Makefiles in there
> before the kerberos stuff
> must be using its own Makefiles with these source files or some such
> magic.



To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-hackers" in the body of the message

Re: SRA+IDEA Telnet

[Narvi]

On Sat, 14 Aug 1999, Mark Murray wrote:

> > Couldn't you work the code so it obtains all its' encryption functions
> > from an external library, such as the system's libdes? That would let you
> > export the code, since it doesn't provide any encryption functions itself,
> > and international people could use the international DES library (for
> > other encryption algorithms, pick a freely available implmenetation such
> > as the one from openssl).
> 
> This makes the most sense. Thrash it out as a port, and if that works,
> we can bring it into both repositories.
> 

Why not just wait and bring the openssl library in? 

A new telnet authentifications method that just we used is not terribly
usefull.

> M
> --
> Mark Murray
> Join the anti-SPAM movement: http://www.cauce.org
> 
> 
Sander

There is no love, no good, no happiness and no future -
all these are just illusions.




To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-hackers" in the body of the message

Re: Whither makefiles for src/crypto/telnet/* ?

[Narvi]

On Sat, 14 Aug 1999, Kris Kennaway wrote:

> On Fri, 13 Aug 1999, Dave Walton wrote:
> 
> > If you really want to work on an encrypted telnet, check out The 
> > Stanford SRP Authentication Project (http://srp.stanford.edu/srp/).  
> > I'd love to see SRP integrated into the FreeBSD telnet/telnetd.
> 
> I got started on this, to the extent of storing the SRP data in the passwd
> file as an additional password crypt() method (using my modified libcrypt
> - see http://www.physics.adelaide.edu.au/~kkennawa/crypt-990725.tar.gz),
> but ran out of time. I hope to be able to work on it again in a few weeks
> once I get my computer back, now that I'm in the US.
> 

Now taht you are in the US, you have to give it up (until you aren't) or
keep a separate versions and describe to others in broad terms what you
did to it.

You can't save it back there, 'cause that would be exporting 8-)

> Kris
> 

Sander

There is no love, no good, no happiness and no future -
all these are just illusions.




To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-hackers" in the body of the message

Re: BSD XFS Port & BSD VFS Rewrite

[Narvi]

On Mon, 16 Aug 1999, Terry Lambert wrote:

> > > > On Fri, 13 Aug 1999, Terry Lambert wrote:
> > > > 
> > > > > Has anyone mentioned to them that they will be unable to incorporate
> > > > > changes made to the GPL'ed version of XFS back into the IRIX version
> > > > > of XFS, without IRIX becoming GPL'ed?
> > > > 
> > > > Given that they say they're dropping IRIX and going with Linux, I don't
> > > > think it'll be a problem.
> > > 
> > > Can you please site a reference for this, other than wishful
> > > thinking by the Linux camp?
> > 
> > Here's one:
> > http://www.zdnet.com/pcweek/stories/news/0,4153,1015908,00.html
> > 
> > But just about every trade rag covered it.
> 
> 
> Begging your pardon, but:
> 
> 
> | --- With the help of Veritas Software Corp., SGI will work to add
> | key features of its Irix operating system to the Linux platform.
> | Currently, Irix runs on the MIPS platform. Once SGI switches
> | entirely to Intel Corp.'s IA/64 platform, that will be the end of
> | Irix. 
> |

Why would switch to IA/64 mean end of IRIX? SGI has long planned to switch
to IA/64, but with IRIX. If SGI wants to continue building Origins, esp
the high CPU count ones, IRIX is to stay for a long time.

> | SGI is also forming an alliance with NEC Corp. to increase its
> | market share in Japan.
> 
> These paragraphs are contradictory.  It implies an end to MIPS.
> 

An end to high-end MIPS may come ... if Merced, etc. peform well enough.
As this is a topic beaten to death on comp.arch, everybody interested
should look there.

> Nintendo 64 uses MIPS.
> 

Which doesn't matter all that much. MIPS cpus for nintendo could be made
by say MISP, not SGI (and SGI sold/is trying to sell MIPS).

> It also seems a bit overzealous.
> 

You bet. It seems it is to hard foir the journalists to actually read the
press releases.

> 
>   Terry Lambert
>   [EMAIL PROTECTED]
> ---
> Any opinions in this posting are my own and not those of my present
> or previous employers.
> 

Sander

There is no love, no good, no happiness and no future -
all these are just illusions.




To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-hackers" in the body of the message

Re: anybody love qsort.c?

[Narvi]

Doesn't the qsort just switch to isort *if* the partition to sort is short
enough? 

Got to check it out, but afaik the size at that qsorts switch to isort is
usually between 8 and 24, with 16 being most common - both halfs are
shorter than 16, so they get isorted.

Sander

There is no love, no good, no happiness and no future -
all these are just illusions.

On Wed, 18 Aug 1999, Christopher Seiwald wrote:

> The FreeBSD qsort implementation has a rather nasty degenerate case.
> If you have data that partitions exactly about the median pivot, yet
> which is unsorted in either partition, you get get treated to an insertion
> sort.  Example:
> 
>   1 2 3 4 5 6 7 8 9 10 19 18 17 16 14 14 13 12 11
> 
> qsort picks 10 as the median, does no swaps on its first pass, and so
> decides to switch to an insertion sort.   The idea is that if no swaps
> occur, the data is likely to be nearly already sorted and a good candidate
> for insertion sort.  This turns out to be a (very) bad idea if you have
> some unsorted data buried in the middle of a (very) large dataset.
> 
> The implementation claims to come from Bentley and McIlroy's paper,
> "Engineering a Sort Function," and this is largely true, but the insertion
> sort optimization(?) isn't in that paper.  The GNU qsort.c only does an
> insertion sort if it is below a certain threshhold in size, and so never
> attempts such a sort on the whole dataset.  (The GNU qsort does a number
> of other things pooh-poohed in the Bentley paper.)
> 
> It's a pretty straightforward change to bypass the insertion sort for
> large subsets of the data.  If no one has a strong love for qsort, I'll
> educate myself on how to make and contribute this change.
> 
> Christopher
> 
> Christopher Seiwald Perforce Software  1-510-864-7400
> [EMAIL PROTECTED] f-f-f-fast SCM   http://www.perforce.com
> 
> 
> 
> To Unsubscribe: send mail to [EMAIL PROTECTED]
> with "unsubscribe freebsd-hackers" in the body of the message
> 



To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-hackers" in the body of the message

Re: SPARC?

[Narvi]

On Mon, 23 Aug 1999, Dennis wrote:

> I heard a rumor that freebsd runs on a sparc, but I dont see any backing
> for that. Is it in the works?
> 
> dennis
> 

It is more correct to say that it passes in and out of the thoughts of
people from time to time, with very little code that has actually
materialised.

Sander

There is no love, no good, no happiness and no future -
all these are just illusions.




To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-hackers" in the body of the message

Re: CS Project

[Narvi]

On Thu, 9 Sep 1999, Julian Elischer wrote:

> I think he wants something like an "inverted chroot"
> (you can see out but others can't see in?
> (into all facets, e.g. process stats, etc.)
> 

It sounds like a "FreeBSD VM", VM taken to mean virtual machine. Anybody
in such a 'jar' would not notice (be able to notice) the existence of
others at all. 

With somedata hiding and given file systems mounted only in such a 'jar'
the ones in it would have no way of telling.

> julian
> 



To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-hackers" in the body of the message

Re: SCSI disk naming problem

[Narvi]

See LINT on details of how to wire down scsi devices...

Your proposal doesn't take adding a second scsi card into account.

On Fri, 1 Oct 1999 [EMAIL PROTECTED] wrote:

> Current FreeBSD SCSi disk naming mechanism is problem for using more than
> one disks in the chain during the disk failure.
> 
> The problem is that the name is not fixed with is SCSI ID. e.g.,
> if one disk is presented in the chain, regardless its SCSI ID, it is
> always named "da0";
> 
> if two disks are installed, the one with lower ID is named da0 and the
> other will be named as da1. When the lower ID one is crashed, then the
> other disk will be named as da0 (from da1) after reboot, and it is not
> mountable due to the name changing.
> 
> If a system has a UW SCSI controller with 15 disks in the chain,
> when the first disk (ID = 0) crashed, all rest 14 disks will be
> useless until either fstab modified or another disk is added with
> SCSI ID = 0.
> 
> Why not we use a fixed name corresponding the SCSI ID. That is,
> disk with ID 0 will be always named as da0, and disk with ID 1
> will be always named da1, etc.?
> 
> Is there problem with fixed disk naming mechanism?
> 
>   -Jin
> 
> 
> 
> To Unsubscribe: send mail to [EMAIL PROTECTED]
> with "unsubscribe freebsd-hackers" in the body of the message
> 



To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-hackers" in the body of the message

Re: SCSI disk naming problem

[Narvi]

On Fri, 1 Oct 1999 [EMAIL PROTECTED] wrote:

> [EMAIL PROTECTED] wrote:

[snip]

> > 
> > That's an interesting argument on the part of a few people.  The
> > commercial UNIX I first adminned had wired down, short names for disks
> > (rz0, rz1, rz2, ... ).  This was very nice.
> 
> This one does not resolve the controller problem either as
> [EMAIL PROTECTED] said.
> 
> So, I guess dac0t0, dac0t1, ...  dac3t4, will be good enough if we want
> to be short, but anything shorter than this will be meaningless.
> 

As long as you don't move a hard disk from one bus on the controller to
the other 8-)

> 
>   -Jin
> 




To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-hackers" in the body of the message

Re: SCSI disk naming problem

[Narvi]

On Fri, 1 Oct 1999, Bruce A. Mah wrote:

> If memory serves me right, [EMAIL PROTECTED] wrote:
> > 
> > This one does not resolve the controller problem either as
> > [EMAIL PROTECTED] said.
> > 
> > So, I guess dac0t0, dac0t1, ...  dac3t4, will be good enough if we want
> > to be short, but anything shorter than this will be meaningless.
> 
> Well...I personally prefer the short names.  On systems with multiple 
> controllers, the commercial UNIX I used (Ultrix) just continued its 
> numbering with rz0, rz1, rz2, ..., rz6, rz7, rz8, ...  FreeBSD lets you 
> do exactly the same thing.
> 
> Having long device names is confusing to users who only have one disk
> controller (and I'd bet this is the vast majority).  It took me a long

The vast majority has just one disk. Given the fast growth in disk sizes,
that majority will not decrease. 

> time to grok the syntax of Solaris device names and I still get confused
> about this.  Commercial or free doesn't have anything to do with this 
> issue...this scheme would force users to remember and type extra 
> characters that many of them don't need.  (/dev/da0s1a is long enough, 
> but /dev/dac0t0d0s1a is a little ridiculous for someone that has only 
> one controller and one drive.)
> 

If you want to *SOLVE* the problem, then make the disk wiring happen
before the kernel is booted. After all, we have a real cute boot loader
that can definately load the /boot/disk.wire file 8-)

The problem after all is *NOT* one of names but that disks not change
names unless the administrator wishes so. It doesn't matter the least how
we call them.

[snip]

> Cheers,
> 
> Bruce.
> 



To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-hackers" in the body of the message

Re: Apple's planned appoach to permissions on movable filesystems

[Narvi]

On Tue, 5 Oct 1999, Pat Dirks wrote:

> Hi,
> 
> I'm the File Systems Tech Lead at Apple in the Mac OS X Core OS group.  
> We've been struggling with the question of how best to handle permissions 
> on disks that are moved between systems for Mac OS X and Mac OS X Server: 
> the problem is that numeric IDs in inodes (or their moral equivalent) 
> written on the filesystem on one system don't necessarily map to the same 
> user, if they're valid at all, on another system (although they MIGHT).  
> With ZIP drives holding appreciable volumes of data and multi-gigabyte 
> FireWire drives becoming more common this is an issue that will 
> definitely pop up more and more as people carry data with them on 
> removable disk filesystems.
> 

[snip]

Have you given consideration to systems where the user/group database is
kept for (possibly a large) number of computers in a centralised manner by
say hesiod or nys (nis+). It would be nice if there was an easy interface
with these so that distributing the local system id numbers need not be
done by hand.

> -Patrick.
> 



To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-hackers" in the body of the message

Re: Apple's planned appoach to permissions on movable filesystems

[Narvi]

On Wed, 6 Oct 1999, Darren R. Davis wrote:

> Narvi wrote:
> 
> > [snip]
> >
> > Have you given consideration to systems where the user/group database is
> > kept for (possibly a large) number of computers in a centralised manner by
> > say hesiod or nys (nis+). It would be nice if there was an easy interface
> > with these so that distributing the local system id numbers need not be
> > done by hand.
> >
> 
> If I was going to look into that kind of approach I would seriously look into
> some
> sort of Directory Server tie in through LDAP.
> 
> Darren
> 

Only people at *MANY* sites are already using NIS and Hesiod (or some
entirely different way ) and are very unlikely to migrate to LDAP or some
other directory or not directory scheme for it, or probably even adapt it. 

No matter *what* scheme they are already using, they will expect the
interface to the system ids to be able to use it. Mandating scheme XYZ is
just like saying "Here, this is how we want you to distribute passwords.
Forget about Kerberos and NIS+ or whatever other scheme you may have in
place."

Which is why I only talked about the interface, not what might be behind
it or connected to it. 




To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-hackers" in the body of the message

Re: Apple's planned appoach to permissions on movable filesystems

[Narvi]

Sorry, this is somewhat late.

On Wed, 6 Oct 1999, Wilfredo Sanchez wrote:

> | Have you given consideration to systems where the user/group  
> database is
> | kept for (possibly a large) number of computers in a centralised  
> manner by
> | say hesiod or nys (nis+). It would be nice if there was an easy  
> interface
> | with these so that distributing the local system id numbers need not be 
> | done by hand.
> 
>   It's complicated.  We do have a distributed database (NetInfo) and  
> we considered perhaps using the name of the NetInfo domain to  
> determine local vs. foreign.  The problem is that distributed  
> databases are sometimes hierarchical, and can be mixed.  For example:
> 

Well, people for some reason miss the point. What I was talking about is
the 'interface', and that it be easy to attach things to it.

Site A will want to distribute the ids via hesiod.
Site B will want to distribute the ids via nis+.
Site C wants to do it via Netinfo
Site D wantd to use LDAP.

There may be others (SNMP?).

One way to do this is for example to have:
a) a parameter (by default null) that specifies which program
   to run to get a list of local system ids
b) a parameters (by default null) that specifies which program
   to run if we want to verify if a certain id has been added
   to the set of local ids since the startup.

As the program can be anything (inc. a shell script) almost any way of
distributing the local systems ids can be accomodated. 

This is of course just one way to achieve it (think of PAM).

[snip]

> 
>   -Fred
> 
> 
> --
>Wilfredo Sanchez, [EMAIL PROTECTED]
> Apple Computer, Inc., Core Operating Systems / BSD
>   Technical Lead, Darwin Project
>1 Infinite Loop, 302-4K, Cupertino, CA 95014
> 
> 
> 
> To Unsubscribe: send mail to [EMAIL PROTECTED]
> with "unsubscribe freebsd-hackers" in the body of the message
> 



To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-hackers" in the body of the message

Fun with vinum

[Narvi]

Should you decide to use vinum keep in mind that you:

a) reboot to make sure that whatever you just set up can
   automatically start itself
b) alternatively
vinum l
vinum makedev
vinum create -f configfile
vinum start
   is your friend and avoids most of the problem

IMHO it should not panick the kernel when it doesn't like the disk setup. 



To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-hackers" in the body of the message

Re: Fun with vinum

[Narvi]

On Mon, 11 Oct 1999, Greg Lehey wrote:

> On Sunday, 10 October 1999 at 19:33:44 +0300, Narvi wrote:
> >
> > Should you decide to use vinum keep in mind that you:
> >
> > a) reboot to make sure that whatever you just set up can
> >automatically start itself
> 
> This is always a good idea.  You don't have to do it immediately, of
> course.
> 
> > b) alternatively
> > vinum l
> > vinum makedev
> > vinum create -f configfile
> > vinum start
> >is your friend and avoids most of the problem
> 
> I don't understand why you would want to do this.  You certainly don't
> want vinum create followed by vinum start.
> 

Well, maybe 'vinum start' is not needed.

vinum l -> load vinum, but not teh disk conf
vinum makedev -> clean the /dev/vinum directory
vinum create ... -> tell vinum what the setup is.

> > IMHO it should not panick the kernel when it doesn't like the disk
> > setup.
> 
> IMO it shouldn't panic.  Could it be there's more to this message than
> you're divulging?
> 

Well, that happens if you post too late. The problem is (see a)) that it
does not automatically start, or rather, it tries but immediately
panicks. And vinum read panicks the system, as does vinum start.

The system is 3.3-STABLE, less than a week old.

> Greg
> --
> See complete headers for address, home page and phone numbers
> finger [EMAIL PROTECTED] for PGP public key
> 



To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-hackers" in the body of the message

Re: Generating interrupts ?

[Narvi]

On Wed, 13 Oct 1999, Johan Kruger wrote:

> In DOS it's possible to load the AX register with DA8C and generate a
> int 15, which will return the BIOS version string and the chipset
> identification int CL register. How do i do it in FreeBSD, and how do i
> generate a interrupt for that manner ?
> 

You don't. Well, at least not without VM86. Why do you want it? (and what
about freebsd-alpha mchines?)

> Greeting fellow FreeBSD users, by the way, 4.0-CURRENT builds a release
> just fine, and it's Linux emulator (sorry for the word emulator ) is
> exellent, try it.
> 



To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-hackers" in the body of the message

Re: --enable-haifa

[Narvi]

On Thu, 14 Oct 1999, Ollivier Robert wrote:

> According to W Gerald Hicks:
> > Just curious what effect using the --enable-haifa flag for building
> > gcc-2.95.1/x86 would have so I did a comparison using the Dhrystone
> > benchmark from /usr/ports/benchmarks/bytebench.
> 
> I think the Haifa scheduler is only really effective on pure RISC processors
> like the Alpha or PA-8000. I remember doing some tests with older versions of
> egcs and not seeing any significant changes...

According to my vague recollectiosn from the early times of egcs when
faifa was integrated, etc. part of the problem is that to have haifa be
really effective, all old kluges need be removed...

Something that back then happened/had happened only to a few cpus, like
HP-PA. Not sure what may have happened since, but I doubt somebody has
redone x86 code generation and fully integrated haifa ins scheduler.

> -- 
> Ollivier ROBERT -=- FreeBSD: The Power to Serve! -=- [EMAIL PROTECTED]
> FreeBSD keltia.freenix.fr 4.0-CURRENT #74: Thu Sep  9 00:20:51 CEST 1999
> 



To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-hackers" in the body of the message