Re: groff & NetBSD & relevance (was Re: Re: Re: Request to reconsider removal of groff from base system)

2015-04-08 Thread Julian H. Stacey
> (I would not complain if other obnoxious uses of C++, particularly newly
> added ones that greatly increase build time, left our tree, on the other
> hand...)
> 
> Thor

Maybe NetBSD might like how FreeBSD does it: 

https://svnweb.freebsd.org/base/head/Makefile.inc1?revision=280992&view=markup
.if ${MK_GROFF} != "no"


http://www.freebsd.org/cgi/man.cgi?query=src.conf&apropos=0&sektion=5&manpath=FreeBSD+10.1-RELEASE&arch=default&format=html
SRC.CONF(5)   FreeBSD File Formats Manual  
SRC.CONF(5)
NAME
 src.conf -- source build options
DESCRIPTION
 The src.conf file contains settings that will apply to every build
 involving the FreeBSD source tree; see build(7).

I don't see src.conf with
http://netbsd.gw.com/cgi-bin/man-cgi?src.conf+5+NetBSD-current

& I cant browse NetBSD source with eg

http://cvsweb.netbsd.org/bsdweb.cgi/src/Makefile?rev=1.312&content-type=text/x-cvsweb-markup&only_with_tag=HEAD

http://cvsweb.netbsd.org/bsdweb.cgi/~checkout~/src/Makefile.inc?rev=1.4&content-type=text/plain&only_with_tag=MAIN

So downloading 
http://ftp7.de.netbsd.org/pub/ftp.netbsd.org/pub/NetBSD/NetBSD-6.1.5/source/sets/src.tgz

Cheers,
Julian
--
Julian Stacey, BSD Linux Unix C Sys Eng Consultant Munich http://berklix.com
Indent previous with "> ".  Reply Below as a play script.
Send plain text, Not quoted-printable, HTML, or base64.


Re: groff & NetBSD & relevance (was Re: Re: Re: Request to reconsider removal of groff from base system)

2015-04-08 Thread Lyndon Nerenberg

On Apr 8, 2015, at 12:47 PM, Thor Lancelot Simon  wrote:

> To me, the simplest and most elegant solution would look to be replacing
> groff with heirloom troff as the formatter for what we have that isn't
> mandoc.

Amen to that.

Pulling troff from any UNIX distribution is just digging it a shallow grave, 
then pissing all over it.  And anyone who can't figure out how to use those 
obscure troff 'dot commands' is clearly incapable of writing the code he can't 
document.


signature.asc
Description: Message signed with OpenPGP using GPGMail


Re: groff & NetBSD & relevance (was Re: Re: Re: Request to reconsider removal of groff from base system)

2015-04-08 Thread Thor Lancelot Simon
On Wed, Apr 08, 2015 at 01:16:06PM -0500, David Young wrote:
> 
> Document preparation is important.  Deleting the only or best document
> preparation system in NetBSD (supposing that is even what's going on)
> is pretty lame, but it seems to me that neither *roff nor an MS Office
> knock-off will buy UNIX much relevance in 2015.  What's next?

Deleting the only thing we have that can format some of the design and user
documentation *included in the source tree* is even more lame.

It's not okay to make system builds require external tools, from my point
of view, and extremely questionable to rip documentation out of the source
tree or disable its build so we can remove a single tool.

To me, the simplest and most elegant solution would look to be replacing
groff with heirloom troff as the formatter for what we have that isn't
mandoc.

(I would not complain if other obnoxious uses of C++, particularly newly
added ones that greatly increase build time, left our tree, on the other
hand...)

Thor


Re: groff & NetBSD & relevance (was Re: Re: Re: Request to reconsider removal of groff from base system)

2015-04-08 Thread Dave Huang
On Apr 8, 2015, at 13:16, David Young  wrote:
> 
> On Tue, Apr 07, 2015 at 11:27:02AM +, Ron Swiernik wrote:
>> Again this is an enhancement? Can mandoc handle tbl and pic input?
>> 
>> UNIX has had the *roff tool suite for a long time. A text formatter is how 
>> they
>> got support from management to continue work on UNIX. I doubt we would be
>> talking about UNIX today if it wasn't for the suite.
> 
> ... but it seems to me that neither *roff nor an MS Office
> knock-off will buy UNIX much relevance in 2015.  What's next?

Agreed. In my ~20 years of using NetBSD, I've used *roff for something 
other than formatting manpages maybe twice (it was to format the stuff 
in /usr/share/doc, and only because I was curious to read them, not 
because I really needed them). I don't get the resistance to move 
things to pkgsrc. If nroff is important to you, grab the binary package 
and install it--nobody's saying that you won't be able to use it.

The rest of the world isn't going to flock to NetBSD because it still 
has a text formatter that uses .commands as inline markup.
-- 
Name: Dave Huang |  Mammal, mammal / their names are called /
INet: k...@azeotrope.org |  they raise a paw / the bat, the cat /
FurryMUCK: Dahan |  dolphin and dog / koala bear and hog -- TMBG
Dahan: Hani G Y+C 39 Y++ L+++ W- C++ T++ A+ E+ S++ V++ F- Q+++ P+ B+ PA+ PL++



groff & NetBSD & relevance (was Re: Re: Re: Request to reconsider removal of groff from base system)

2015-04-08 Thread David Young
On Tue, Apr 07, 2015 at 11:27:02AM +, Ron Swiernik wrote:
> Again this is an enhancement? Can mandoc handle tbl and pic input?
> 
> UNIX has had the *roff tool suite for a long time. A text formatter is how 
> they
> got support from management to continue work on UNIX. I doubt we would be
> talking about UNIX today if it wasn't for the suite.

There can be no denying that the MS office suite has serious usability
problems (not to mention problems with usefulness, relevance, and
resilience), but I don't think a batch-oriented system using dot
commands is any kind of improvement.

I don't think that arguments whether one old technology (MS Office is,
by now, rather long in the tooth) is an improvement or not over an older
technology (just how old is *roff?) really advance the project.

