Re: Under FREEBSD network control.
On 18 jul. 2012, at 05:17, cz li wrote: > I would like to build a bridge using FREEBSD system.At the same time, > they can do the network traffic control.How to do it? Check the handbook - or, easier, do 'man bridge' and see the last example in the section 'examples'. Dw. ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "freebsd-hackers-unsubscr...@freebsd.org"
Re: Under FREEBSD network control.
Hi, On Wednesday 18 July 2012 10:17:31 cz li wrote: > I would like to build a bridge using FREEBSD system.At the same time, > they can do the network traffic control.How to do it? if I remember right, it is all in the handbook. You might also check man rc.conf and man ifconfig We will help you when you have some questions regarding the details. Erich ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "freebsd-hackers-unsubscr...@freebsd.org"
Under FREEBSD network control.
I would like to build a bridge using FREEBSD system.At the same time, they can do the network traffic control.How to do it? thank you! ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "freebsd-hackers-unsubscr...@freebsd.org"
Re: Resistance to documentation? (was Re: Pull in upstream before 9.1 code freeze?)
On 07/17/2012 03:38 PM, Dave Hayes wrote: > On 07/17/12 15:14, Doug Barton wrote: >>> Some sources of this are: I rarely read the handbook >> >> So now that we've discussed *our* shortcomings, let's discuss yours. :) >> Read the handbook. Seriously. > > I should have written that better. I *do* read the handbook; check the > conjunction. I said: > > "I rarely read the handbook *and* find that the procedures or tools as > advertised" Ok, you're off the hook then. :) ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "freebsd-hackers-unsubscr...@freebsd.org"
Re: Resistance to documentation? (was Re: Pull in upstream before 9.1 code freeze?)
On 07/17/12 15:14, Doug Barton wrote: Some sources of this are: I rarely read the handbook So now that we've discussed *our* shortcomings, let's discuss yours. :) Read the handbook. Seriously. I should have written that better. I *do* read the handbook; check the conjunction. I said: "I rarely read the handbook *and* find that the procedures or tools as advertised" -- Dave Hayes - Consultant - Altadena CA, USA - d...@jetcafe.org *The opinions expressed above are entirely my own* "Every extreme attitude is a flight from the self." -- Eric Hoffer ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "freebsd-hackers-unsubscr...@freebsd.org"
Re: Resistance to documentation? (was Re: Pull in upstream before 9.1 code freeze?)
On 07/17/2012 01:56 PM, Dave Hayes wrote: > I've been using FreeBSD since the 90s. My perception (over many years of > observation) is that the FreeBSD people most able to document what > exists and how to use it seem to also have the greatest resistance to > writing any documentation. Writing code is more fun than documenting it. People who are good at documenting other people's code usually go down 2 paths ... either they become very good at it and expect to be well paid for their services, or they realize that writing code is more fun than documenting it. That said, historically as a project we have placed very high value on attracting people who are good at writing good code, and not placed a high value on documentation. That's not to say that we don't value the people who *do* write our documentation, but if it comes to a choice between good code with no documentation, or no code, we have historically chosen the former. This is true to the extent that when I suggested to a new committer that they should have waited to add a new project until the man pages were written I got torn a new one by my fellow committers, and told that I was 'discouraging contributions' and 'bad for morale.' > Perception is usually subjective, and I'm not > going to try to prove this or claim objective truth here...I could very > well be objectively incorrect. Perhaps it's more general; it seems to me > at best that this community resists documentation and explanation in the > general case. Resistance is not accurate. Indifference is a better description. > Some sources of this are: I rarely read the handbook So now that we've discussed *our* shortcomings, let's discuss yours. :) Read the handbook. Seriously. The FAQ is stale, and needs attention, but the FreeBSD Handbook is top-quality stuff. It has some cobwebby bits, and if you find them, file PRs to bring it to our attention. But you can't on one hand say that we resist documentation, and then on the other hand admit that you haven't read our most important example. > ... and sometimes > asking anything is met with stoic silence (e.g. how > does libgeom work, especially the XML stuff...for that matter a good > detailed document on geom(8) with examples and best practices ). So we're back to the area where we are indeed weak. I have pushed and pushed (both privately and publicly) for us to get better in this area, and am constantly told that what I'm asking for is foolish and/or unnecessary. We really do need better design documents, and plans to change critical parts of the system should be better documented in advance. But frankly, this is incredibly unlikely to happen without a major change in the values system of the project as a whole; and the last core election made it pretty clear that it's not likely to happen any time soon. > This perception troubles me because, at least in my mind, a good > developer also documents the work and provides some sort of link or > summary for people who are running production or near-production > systems. I really don't understand why I have this perception, nor is it > logical that the perception should exist in the first place. Not only is the perception reasonable, but the process of writing out such documentation (different from handbook-style docs, or even man pages) often helps clarify both the actual proposed design, and the current state of things. It's a shame that we don't have a culture that not only encourages this, but requires it. However, we don't; and aren't ever likely to. Doug ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "freebsd-hackers-unsubscr...@freebsd.org"
Re: Resistance to documentation? (was Re: Pull in upstream before 9.1 code freeze?)
On Tue, Jul 17, 2012 at 01:56:33PM -0700, Dave Hayes wrote: > I've been using FreeBSD since the 90s. My perception (over many > years of observation) is that the FreeBSD people most able to > document what exists and how to use it seem to also have the > greatest resistance to writing any documentation. I'll just note that over the past ~6 months, the documentation team has seen a lot of new contributors and new energy. So from my view, the situation is improving. mcl ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "freebsd-hackers-unsubscr...@freebsd.org"
Resistance to documentation? (was Re: Pull in upstream before 9.1 code freeze?)
On 07/17/12 12:35, Mike Meyer wrote: I'm not going to do this - this is the kind of thing that makes me loathe Linux. But if you want this functionality in your/the base system, your first step is clear - write the WTF program! Until that exists, the rest is just pointless debating. I think this is unintentionally specious reasoning. No offense intended. :) The program itself is fairly trivial to write. It's the -content- that is important to the perceived usability of the tool. I do not believe the content can be written by one person alone; this would be a community effort. Without the content, most everyone will declare the tool useless, the experiment a failure, and it will be business as usual. So it's really not possible to write the tool and associated documentation "myself". Otherwise I would. The "pointless debating" is really an attempt to get a critical mass of knowledgeable developers to agree to participate in creating this tool. There seems to be an equal and opposing mass that feels we should dig for this information ourselves and the existence of a helpful tool to do this is a blight on the operating system. The problem actually has a deeper idea, and this is why I changed the subject line. I've been using FreeBSD since the 90s. My perception (over many years of observation) is that the FreeBSD people most able to document what exists and how to use it seem to also have the greatest resistance to writing any documentation. Perception is usually subjective, and I'm not going to try to prove this or claim objective truth here...I could very well be objectively incorrect. Perhaps it's more general; it seems to me at best that this community resists documentation and explanation in the general case. Some sources of this are: I rarely read the handbook and find that the procedures or tools work as advertised, or that there wasn't some better tool or idea I "should have just known to do". I likely miss some best practices because...the information is not out there and sometimes asking anything is met with stoic silence (e.g. how does libgeom work, especially the XML stuff...for that matter a good detailed document on geom(8) with examples and best practices ). This perception troubles me because, at least in my mind, a good developer also documents the work and provides some sort of link or summary for people who are running production or near-production systems. I really don't understand why I have this perception, nor is it logical that the perception should exist in the first place. It remains nonetheless. -- Dave Hayes - Consultant - Altadena CA, USA - d...@jetcafe.org *The opinions expressed above are entirely my own* Nasrudin was sitting talking with a friend as dusk fell. "Light a candle", the man said, "because it is dark now. There is one just by your left side." "How can I tell my right from my left in the dark, you fool?" came the reply. ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "freebsd-hackers-unsubscr...@freebsd.org"
Re: Pull in upstream before 9.1 code freeze?
On Tue, 17 Jul 2012 14:32:19 -0400 "Dieter BSD" wrote: > >> Why not create a command wtf(1)? > > there are really lot of good features that can be made in FreeBSD. > > actually good, instead of that crap > While this is certainly not the most important improvement that could > be made (Fix the PRs!), the proposed wtf command could be useful. And it's been suggested a number of times on this thread. The proposed path is: 1) Write the WTF (or portsearch, or ...) command that can take a command name and return a list of suggested ports. Make it a port, since that's pretty much a zero-resistance move. 2) Add code to the port to use the *existing* hooks in some of the shells in ports (bash and zsh both have this, for instance) to invoke said command appropriately when they hit a command-not-found error. 3) Let people evaluate and play with that. 4) Now decide if we want this command in the base system. If the answer is mostly no, stop here. 5) Propose a patch to your favorite shell in the base system so the functionality added in step 2 will work in it as well. I'm not going to do this - this is the kind of thing that makes me loathe Linux. But if you want this functionality in your/the base system, your first step is clear - write the WTF program! Until that exists, the rest is just pointless debating. http://www.mired.org/ Independent Software developer/SCM consultant, email for more information. O< ascii ribbon campaign - stop html mail - www.asciiribbon.org ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "freebsd-hackers-unsubscr...@freebsd.org"
Re: Pull in upstream before 9.1 code freeze?
>> Why not create a command wtf(1)? >> > there are really lot of good features that can be made in FreeBSD. > actually good, instead of that crap While this is certainly not the most important improvement that could be made (Fix the PRs!), the proposed wtf command could be useful. And, importantly, putting this functionality into a seperate utility is the correct way to do it. We don't want to add more complexity to the shell for several good reasons (bloat, possiblilty of bugs, slowness after every typo, not the Unix way[1], etc.). [1] "Make each program do one thing well. To do a new job, build afresh rather than complicate old programs by adding new features." http://www.faqs.org/docs/artu/ch01s06.html ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "freebsd-hackers-unsubscr...@freebsd.org"
Re: Pull in upstream before 9.1 code freeze?
On 07/16/12 22:45, Wojciech Puchar wrote: Why not create a command wtf(1)? there are really lot of good features that can be made in FreeBSD. actually good, instead of that crap Unless you have some objective, measurable, and quantifiable definition of "crap", your judgement is a subjective one and I am unable to evaluate whether I am for or against it. I find that it's a real problem finding good features in FreeBSD, especially if they are new. I don't have so much time to track mailing lists and pour over the source code (usually the single source of documentation on new features), so I would find a command that suggested new features and pointed the user to related documentation extremely useful. I'm sure there are many others who would agree. :) Would you explain why you do not? -- Dave Hayes - Consultant - Altadena CA, USA - d...@jetcafe.org *The opinions expressed above are entirely my own* The difference between a moral man and a man of honor is that the latter regrets a discreditable act, even when it has worked and he has not been caught. ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "freebsd-hackers-unsubscr...@freebsd.org"
Using mcelog
All I wanted to see how users of mcelog were implementing it on FreeBSD . My Linux servers tend to run it via cron hourly and dump the results to syslog or a local log file . For now I am going to make a similar setup . Does using it as a daemon provide anything running it via cron can't ? Are there any options to stay away from , Linux only options etc ? Also does anyone know what options there are for FreeBSD on sparc ? --- Mark saad | mark.s...@longcount.org ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "freebsd-hackers-unsubscr...@freebsd.org"
Re: Pull in upstream before 9.1 code freeze?
At 11:25 17/07/2012, Wojciech Puchar wrote: the behavior of shells is an even worse idea than turning this nanny behavior on for everyone. Add sysctl for apps is a no-no, sysctl is for system control, not userland still this stupid idea topics continue? Is FreeBSD finally intended to be unix implementation or feature war with linux/windows? Of course it continues. There must be one site for each thing, that way i (we) only search where it is and not where perhaps it should be. I suppouse that you want sendmail configuration on sysctl? Not all, only some config lines, other lines can be on rc.conf, sendmail.conf, maild.conf and 30 more conf files. It's better than having only one. There will be conflicts, changes between minor release of where is what, but, hey!! it's the way you want it. STOP IT. NO. And i can write with bigger uppercase letters than you ;) L ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "freebsd-hackers-unsubscr...@freebsd.org"
Re: Pull in upstream before 9.1 code freeze?
the behavior of shells is an even worse idea than turning this nanny behavior on for everyone. Add sysctl for apps is a no-no, sysctl is for system control, not userland still this stupid idea topics continue? Is FreeBSD finally intended to be unix implementation or feature war with linux/windows? STOP IT. ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "freebsd-hackers-unsubscr...@freebsd.org"
Re: Pull in upstream before 9.1 code freeze?
At 19:15 05/07/2012, Mike Meyer wrote: On Thu, 5 Jul 2012 13:09:44 -0400 Jason Hellenthal wrote: > On Thu, Jul 05, 2012 at 06:19:31PM +0200, Damien Fleuriot wrote: > > As long as it can be toggled off system-wide, persistently (sysctl?), I > > can't see the harm in bringing that in. > Haha sysctl... thats going quite a bit too far into the system for this. Yup. A sysctl (or rc.conf variable) intended specifically to control the behavior of shells is an even worse idea than turning this nanny behavior on for everyone. Add sysctl for apps is a no-no, sysctl is for system control, not userland control. The rc.conf is not for that neither, it has system wide configuration, not app specific config. The best solution (for me) is leave sh untouched without this functionality. Fork it and make a sh++ port with this (and more) functionality , install it and use it. Is it really too much work to change your default (non-root) shell? I use zsh f.ex. Take care, if you start the system in rescue mode or singleuser mode, will the new "hook" feature search the unmounted partitions for ports info? will it connect to internet for that? will fail miserably? L -- Si la vida te da la espalda, ¡tocale el culo! ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "freebsd-hackers-unsubscr...@freebsd.org"