Document preparation is important.  Deleting the only or best document
preparation system in NetBSD (supposing that is even what's going on)
is pretty lame, but it seems to me that neither *roff nor an MS Office
knock-off will buy UNIX much relevance in 2015.  What's next?

Dave

-- 
David Young
dyo...@pobox.comUrbana, IL(217) 721-9981


Re: Request to reconsider removal of groff from base system

2015-04-08 Thread J. Lewis Muir
On 4/8/15 10:41 AM, Julian H. Stacey wrote:
> A multi- decades BSD developer friend & I discussed:
> It's a liability that there's no managers on *BSD.org projects to
> control the immature & instill perspective, explaining:

Hi, Julian.

But there is such a body for NetBSD; it's the Board of Directors and the
committees they oversee.  See .

Regards,

Lewis


Re: Request to reconsider removal of groff from base system

2015-04-08 Thread Julian H. Stacey
Ron Swiernik wrote:
> Again this is an enhancement? Can mandoc handle tbl and pic input?
> 
> UNIX has had the *roff tool suite for a long time. A text formatter is how 
> they
> got support from management to continue work on UNIX. I doubt we would be
> talking about UNIX today if it wasn't for the suite.

... etc ...

Agreed.   
I recall a past effort to similarly remove groff from FreeBSD src/ 
 (still in FreeBSD/branches/-current/src/ )

FreeBSD also periodicly suffers vandals removing working code
(demime, majordomo etc) & has also had to fight off proposals to
slash other things (eg procmail etc).

A multi- decades BSD developer friend & I discussed:
It's a liability that there's no managers on *BSD.org projects 
to control the immature & instill perspective, explaining:

  While there are some things each BSD person wouldn't miss we don't
  try to force removal, because we'd disagree which, & many different
  tools could be removed, inc. some we'd miss.
  
  Some new tools may always seem nicer for some new work & new
  people, than older existing tools, but never ignore the legacy
  our BSD systems carry, to support existing users' time investment & data.
  
  Code vandals will make any BSD less attractive to users, who would
  less complain, than silently leave, & not stay to later contribute
  to the BSD community.

Those who would ignore BSDs' Unix legacy:  Better play with free remit Linux.

Julian
--
Julian Stacey, BSD Linux Unix C Sys Eng Consultant Munich http://berklix.com
Indent previous with "> ".  Reply Below as a play script.
Send plain text, Not quoted-printable, HTML, or base64.


Re: SMP in dom0

2015-04-08 Thread Manuel Bouyer
On Tue, Apr 07, 2015 at 06:41:13PM +0530, Nagaraj Math wrote:
> Hi,
> 
> I am working on a product where I would like to have SMP in dom0.
> I have come across couple of forums, where it has been discussed, currently
> SMP is not supported in NetBSD in dom0 because back end drivers are not SMP
> safe.
> Does it mean that, as kernel NetBSD is SMP compatible in dom0, it is the
> drivers who needs to be fixed to support SMP? How big is this effort, my
> team would like to support in making SMP functional in dom0.

Yes, I think it's only the drivers that need some work.
domU kernels are already SMP-capable so most of the work is done.

The problem is, I guess, mostly in the backend drivers such as
arch/xen/xen/privcmd.c
arch/xen/xen/xenevt.c
the backend drivers arch/xen/xen/xennetback_xenbus.c and
arch/xen/xen/xbdback_xenbus.c
maybe arch/xen/x86/xen_shm_machdep.c

(basically, you need to replace spl-style locking with mutexes).

-- 
Manuel Bouyer 
 NetBSD: 26 ans d'experience feront toujours la difference
--


Re: dhcpcd / IPv6 question

2015-04-08 Thread Paul Goyette

On Wed, 8 Apr 2015, Niels Dettenbach (Syndicat IT & Internet) wrote:


Am 8. April 2015 14:40:14 MESZ, schrieb Greg Troxel :

I have tunnels from
sixxs, and aside from occasional POP issues they have been pretty
reliable.

With SIXX i have (sorry) very bad experiences - mainly regarding their support (just 
silence or no help in regaining an access to a misconfigured tunnel on SIXX side, 
inflexibility to just ignorance...) and partly their register policies. I wouldn't 
recommend it for applications require any kind of "reliability", but may OK for 
playing around with IPv6, where bandwidth and reliability are secondly or tertiary...


I think I understand - I filled out the sign-up form, and about four 
hours later I received a "rejection" notice.  The reason given was 
(paraphrased) "give us complete details or don't bother to apply."
Rather rude, even making allowances for their being from a different 
culture...


I've tried to resubmit my info to SixXS but I don't have much hope.

HEnet isn't really viable since I'm not only at a dynamic IP, but also 
behind a NAT box.  So I'd really need someone running aiccu/ayiya to 
handle the tunnels (at least, this is what I understand).


A worst-case possibility is for me to set up my own OpenVPN tunnel back 
to a virtual machine I've got running in California.  But I suspect that 
round-trip delays would make it nearly unuseable.




-
| Paul Goyette | PGP Key fingerprint: | E-mail addresses:   |
| (Retired)| FA29 0E3B 35AF E8AE 6651 | paul at whooppee.com|
| Network Engineer | 0786 F758 55DE 53BA 7731 | pgoyette at juniper.net |
| Kernel Developer |  | pgoyette at netbsd.org  |
-


Re: dhcpcd / IPv6 question

2015-04-08 Thread Niels Dettenbach (Syndicat IT & Internet)
Am 8. April 2015 14:40:14 MESZ, schrieb Greg Troxel :
>I have tunnels from
>sixxs, and aside from occasional POP issues they have been pretty
>reliable.
With SIXX i have (sorry) very bad experiences - mainly regarding their support 
(just silence or no help in regaining an access to a misconfigured tunnel on 
SIXX side, inflexibility to just ignorance...) and partly their register 
policies. I wouldn't recommend it for applications require any kind of 
"reliability", but may OK for playing around with IPv6, where bandwidth and 
reliability are secondly or tertiary...

I'm in the luck of having an access provider (VDSL) now who offers IPv6 
natively within their products over a dual stack by default - so the user can 
decide what IP to use for what in his network. Before i've runned my own IPv6 
tunnels over some of our noc locations with dual stack uplink. If you have 
similiar options (or i.e. some access to a machine/system on an IPv6), i would 
recommend to prefer them too over SIXX.

Not at least - if you want to prevent third party snooping of your traffic 
activities by i.e. services or whatever - i would avoid such well known / 
costless "quasi anonymous" tunnel services because they are much more easy to 
watchover by services - with or without the help of the provider (if the tunnel 
services is not runned by a service directly...). And if you come not around a 
tunnel service, try to prefer one which is usable with any proven standard open 
source solutions / completely open protocol standards.


just my two cents,


Niels.
-- 
Niels Dettenbach
Syndicat IT & Internet
http://www.syndicat.com


Re: SMP in dom0

2015-04-08 Thread Greg Troxel

I think it means that the xen-specific dom0-specific driver code in the
kernel doesn't have adequate locking.   The drivers used by domUs must,
because running a domU with multiple cpus is stable :-)




pgpXw4RM6manF.pgp
Description: PGP signature


Re: dhcpcd / IPv6 question

2015-04-08 Thread Greg Troxel

Paul Goyette  writes:

> OK, then off to plan B - let's see if I can get a tunnel broker to
> work with my dynamic IP address.  (Fixed/Static IP not available here
> in the Philippines for residential service, as far as I can tell.)
> (If that doesn't work, I'll just disable IPv6...)
>
> Anyone got suggestions for a simple tunnel set-up?

Two tunnel providers that come to mind are he.net (which I hear good
things about but have not used) and sixxs.net.

I have tunnels from
sixxs, and aside from occasional POP issues they have been pretty
reliable.  One can have a tunnel with a dynamic address and use tunnel
setup protocol to establish it; I have one like this for my notebook,
for when I'm on networks without v6.   There is net/aiccu in pkgsrc that
does the client half of this.


pgp4As0ISuQOs.pgp
Description: PGP signature


SMP in dom0

2015-04-08 Thread Nagaraj Math
Hi,

I am working on a product where I would like to have SMP in dom0.
I have come across couple of forums, where it has been discussed, currently
SMP is not supported in NetBSD in dom0 because back end drivers are not SMP
safe.
Does it mean that, as kernel NetBSD is SMP compatible in dom0, it is the
drivers who needs to be fixed to support SMP? How big is this effort, my
team would like to support in making SMP functional in dom0.

Thanks and Regards,
Nagraj


RE: Re: Re: Request to reconsider removal of groff from base system

2015-04-08 Thread Ron Swiernik
Again this is an enhancement? Can mandoc handle tbl and pic input?

UNIX has had the *roff tool suite for a long time. A text formatter is how they
got support from management to continue work on UNIX. I doubt we would be
talking about UNIX today if it wasn't for the suite.

If you still want this OS to stay relevant to people looking an alternative to 
M$
you should be hyping the formatting tools that come with it more. They are
very powerful tools for those who want to learn them. I have done documents
ranging from simple letters to forms that my boss said needed a Desktop
Publish Packager to do. And he has been using UNIX as long as I have. He, like
most others, considered them outdated and useless, I find it far easier to 
remember
a handfull of dot commands than to search through menus and button bars that
change wither every new release of the office tools.

All of my opinions are my own and do not in ANY way reflect those of the 
company I work for.

Ron

From: netbsd-users-ow...@netbsd.org [netbsd-users-ow...@netbsd.org] on behalf 
of carsten.ku...@arcor.de [carsten.ku...@arcor.de]
Sent: Tuesday, April 07, 2015 02:25
To: netbsd-users@NetBSD.org
Subject: Aw: Re: Re: Request to reconsider removal of groff from base system

Thor Lancelot Simon  wrote:

> mandoc(1) does not process roff.

Very simplified described it acts somehow like "nroff -mandoc ..." or "troff 
-mandoc ...".
There it understands a large subset of the nroff/troff language.
(Only a few useres need real nroff/troff for typesetting other documents than 
manpages.)

Carsten



Notice: This communication, including attachments, may contain confidential or 
proprietary information to be conveyed solely for the intended recipient(s). If 
you are not the intended recipient, or if you otherwise received this message 
in error, please notify the sender immediately by return e-mail and promptly 
delete this e-mail, including attachments, without reading or saving them in 
any manner. The unauthorized use, dissemination, distribution, or reproduction 
of this e-mail, including attachments, is strictly prohibited and may be 
unlawful.


RE: Request to reconsider removal of groff from base system

2015-04-08 Thread Ron Swiernik
And does fmt let you change font sizes?

All of my opinions are my own and do not in ANY way reflect those of the 
company I work for.

Ron

From: Martin Husemann [mar...@duskware.de]
Sent: Tuesday, April 07, 2015 04:19
To: Ron Swiernik
Cc: Kamil Rytarowski; netbsd-users@NetBSD.org; Gerard Lally
Subject: Re: Request to reconsider removal of groff from base system

On Mon, Apr 06, 2015 at 10:05:51PM +, Ron Swiernik wrote:
> Even Microsoft gives you Wordpad with the OS

And NetBSD base has vi and fmt...

Martin



Notice: This communication, including attachments, may contain confidential or 
proprietary information to be conveyed solely for the intended recipient(s). If 
you are not the intended recipient, or if you otherwise received this message 
in error, please notify the sender immediately by return e-mail and promptly 
delete this e-mail, including attachments, without reading or saving them in 
any manner. The unauthorized use, dissemination, distribution, or reproduction 
of this e-mail, including attachments, is strictly prohibited and may be 
unlawful.