Re: Replacing BIND with unbound
On 8/21/2012 10:11 AM, Bjoern A. Zeeb wrote: On Tue, 21 Aug 2012, Dag-Erling Smørgrav wrote: Doug Barton do...@freebsd.org writes: Dag-Erling, do you have a timeline for getting started on the ldns/unbound import? I imported the code into the vendor tree, but did not proceed any further as there was still no firm consensus at the time. I believe the conclusion - to the extent that there was one - was that people were fine with tossing out BIND and importing ldns to replace the client bits, as long as we had suitable drop-in replacements for host(1) and dig(1), but there was no consensus on whether to import unbound. I'll start working on getting ldns into head this weekend. I think ldns really is not what we want; can you defer this for a week and we could chat in person, also wtih brooks around, next week? There is a wwaayy larger thing to the picture of resolver libraries, exspecially validating once, which includes standardization, acceptance, application support, etc. and I admit there should be a summary of that on the wiki but isn't yet as some of the things only very last-weekishly materialized for real for us. Neither importing ldns nor removing BIND is going to have any effect on the stub resolver library in libc. And if you have much larger plans for resolver libraries, especially validating ones, it would be great if they were discussed IN PUBLIC, so that those of us who know a little something about the topic can be involved in the discussion BEFORE all the decisions are made, and all the balls start rolling. Thanks, Doug -- I am only one, but I am one. I cannot do everything, but I can do something. And I will not let what I cannot do interfere with what I can do. -- Edward Everett Hale, (1822 - 1909) ___ 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: Replacing BIND with unbound
On 8/21/2012 11:08 AM, Bjoern A. Zeeb wrote: On Tue, 21 Aug 2012, Doug Barton wrote: Neither importing ldns nor removing BIND is going to have any effect on the stub resolver library in libc. Yes it does as if we are not carefull, we'll neither have a _proper_ validating caching resolver but 4 different resolver libraries 3 of which needing crypto and only 2 with a well known support plan and only 2 with the same interface in base. Can you please enumerate what resolver libraries you're talking about, because I don't understand what you're referring to here. The way that I'm using the terms above: 1. A validating, caching resolver is a full server type thing, such as BIND or Unbound. 2. The stub resolver library is (as currently implemented) part of libc, and currently uses code from a completely separate import of the BIND resolver library implementation. To be clear, removing src/contrib/bind9 won't affect that at all. 3. ldns _can_ be used to make a resolver library, but it does not have to be. Under the plan that des and I have it would be used as the basis of the dig-like tool called drill, and the host-alike tool that Vitaly provided. It's also a dependency of Unbound, FWIW. I have also said on numerous occasions that I don't think we should have a _single_ validating resolver in the base at all, however I understand that you think differently, which is why you raise the objection above. Can you see why Simon's question is important to not make the current problem worse? Of course I understand Simon's question. That's why I answered it. :) (rhetorical for you, Des will answer). Can we make sure if we do this that things like portsnap and freebsd-update will not stop working (using the command line tools for example)? I've been testing Vitaly's host-alike tool, and haven't run into any problems where the output is different. Obviously we would have to test the dependencies before we pulled BIND out altogether. That's why we are only contemplating doing this in HEAD, long before 10.0-RELEASE. It's also worth pointing out that if we stick to the plan *cough* that we have less than a year before 10-RELEASE, so getting started sooner rather than later here is a good thing. Can we have a longer plan of where we want to be in a year, which parts we need from where and how to get them, and if we feel like it, add names to this? It's strange that others in this thread have asked for it already, not just me yelling stop. But those things have already been discussed, most recently in this thread. Really, you need to pay attention if you want to be involved. :) Plan 0: Import ldns/drill/host-alike, remove BIND. Following which ... Plan A: Allow user to choose from a list of validating resolvers at install time, including at minimum Unbound and BIND. Plan B: Import Unbound Both Plans [AB] involve support for DNSSEC for whatever solutions we make available to the users. IMO in order to be considered for inclusion as a validating resolver the software has to support RFC 5011 rollovers, which means that the difficult part of DNSSEC support is the bootstrapping of the root trust anchor. I have an idea for how I want to do that for BIND in the ports, but lately I have been thinking that it might make more sense to write an rc.d script for the base that can do this in a generic way at boot time. What is definitely *not* going to be acceptable is a hard-coded set and forget scheme. We've already seen that fail in another OS, and I don't want to repeat that mistake. And if you have much larger plans for resolver libraries, especially validating ones, it would be great if they were discussed IN PUBLIC, so that those of us who know a little something about the topic can be involved in the discussion BEFORE all the decisions are made, and all the balls start rolling. Do you understand the part about the wiki from above? I can put an ACL on to exclude everyone but the secret cabal, having investigated days the last 18 months on the topic, talked to people on multiple continents, from different projects, ... but I hadn't planned to .. and I am not the only one. The fact that it's not written down is, as I said, things are only no longer totally nebulous since last week. I'm sorry, I don't understand most of the paragraph above, but what it sounds like is that you have been talking to people privately about what you think this stuff should look like for 1 1/2 years. I think that's great, but whatever private discussions you may have had don't give you ownership of the problem. This is too important for any one person (myself included) to deal with on their own. Whatever plans we may have in this area need to be thoroughly discussed, IN PUBLIC, before decisions are made, or actions are taken. Not to mention that if the discussion had been public we could potentially have benefited from the ability of many contributors being able to make progress faster than 1 person
Re: Replacing BIND with unbound
On 08/06/2012 13:23, Vitaly Magerya wrote: Doug Barton do...@freebsd.org wrote: On 07/07/2012 16:33, Garrett Wollman wrote: The utilities (specifically host(1) and dig(1)) are the only user-visible interfaces I care about. [...] ldns (a dependency of unbound) comes with drill, which is a dig-alike tool. I'd like to see us produce a host-alike based on ldns as well, If there still is interest, I've got just that at [1]. This tool, ldns-host, implements all the options of bind9-host (except for debugging ones), and produces close (and often identical) output. There's a list of differences between ldns-host and bind9-host in the man page (see [2]); most items can be fixed if people will request for it. Some more exotic situations where not tested though, so that list is only partial. [1] http://hg.tx97.net/ldns-host/file/ [2] http://manweb.tx97.net/http://hg.tx97.net/ldns-host/raw-file/tip/ldns-host.1 If I didn't already say so, this is awesome! :) Dag-Erling, do you have a timeline for getting started on the ldns/unbound import? -- I am only one, but I am one. I cannot do everything, but I can do something. And I will not let what I cannot do interfere with what I can do. -- Edward Everett Hale, (1822 - 1909) ___ 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: Replacing BIND with unbound
On 08/20/2012 01:55, Bjoern A. Zeeb wrote: We will continue to reject this until there are more firm plans, proper documentation on the security support side, which I cannot remember Simon got an answer for. I gave a clear answer. If there are any pieces missing it's up to Simon to follow up with Dag-Erling. I continue to say that I am not willing to trade one for another for the sake of just changing the name. Have you seriously not been paying attention to the numerous reasons why BIND in the base is no longer a good fit? In any case, importing ldns/unbound is a different question from removing BIND. Not only do I not see any reason not to move forward on the former, I think that once people see a solid implementation in place already it will ease the fears about removing BIND. Doug -- I am only one, but I am one. I cannot do everything, but I can do something. And I will not let what I cannot do interfere with what I can do. -- Edward Everett Hale, (1822 - 1909) ___ 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: Replacing BIND with unbound
On 08/20/2012 02:16, Mark Blackman wrote: On 20 Aug 2012, at 10:12, Doug Barton do...@freebsd.org wrote: On 08/20/2012 01:55, Bjoern A. Zeeb wrote: We will continue to reject this until there are more firm plans, proper documentation on the security support side, which I cannot remember Simon got an answer for. I gave a clear answer. If there are any pieces missing it's up to Simon to follow up with Dag-Erling. I continue to say that I am not willing to trade one for another for the sake of just changing the name. Have you seriously not been paying attention to the numerous reasons why BIND in the base is no longer a good fit? Perhaps bunging together a quick wiki-page to point busier individuals at would be handy? Just read this thread in the archives, that should do it for you. -- I am only one, but I am one. I cannot do everything, but I can do something. And I will not let what I cannot do interfere with what I can do. -- Edward Everett Hale, (1822 - 1909) ___ 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: Replacing BIND with unbound
On 08/20/2012 02:19, Bjoern A. Zeeb wrote: On Mon, 20 Aug 2012, Doug Barton wrote: On 08/20/2012 01:55, Bjoern A. Zeeb wrote: We will continue to reject this until there are more firm plans, proper documentation on the security support side, which I cannot remember Simon got an answer for. I gave a clear answer. If there are any pieces missing it's up to Simon to follow up with Dag-Erling. If you did, where was it. My email client shows 1 follow-up to http://lists.freebsd.org/pipermail/freebsd-hackers/2012-July/039837.html and that was unrelated and not you. You don't get to comment on the discussion if you're not going to follow the discussion. :) It's not up to me to advocate for the inclusion of unbound in any case, that's up to Dag-Erling. My point is simple ... BIND is not a good fit for the FreeBSD base, and it needs to go. The fact that we not only have a solid replacement for it ready to go, but a willing maintainer, is a bonus. Doug -- I am only one, but I am one. I cannot do everything, but I can do something. And I will not let what I cannot do interfere with what I can do. -- Edward Everett Hale, (1822 - 1909) ___ 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: How to diagnose system freezes?
On 07/31/2012 17:02, Yuri wrote: One of my 9.1-BETA1 systems periodically freezes. If sound was playing, it would usually cycle with a very short period. And system stops being sensitive to keyboard/mouse. Also ping of this system doesn't get a response. Just for fun, have you tried switching to the 4BSD scheduler in your kernel config? -- I am only one, but I am one. I cannot do everything, but I can do something. And I will not let what I cannot do interfere with what I can do. -- Edward Everett Hale, (1822 - 1909) ___ 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: dtraceall.ko with old nfsclient
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 On 07/31/2012 09:48, Fabian Keil wrote: I think guessing that INET and INET6 are available is a lot more reasonable than doing the same for the external NFS modules. FYI, there has been considerable work done to ensure that INET6 works without INET, so it's not safe to assume anything about the other just because 1 of them is present. TMK you still need one or the other though ... - -- I am only one, but I am one. I cannot do everything, but I can do something. And I will not let what I cannot do interfere with what I can do. -- Edward Everett Hale, (1822 - 1909) -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.19 (FreeBSD) iQEcBAEBCAAGBQJQH3q6AAoJEFzGhvEaGryEGXsH/RjKJQYsQqhbNw/Hb+vQV32V t9GiDcxrsiGBYWPwoGBUXf9UXLKz6V1KM47BUjZJaX3AEpjLWpkc10lanA1c6j23 DHvyU5gQVz4xjDm9xpLsiygCVuIQYKHE80ZmQRajeFwUOrcFMCyKuWH9evNjPWGq M11LYMbpBYbPw63LhYDpvcoxmi6E0LhvagWjgJfL1XNOcYK4kEHgxWv4wYjfLyuH +Vd1jTipkHSNxI7IdA0lHOsp7pNNQu5tSl/mQkH+72DXRKxNva63PnxrngQrRRv/ HrmZMMPRxjSyDUGkk/GzrH083yB17IP75eRJmvVplcZ5ytBSs7v2uqdmTmj/124= =OrU7 -END PGP SIGNATURE- ___ 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: On cooperative work [Was: Re: newbus' ivar's limitation..]
On 08/02/2012 12:18, David Chisnall wrote: Thank you for your thoughtful reply, You too ... I let some time go by to see what others had to say. I think it's disappointing that more people aren't concerned about this issue. On 2 Aug 2012, at 19:33, Doug Barton wrote: However, my point is that in spite of the fact that it's non-trivial, the mindset on this topic needs to change if the dev summits are going to continue to be significant focii of both work being done and decisions being made (which of course, they are). I believe that, before that decision can be made, there needs to be some consensus on what the purpose of the DevSummits is. In my view, DevSummits do not exist to set project policy. And yet, that's exactly what happens. It's easy to understand why ... you have a bunch of people together in the same place, they all agree on a topic, and after all, since they are the ones who are there, they should be the ones to make the decision, right? It's not necessarily that they are trying to do something malicious, it's just human nature. I know, I used to travel to conferences for a living. They are places where: - People can talk face to face about their current and planned projects. - Developers can meet on a social basis, making remote working easier. The latter is very important - I've found in other projects that it's far easier to work with someone on the other side of the world when you've chatted with them over a few beverages-of-choice. I agree with these points as well. (Again, been there, done that.) In fact I'm quite confident that a lot of the issues people have with me are related to this deficiency. :) Any official conversations happen on the mailing lists. This should be true, but it isn't. This is my point. DevSummits are for people working on similar things to meet and discuss their plans, and for people to have a chance to get to know what everyone else is doing, ... so far, so good .. for a limited set of 'everyone else'. ... and this is where I call shenanigans. This is an open project. Anything that is going to be done is going to be seen. If there are problems with a proposal it's better to see them early. If it's a good proposal, there is no reason not to share it. Slides and summaries so on from the more structured parts of this are available afterwards, which helps people who can't attend get the same benefit - they know what other people are working on. In the IETF context proposals often benefit from the real-time focus of attention, from both local and remote participants, that the meetings provide. There is no reason to believe that this would not be true in FreeBSD as well. The original complaint that spawned this long discussion was that decisions about the project are made behind closed doors. This is obviously true in the literal sense, as code always wins over chatter in an open source project, and the person willing to sit down and write the code gets the final say on how it should work, That's an oft-repeated maxim, especially around here. But we've already demonstrated that it isn't true. The only time that this is true is if the work being done is in line with what the PTB want. I've demonstrated this time after time by volunteering to do various projects my way and being told that my efforts weren't welcome. Not to mention having my finished, working code reverted by a core team member for an inferior, broken result. So can we please stop repeating that BS and focus on the real issues? although ideally with code review, design feedback and so on from others. Even if we broadcast everything that happens in the official parts of the DevSummits, that won't necessarily fix anything because a lot of the most productive conversations happen over dinner or in the pub. The community needs to not be accepting of the status quo, and demand that things be publicized on the lists first before decisions are made. Once again, if they are good decisions, they won't be harmed by sharing them in advance. If they are less-good, we could be saving someone efforts that would be otherwise wasted. If there is a real problem to address, then it is people making policy decisions at DevSummits, without adequate consultation. I have not observed this happening, but I would regard it as no different to people making policy decisions via private email, and something that should be subject to the same response: revisit the decisions in public if there are legitimate concerns raised about it, subject to the usual open source rule that the person actually willing to do the work gets to make the final call. Exactly. Finance is not the only obstacle. In some venues, bandwidth is a problem (not at Cambridge hopefully - people will have stopped using it all to stream the olympics by then), but in other venues we only have WiFi, which is shared with a room full of developers. If we buy some equipment (decent
Re: On cooperative work [Was: Re: newbus' ivar's limitation..]
On 08/02/2012 09:20, Scott Long wrote: On Aug 2, 2012, at 12:23 AM, Kevin Oberman kob6...@gmail.com wrote: Doug makes some good points. No, he doesn't. Yes I do! (So there) He and Arnould being argumentative and accusatory where none of that is warranted. I used to run the devsummits, and we did tele-conference lines for remote people to participate. I singled out BSDCAN specifically since that's where the action is for the last several years. I do recall your efforts in this regard, but it so happened that I was able to attend most of them in person back then. No slight towards what you did was intended. After I stepped down, others took it up and did the same thing. Usually, the lines were unused. I suspect that organizers simply stopped thinking about them after a while because of poor interest. There is no conspiracy of exclusion here, just simple human apathy. Here I have to disagree with you. Once again, speaking specifically about BSDCAN dev summits, I repeatedly asked the organizers to provide some sort of audio stream (phone, Internet, anything) and was repeatedly told it wasn't possible. This was not a case of lack of interest. This was a case of We understand that it is something people want, but it isn't going to happen. The invite system for the devsummit was, and still is, purely about providing some order to the process. It ensures that people attending are willing to demonstrate a minimum amount of interest, more than just wondering by a room one day and dropping in for free food and wifi. I specifically made allowances for this issue in my post. Doug -- I am only one, but I am one. I cannot do everything, but I can do something. And I will not let what I cannot do interfere with what I can do. -- Edward Everett Hale, (1822 - 1909) ___ 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: On cooperative work [Was: Re: newbus' ivar's limitation..]
On 08/02/2012 05:54, David Chisnall wrote: On 2 Aug 2012, at 05:30, Doug Barton wrote: I used to ask the PTB to provide *some* form of remote participation for even a fraction of the events at the dev summit. I don't bother asking anymore because year after year my requests were met with any of: indifference, hostility, shrugged shoulders (that's a hard problem that we can't solve), or embarrassment. Since if the right people around here want something to happen, it happens; I finally came to the conclusion that they didn't want remote participation to happen, so it won't. That's a shame. You haven't asked for this for the Cambridge DevSummit, You did read the part where I gave up, right? but others have and so we have arranged for cameras and microphones to be available for two of the sessions (the DocSummit and the ARM working group) to allow those who can not attend in person for various reasons to participate. Well that's a start. :) And where was this availability announced? If I missed it, that's on me. But providing remote access that you don't tell people about isn't really any better than not providing it at all. I don't know how useful it will be (hopefully everything will work, but my experience with video conferencing is that it stops working as soon as you try to do something important with it), If I can offer some advice from the trenches ... focus on making the audio robust, and put efforts into the video as resources permit. The combination of solid audio, making presentations available on line, and a chat room (IRC, jabber, whatever) allows for a great deal of remote participation. Video is nice, but if the video going down takes the audio with it, you're no better off than when you started. but there is certainly no active attempt to exclude people who can't attend. ... and here is where I need to push back. No active attempt to exclude people is not the same thing as actively encouraging remote participation. It's the latter that we're after. After each DevSummit, the results seem to appear on the wiki quite promptly - often during the sessions. At BSDCan this year, two of the working groups that I attended used OpenEtherPad to take minutes, so they were available in real time for non-attendees and people outside of the room were able to add things to them. There are usually people in the room on IRC as well, who are willing to relay things from people outside. Those all sound like nice steps forward, thank you for pointing them out. Nothing would make me happier than to be proven wrong in this area. What would be nice I think would be if these steps were formalized, and shared more openly. Having things on the wiki is nice, but reporting things in detail on the mailing lists puts it in the archives for future reference, as well as making it more broadly available to start with. Doug -- I am only one, but I am one. I cannot do everything, but I can do something. And I will not let what I cannot do interfere with what I can do. -- Edward Everett Hale, (1822 - 1909) ___ 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: On cooperative work [Was: Re: newbus' ivar's limitation..]
On 08/02/2012 09:44, Garrett Cooper wrote: The Watson/Losh connection worked really well in BSDCan 2010 :). I wasn't going to mention that, since I didn't want to tell tales out of school. But the fact that remote participation actually was provided for the right people, even though I was told repeatedly that it wasn't possible, actually highlights a big part of the problem. Advertising the teleconferencing lines might be an issue (I would have loved to have joined in some of the remote conferences, if for nothing more than be a fly on the wall, this year), but that's a separate thing aside. At various points when I was asking for remote participation at BSDCAN different people offered to provide this through their company's teleconferencing solutions, providing that the organizers could put a phone line in the room(s). They were told that it wasn't possible to do that. Doug -- I am only one, but I am one. I cannot do everything, but I can do something. And I will not let what I cannot do interfere with what I can do. -- Edward Everett Hale, (1822 - 1909) ___ 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: On cooperative work [Was: Re: newbus' ivar's limitation..]
On 08/02/2012 10:13, David Chisnall wrote: On 2 Aug 2012, at 17:46, Doug Barton wrote: Well that's a start. :) And where was this availability announced? If I missed it, that's on me. But providing remote access that you don't tell people about isn't really any better than not providing it at all. It's not widely advertised, because we're likely to be able to support a limited number of remote participants (10 seems like the upper limit for the technology that we're looking at, and I wouldn't be surprised if it degrades before then). Welcome to the 21st Century. :) There are widely available audio and video conferencing solutions that easily scale into the thousands of users, at minimal cost. As with all other things in the project, we welcome people who are willing to make an effort to engage. We provide it when people ask, not spontaneously, because organising cameras and decent microphones requires effort on the bart of the organisers. Yes, It takes effort. I get that. I've been part of the effort to provide remote participation for other groups, on a much larger scale than anything FreeBSD can dream of. My point, and I cannot emphasize this highly enough, is that your entire mindset about this is all wrong. It needs to shift from We'll do this on a small scale, for those who ask to We'll make providing robust remote participation a top priority, built into the planning from day 1. It's as simple as that. The FreeBSD Foundation has also offered to fund new contributors who want to attend but are unable to afford to do so on their own. In spite of the fact that I spent some effort encouraging people to apply for this, only one person actually did. It isn't just the financial cost of attending the summit. Often (as in my case) it's the lack of ability to take time away from personal, work, and/or family commitments. For others it may be the difficulty of doing the traveling at all. The fact that only 1 person took you up on this offer (and IIRC there have been similar results in the past) pretty clearly indicates that you're trying to solve the wrong problem. Given that the foundation has money to spend here, why not put 2 and 2 together and have the foundation invest in providing remote participation? That would benefit far more people, and almost certainly at less cost. Doug -- I am only one, but I am one. I cannot do everything, but I can do something. And I will not let what I cannot do interfere with what I can do. -- Edward Everett Hale, (1822 - 1909) ___ 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: On cooperative work [Was: Re: newbus' ivar's limitation..]
BTW, for those who'd like to get a flavor of what the IETF model looks like, the Vancouver meeting is in process now: https://datatracker.ietf.org/meeting/84/agenda.html Feel free to join in as a lurker. -- I am only one, but I am one. I cannot do everything, but I can do something. And I will not let what I cannot do interfere with what I can do. -- Edward Everett Hale, (1822 - 1909) ___ 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: On cooperative work [Was: Re: newbus' ivar's limitation..]
On 08/02/2012 10:34, Doug Barton wrote: BTW, for those who'd like to get a flavor of what the IETF model looks like, the Vancouver meeting is in process now: https://datatracker.ietf.org/meeting/84/agenda.html Feel free to join in as a lurker. Sorry, this agenda makes it easier to see the remote participation stuff: https://tools.ietf.org/agenda/84/ -- I am only one, but I am one. I cannot do everything, but I can do something. And I will not let what I cannot do interfere with what I can do. -- Edward Everett Hale, (1822 - 1909) ___ 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: On cooperative work [Was: Re: newbus' ivar's limitation..]
On 08/02/2012 10:37, David Chisnall wrote: Thank you for volunteering to organise this. It's good to see people with both the motivation and experience required to do something well actively contributing to the project. Cheap copout. And quite sad, especially coming from a newly elected core team member. Doug -- I am only one, but I am one. I cannot do everything, but I can do something. And I will not let what I cannot do interfere with what I can do. -- Edward Everett Hale, (1822 - 1909) ___ 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: On cooperative work [Was: Re: newbus' ivar's limitation..]
On 08/02/2012 10:40, Warner Losh wrote: One thing to remember about the IETF. There's many vendors that devote significant resources to the IETF. While I was at Cisco, for example, I know that we provided audio and video bridges to IEFT meetings to facilitate remote attendance at the meetings. Cisco dedicated several engineers to ensure that the audio and video quality remained good during the meetings and were able to use facilities cisco normally used for things like WebEx and MeetingPlace. With a global presence and infrastructure, they were able to pull it off. I'm not aware of similar resources within the project. I'm not suggesting we need anything at the full WebEx audio/video/presentation/chat level. And apparently the Foundation has money to spend on dev summits. As I suggested in a previous message, this would be a good long-term investment that would benefit a lot of people, especially in comparison to the money set aside for travel grants which is now going begging. Doug -- I am only one, but I am one. I cannot do everything, but I can do something. And I will not let what I cannot do interfere with what I can do. -- Edward Everett Hale, (1822 - 1909) ___ 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: On cooperative work [Was: Re: newbus' ivar's limitation..]
On 08/02/2012 05:39, John Baldwin wrote: I find this a bit ironic from you given that I've met you in person at USENIX ATC which is an order of magnitude more expensive than BSDCan (and in fact, one of the reasons the US-based BSDCon died and was effectively supplanted by BSDCan was that BSDCan is far cheaper). Yep, back in 2004 when traveling to conferences was part of my job, and before my daughter was born. My life now is quite different. ... not to mention that this thread isn't about me. It's about the importance of remote participation to the FreeBSD community as a whole. Doug -- I am only one, but I am one. I cannot do everything, but I can do something. And I will not let what I cannot do interfere with what I can do. -- Edward Everett Hale, (1822 - 1909) ___ 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: On cooperative work [Was: Re: newbus' ivar's limitation..]
On 08/02/2012 11:12, David Chisnall wrote: FreeBSD is a volunteer project. Yeah, I get that. I've been around quite a bit longer than you have, in case you didn't notice. :) I understand what you're saying, it's going to take work to change this mindset, and to provide these resources. If you read my posts on a factual basis, I'm not suggesting that the dev summits provide remote participation at the same level as groups like the IETF or ICANN do, and your point (and Warner's) that these groups have significant financial backing is well taken. However, my point is that in spite of the fact that it's non-trivial, the mindset on this topic needs to change if the dev summits are going to continue to be significant focii of both work being done and decisions being made (which of course, they are). What I'm *not* doing is demanding that any one person, or even any one group take responsibility for solving the whole problem on their own. Unfortunately, due to my inability to actually attend these meetings, I won't be able to provide the kind of hands-on assistance that I'd like to be able to. However it sounds like there may be financial resources available through the foundation, which would go a long way towards making a solution possible. The next step would be for people to agree that this is a problem that *needs* to be solved, followed by willingness on the part of dev summit organizers to support these efforts, which will hopefully lead to people who are willing and interested to step up and actually provide solutions. It's already been true in the past that various companies have volunteered to do this. There is no reason to believe that it wouldn't happen again if organizers are willing to be supportive. What I'm hearing so far is defensiveness, and an attempt to focus the discussion on me. Neither is helpful. :) Acknowledging that this is a problem that needs to be solved does not imply that by not solving it you personally have failed in some way. I apologize if anything I've written so far has implied otherwise. Doug -- I am only one, but I am one. I cannot do everything, but I can do something. And I will not let what I cannot do interfere with what I can do. -- Edward Everett Hale, (1822 - 1909) ___ 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: On cooperative work [Was: Re: newbus' ivar's limitation..]
On 8/1/2012 8:36 PM, Warner Losh wrote: I think this proves the point everybody has been saying: you are being needlessly contrary and confrontational. Actually if you take a step back and look at what Arnaud is saying objectively, he's right. If anyone can attend the meeting by simply getting an invitation from a committer, the only purpose the invitation serves is to force the mere-mortal user to kiss someone's ring. That's precisely the kind of elitist crap that I've been railing against for so many years now. OTOH, currently the dev summits generally take place with limited resources, so it's not really possible to have everyone attend. And (TMK) the invitation process is really more like a restaurant with a sign that says we reserve the right to refuse service to anyone. But on the _other_ other hand, the problem of things being discussed and/or decisions being taken exclusively at the dev summits, especially BSDCAN, has gotten quite bad over the last several years. Even amongst committers, the community has become divided between the haves who can travel to the summit, and the have nots who can't. Note, I'm quite sure that this statement will be met with howls of protest, from the haves, that this isn't the case. Even if they were sincere, it's incredibly easy for the people with the privileges to see their privileged state as normal, and lose sight of how the world looks from the cheap seats. In spite of Kevin's concerns (and I don't know what working groups he's been attending) the IETF model is really a good one to examine here. The majority of the work gets done on the mailing lists, with working group meetings serving as an opportunity for group discussion, presentations, etc. The results of the meetings are then published to the mailing list in the form of minutes, and the final decisions are made in public, on the lists. Another incredibly important feature, the meetings are open to remote participation in the sense that slide decks are published in advance, the meeting audio is streamed live, and there are jabber rooms for remote participants to interact with the people in the meeting. I used to ask the PTB to provide *some* form of remote participation for even a fraction of the events at the dev summit. I don't bother asking anymore because year after year my requests were met with any of: indifference, hostility, shrugged shoulders (that's a hard problem that we can't solve), or embarrassment. Since if the right people around here want something to happen, it happens; I finally came to the conclusion that they didn't want remote participation to happen, so it won't. That's a shame. If the only large, open project you've ever participated in is FreeBSD, what gets done around here feels normal to you. But don't be so quick to dismiss the viewpoints of people who have experience in the wider world. Doug -- I am only one, but I am one. I cannot do everything, but I can do something. And I will not let what I cannot do interfere with what I can do. -- Edward Everett Hale, (1822 - 1909) ___ 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
Is there a reason that xhci isn't mentioned in NOTES in 8-stable?
The xhci code in 8-stable works, but it's not mentioned in the NOTES files in sys/conf, sys/i386/conf, or sys/amd64/conf. The module is hooked up in sys/modules/usb/Makefile, and that's how I've been using it so far. Is it not possible to compile this code into the kernel? Doug -- Change is hard. ___ 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: Is there a reason that xhci isn't mentioned in NOTES in 8-stable?
On 07/19/2012 02:17, Hans Petter Selasky wrote:
On Thursday 19 July 2012 11:14:42 Doug Barton wrote:
The xhci code in 8-stable works, but it's not mentioned in the NOTES
files in sys/conf, sys/i386/conf, or sys/amd64/conf. The module is
hooked up in sys/modules/usb/Makefile, and that's how I've been using it
so far. Is it not possible to compile this code into the kernel?
Doug
Yes, you can compile xhci into the kernel using device xhci. Not sure who's
responsible for updating NOTES.
That would be you. :) (Since AFAICS you added the code.) It should
almost certainly also be in the GENERIC files for the systems to which
it applies.
In HEAD and stable/9 it's in sys/conf/NOTES, and
{amd64|i386}/conf/GENERIC; so the same should probably go for stable/8.
Not sure if the code works on stable/7 or not, but we're going to do
another release in stable/8 so it should be updated there for sure.
Doug
--
Change is hard.
___
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: Is there a reason that xhci isn't mentioned in NOTES in 8-stable?
On 07/19/2012 03:29, Hans Petter Selasky wrote:
On Thursday 19 July 2012 11:38:11 Doug Barton wrote:
On 07/19/2012 02:17, Hans Petter Selasky wrote:
On Thursday 19 July 2012 11:14:42 Doug Barton wrote:
The xhci code in 8-stable works, but it's not mentioned in the NOTES
files in sys/conf, sys/i386/conf, or sys/amd64/conf. The module is
hooked up in sys/modules/usb/Makefile, and that's how I've been using it
so far. Is it not possible to compile this code into the kernel?
Doug
Yes, you can compile xhci into the kernel using device xhci. Not sure
who's responsible for updating NOTES.
That would be you. :) (Since AFAICS you added the code.) It should
almost certainly also be in the GENERIC files for the systems to which
it applies.
In HEAD and stable/9 it's in sys/conf/NOTES, and
{amd64|i386}/conf/GENERIC; so the same should probably go for stable/8.
Not sure if the code works on stable/7 or not, but we're going to do
another release in stable/8 so it should be updated there for sure.
I've MFC'ed the NOTES bit, but I'm not sure about the GENERIC bit.
http://svn.freebsd.org/changeset/base/238616
Thanks! What are your concerns about adding it to GENERIC?
--
Change is hard.
___
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 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: FreeBSD 8.3
On 07/15/2012 02:39, Mike Meyer wrote: On Sat, 14 Jul 2012 13:29:59 -0700 Doug Barton do...@freebsd.org wrote: For the OP, make sure you have the latest BIOS. I had a similar problem with vt-x and it was solved by a later BIOS upgrade. And *that* solved the problem. The performance is much better, now being a lot like using a poor wireless mouse. My thanks to everyone who took time to help me. I'm glad to help, and more glad that it was that simple of a solution. :) Doug -- Change is hard. ___ 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: FreeBSD 8.3
For the OP, make sure you have the latest BIOS. I had a similar problem with vt-x and it was solved by a later BIOS upgrade. hth, Doug -- Change is hard. ___ 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: Replacing BIND with unbound 9.1 code freeze?)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 On 07/09/2012 19:46, Peter Jeremy wrote: Firstly, I should note that I'm not against removing bind from base. Thanks for clarifying. I'm merely saying that users are going to need some guidance during the transition. I've never argued against that. I think you misunderstood my flippant comment below. On 2012-Jul-09 13:52:15 -0700, Doug Barton do...@freebsd.org wrote: On 07/09/2012 13:47, Peter Jeremy wrote: On 2012-Jul-09 14:15:13 +0200, in freebsd-security, Andrej (Andy) Brodnik and...@brodnik.org wrote: Excuse my ignorance - but is there a how-to paper on transition from bind to unbound for SOHO? You don't need to transition if you don't want to. Just install BIND from the ports. IMHO, this is a copout. If the default response to anyone asking a question about transitioning is install bind then we might as well leave bind in the base system. 3 things to keep in mind in response. 1. We cannot keep BIND in the base system. 2. As above, I didn't say we shouldn't have a transition guide. I said we don't need one. That may not seem like an important distinction, but it is. :) 3. People really don't have to transition if they don't want to. All 3 of these are important points, but 1 and 3 are critical for people to understand if they are going to participate in this discussion. As I see it, FreeBSD systems fall roughly into 3 categories: 1) Client systems that need to lookup external DNS servers only. 2) SOHO systems that primarily do external lookups but need to be internally authoritative about their local network. 3) Systems that are primarily DNS servers. The third category is clearly a use ports case - there's no need for the base system to include all the tools necessary to build one of the root nameservers. The base system _must_ handle the first category - and I'll accept advice from dougb@ des@ that unbound is a good choice for this. The issues people seem to have with the change here are the user tools to interface with DNS - currently dig(1), host(1) and nslookup(1) - and des@ has now adequately covered this. I think your analysis above is basically correct. I think the majority of the remaining unease in this thread comes from people who administer systems in the second category. I (and I expect lots of other people) use bind for this solely because it is in the base system, not because it is the best tool for the job. Well that's yet another reason to take it out of the base so that people can analyze this critically. :) Seriously though, install BIND from ports is still a good answer to this use case. I'd argue that BIND 9.[89] is actually the best tool for the purpose you outlined, but there's no reason you couldn't use a combination of unbound and nsd. It would just be different than what people are used to. In particular, if unbound has no authoritative server capabilities, what suggestions are there for handling the private hosts in a SOHO environment? Stub and/or forward zones. The unbound docs have more information. But unfortunately no tutorial guides. https://unbound.net/documentation/index.html Having looked at the online copy of unbound.conf(5), it appears that unbound _does_ have some limited server capabilities - this wasn't clear in the original proposal. It's not immediately clear to me whether it's adequate for my purposes and, if it isn't, what I should use. You're still stuck on If it's in the base, it's the thing I have to use, so the fact that I don't know how to use it is causing me stress. Get over that, and realize that you can continue to use all the same stuff you already have, if you install BIND from ports. :) Doug - -- Change is hard. -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.19 (FreeBSD) iQEcBAEBCAAGBQJP+9XPAAoJEFzGhvEaGryENVkH/jWir7h8xI9CmdpMuXdMRZZT ulfoUs8KFt1BAwWvIQsXS1kwH+coe6i0rMd9ir9QCXgs9CqllJ8NhTcaY+OqxudA YcUWdzYIX6szfrgnocwxlZWIz2Xou63T3cRFdBQ9hzLDA7KzlJxgreTtLrEf3Fvg V1qv0ZigI3X50UtelOilROe/xqZLHwgOlUWpX6vuvYJhlw5s///Oe+13ZSQkqTa7 Roa9bz3r2PKaHSw3hTjKIuVDiCwJQMbx26IXmYf5SPIlJaBG28/LBGVFcxETMPPf c+fc1JYjDp2wZ1yBUmJ3gljtl7mGmGV40KF9WCie6dKrTSMgRGAvuTn+EMXD3rs= =RRzj -END PGP SIGNATURE- ___ 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: Replacing BIND with unbound
On 07/09/2012 14:47, Mark Blackman wrote: I never use '-t' with dig. drill *told* me I should use '-t' then completely failed to acknowledge I had done so. Have you reported this bug? -- Change is hard. ___ 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: Replacing BIND with unbound
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 On 07/09/2012 19:56, Peter Jeremy wrote: On 2012-Jul-10 00:40:07 +0200, Dag-Erling Smørgrav d...@des.no wrote: They are sufficiently similar that writing a wrapper that supports a significant subset of dig's command-line option and uses drill as a backend shouldn't take more than an afternoon for a reasonably experienced programmer. I would further suggest that where a dig(1) option isn't emulated, the fallback error message should refer the user to drill(1). IMO we don't need a wrapper for drill. For most people, just substituting 'drill' for 'dig' is enough. For more complex stuff people really need to learn the new tool, or install bind-tools. As for nslookup... it's been deprecated for a decade. But old fogies might still use it. Can I suggest that something along the lines of the the following be installed as /usr/bin/nslookup: #!/bin/sh echo nslookup is no longer supported. Please see drill(1) or host(1) 2 exit 1 You have no idea how long I've wanted to do that. :) - -- Change is hard. -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.19 (FreeBSD) iQEcBAEBCAAGBQJP+9bHAAoJEFzGhvEaGryEd9YIAL/A71XjQUC2aXZV36m4nFJ6 sGqfpeVcP/AjaF67wld1WukcrKxqqjmIQATlUna3m6L5t0exNGy4y3Udqmr5eOeo U6p/qYyJ2xkaPz+GnmcO6ygi4uWa0CwzbH5/jfprRSrCQuk7PZzRC0FvNsqqQcyc PtwEBmxTHzURSE6CaB19EuYKYQe+hLecSZlwVlipG4IaEmqmczpdjHnE1EHWiGCU 2uIEkJRradqXknAUTxfomAfM8ARiK2AQGT3TKRJuG8ApcF2CpoJkCaFKn73yxvn8 DQ3ENpSKkkRn8n7t/a9rOUQ0gbl9GP3dXpX/1Kw0dlq21LsGn5aOIy+yvOUw3bw= =Yrv4 -END PGP SIGNATURE- ___ 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: Replacing BIND with unbound (Was: Re: Pull in upstream before 9.1 code freeze?)
On 07/09/2012 16:45, George Mitchell wrote: On 07/09/12 17:01, Doug Barton wrote: On 07/09/2012 06:45, Mark Blackman wrote: Indeed, 'dig' and 'host' must be present and working as expected in a minimally installed system. So if you don't like the versions that get imported, install bind-tools from ports. Doug Doug, you are one of the people whose writings on the FreeBSD lists I most respect. Thank you for the kind words. :) But I think you are wrong about this one aspect of your proposed change. To discover that dig is suddenly not in the base FreeBSD system any more some day would be just about the worst violation of the Principle of Least Astonishment for me in many years. All flippancy aside, I understand what you're saying here. The problem is that we can't keep BIND in the base. Given that, we need to look at how best to handle the transition. Doug -- Change is hard. ___ 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: Replacing BIND with unbound 9.1 code freeze?)
On 07/10/2012 00:28, Mike Meyer wrote: I suspect that dnsmasq is a lot better tool for that job than BIND I think better is in the eye of the beholder, particularly whether or not the O is either small or well-staffed enough to pre-enter hostnames into the zone files. That said, dnsmasq is a great tool, especially if you're relying on DDNS. OTOH, as anyone can see from the named.conf in the base, I believe rather strongly that a large'ish network should take responsibility for being authoritative for 1918 stuff (et al) so that they don't go out over the network. You can still do that with other solutions, but this is one area where the fact that BIND can do both is a feature. Doug -- Change is hard. ___ 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: Replacing BIND with unbound
On 7/10/2012 4:27 AM, Mark Blackman wrote: On 10 Jul 2012, at 08:12, Doug Barton wrote: On 07/09/2012 14:47, Mark Blackman wrote: I never use '-t' with dig. drill *told* me I should use '-t' then completely failed to acknowledge I had done so. Have you reported this bug? Nope, you? I'm not the one bothered by it. :) -- Change is hard. ___ 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: Replacing BIND with unbound (Was: Re: Pull in upstream before 9.1 code freeze?)
On 07/08/2012 23:16, Avleen Vig wrote: On Sun, Jul 8, 2012 at 10:51 PM, Doug Barton do...@freebsd.org wrote: On 07/08/2012 22:43, Avleen Vig wrote: It would be silly not to keep bind-tools in base. Sounds easy, but not so much in practice. Keeping any of the code doesn't solve the problem of the release cycles not syncing up. And for the vast majority of users needs the tools we will import will be more than adequate. The question I keep asking myself is: Is this best for the users? Carrying BIND code in the base that is past EOL is not good for the users, period. Everything else we're discussing is an implementation detail. Linux has `nscd` which is a nice caching resolver, but most distributions still carry bind-tools in the default install. A) You're wrong about most. and B) The Linux distros have a default set of packages. There is no base like there is in FreeBSD. (Thus, your analogy is flawed.) That said, I still believe that our idea of what should, and should not be, in the base system is seriously flawed, and needs to be completely redone. But that's never going to happen, so I'm trying to work with what we've got. Doug -- This .signature sanitized for your protection ___ 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: Replacing BIND with unbound (Was: Re: Pull in upstream before 9.1 code freeze?)
On 07/09/2012 00:34, Avleen Vig wrote: On Sun, Jul 8, 2012 at 11:26 PM, Doug Barton do...@freebsd.org wrote: On 07/08/2012 23:16, Avleen Vig wrote: On Sun, Jul 8, 2012 at 10:51 PM, Doug Barton do...@freebsd.org wrote: On 07/08/2012 22:43, Avleen Vig wrote: It would be silly not to keep bind-tools in base. Sounds easy, but not so much in practice. Keeping any of the code doesn't solve the problem of the release cycles not syncing up. And for the vast majority of users needs the tools we will import will be more than adequate. The question I keep asking myself is: Is this best for the users? Carrying BIND code in the base that is past EOL is not good for the users, period. Everything else we're discussing is an implementation detail. I think the everything else we're discussing is an implementation detail is the part we'll have a problem with. No doubt there will be some bumps in the road. That's why it is going to be done in -current before 10-RELEASE, so that the bugs can be worked out. Although Garrett's reply to my email makes sense too. That said, I still believe that our idea of what should, and should not be, in the base system is seriously flawed, and needs to be completely redone. But that's never going to happen, so I'm trying to work with what we've got. Agreed. The idea of a minimally functional system itself might be flawed. No, there are 2 questions. First, What is a minimally functional system? and second, How do we provide it? Answering those questions is beyond the scope of this thread. Do you consider having `dig` and `host` essential in a minimally functioning system? I do. It's pretty f'king hard to resolve problems with installing the bind-utils port, if you don't know how to test your DNS :-) No one has said that we're going to leave the base without any tools. Please actually read the entire thread before commenting further. Yes, I'm going to be a stickler and say that having EOL code in base isn't the end of the world. Yours is a minority opinion. If there's a security vulnerability, sure, I understand that it might suck without support from ISC to patch dig/host/nslookup, but when was the last time that happened? Those binaries are just wrappers to the BIND libs, which are upgraded rather often when security vulnerabilities are found. Up to this point I've tried to respond to your questions in the hopes that answering them will serve to elucidate some of the details behind what's going on here. At this point though I'm starting to repeat myself. So if you have further questions I'd suggest that you read the entire thread so far, and then do some research on your own to try and understand the problem better. After that, if you still disagree, voicing your concerns when Dag-Erling has had a chance to get involved is probably your best bet. Doug -- This .signature sanitized for your protection ___ 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: Replacing BIND with unbound (Was: Re: Pull in upstream before 9.1 code freeze?)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 On 07/09/2012 13:47, Peter Jeremy wrote: On 2012-Jul-09 14:15:13 +0200, in freebsd-security, Andrej (Andy) Brodnik and...@brodnik.org wrote: Excuse my ignorance - but is there a how-to paper on transition from bind to unbound for SOHO? You don't need to transition if you don't want to. Just install BIND from the ports. In particular, if unbound has no authoritative server capabilities, what suggestions are there for handling the private hosts in a SOHO environment? Stub and/or forward zones. The unbound docs have more information. Doug - -- This .signature sanitized for your protection -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.19 (FreeBSD) iQEcBAEBCAAGBQJP+0R/AAoJEFzGhvEaGryECuQIAM2CtwjuYZPpQHYojU93mF7g ZLmTqmo8cdunpRUc66hHEirqnmnZ58LkosOugbuTgNvWAB9H2NOo25rFKkft3k0q S+5hSqS442NNvEYrsOlBhdPlP/cEpK36Mt24o3UlB1JVDjX0oj3BxXBc6BY08zHI 6/vCr74+SBHrg8k5yOhLpbgI5sEENhEAKNQY/6XSUmQlWzOPTMVEehp2Xon+llbf m/T5vkjitLBSveG7+xwFT4gCMgI1S2eJcFE/rmgmLYI9iqoUkp5uO/eSZQBi12Qa EIHKIPwp1eioSdrtPqZTuqLaPripJ+ewhveL126aXFVsKToskk9HaFRQr0TzMac= =Ojll -END PGP SIGNATURE- ___ 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: Replacing BIND with unbound (Was: Re: Pull in upstream before 9.1 code freeze?)
On 07/09/2012 06:33, Jonathan McKeown wrote: On Monday 09 July 2012 09:34:34 Avleen Vig wrote: The issue is also one of barrier-to-entry. By removing `dig` and `host`, I think we're making things unnecessarily more difficult for people who don't *know* FreeBSD. `dig` and `host` a universally standard tools for doing DNS lookups. Taking them away in base to replace them with something else just seems like something that won't really *help* users. Yes. So we should change the base system so that by default it does a database lookup whenever you type an unrecognised command - to lower the barrier to entry. Right. We should also change the base system to remove the most commonly used tools for doing DNS lookups, to what was the reason again? It's been covered at length in this thread. We get it, change is hard. Doug -- This .signature sanitized for your protection ___ 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: Replacing BIND with unbound (Was: Re: Pull in upstream before 9.1 code freeze?)
On 07/09/2012 06:45, Mark Blackman wrote: Indeed, 'dig' and 'host' must be present and working as expected in a minimally installed system. So if you don't like the versions that get imported, install bind-tools from ports. Doug -- This .signature sanitized for your protection ___ 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: Replacing BIND with unbound (Was: Re: Pull in upstream before 9.1 code freeze?)
On 07/07/2012 19:44, Warner Losh wrote: On Jul 7, 2012, at 5:33 PM, Garrett Wollman wrote: On Sat, 07 Jul 2012 16:17:53 -0700, Doug Barton do...@freebsd.org said: BIND in the base today comes with a full-featured local resolver configuration, which I'm confident that Dag-Erling can do for unbound (and which I would be glad to assist with if needed). Other than that, what integration are you concerned about? The utilities (specifically host(1) and dig(1)) are the only user-visible interfaces I care about. I don't see any need for there to be an authoritative name server in the base system. So long as the resolver works properly and does DNSsec validation The only reason I want it in the base system is that ports don't cross build very well, but the base system does. That's a weak +1 for keeping something in the base system, but I'll be the first to admit it is a second or third tier argument at best. With the proper ports infrastructure, this issue goes away. Meanwhile, we're already in basic agreement that importing unbound into the base is a good stopgap. Doug -- This .signature sanitized for your protection ___ 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: Replacing BIND with unbound (Was: Re: Pull in upstream before 9.1 code freeze?)
On 07/08/2012 01:03, Bjoern A. Zeeb wrote: On 8. Jul 2012, at 02:44 , Warner Losh wrote: On Jul 7, 2012, at 5:33 PM, Garrett Wollman wrote: On Sat, 07 Jul 2012 16:17:53 -0700, Doug Barton do...@freebsd.org said: BIND in the base today comes with a full-featured local resolver configuration, which I'm confident that Dag-Erling can do for unbound (and which I would be glad to assist with if needed). Other than that, what integration are you concerned about? The utilities (specifically host(1) and dig(1)) are the only user-visible interfaces I care about. I don't see any need for there to be an authoritative name server in the base system. So long as the resolver works properly and does DNSsec validation The only reason I want it in the base system is that ports don't cross build very well, but the base system does. That's a weak +1 for keeping something in the base system, but I'll be the first to admit it is a second or third tier argument at best. The real reason you want exactly these tools in base is that otherwise you end up rewriting tiny parts of freebsd-update etc that actually depend on host, etc. to query SRV for SRV records. That's an implementation issue, and is easily handled with drill, or the host-like program we all agree is a really-nice-to-have. -- This .signature sanitized for your protection ___ 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: Replacing BIND with unbound (Was: Re: Pull in upstream before 9.1 code freeze?)
On 07/08/2012 01:07, Bjoern A. Zeeb wrote: On 7. Jul 2012, at 23:45 , Doug Barton wrote: On 07/07/2012 16:34, Bjoern A. Zeeb wrote: On 7. Jul 2012, at 23:17 , Doug Barton wrote: Other than authoritative DNS, what features does unbound lack that you want? DNS64 as a start. Personally I would classify that as a highly-specialized request, and would point you to the bind* ports. I acknowledge that others may have a different view. Just to give you an idea - there are US nation-wide networks that depend on it these days. It's become an essential feature unfortunately. I didn't say it was unimportant, unused, or un-anything else. I said that we already have a solution for it, which doesn't need to stay in the base. In fact, no base BIND version supports DNS64 robustly. 9.8 (in 9-RELEASE) supports it weakly. If you have an enterprise network that relies on DNS64 you're infinitely better off with BIND 9.9, which hasn't been (and isn't likely to be) imported. Doug -- This .signature sanitized for your protection ___ 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: Replacing BIND with unbound (Was: Re: Pull in upstream before 9.1 code freeze?)
On 07/07/2012 17:35, Adam Vande More wrote: I am unclear on how this solves the main problem I think was stated about syncing up with release branches. I've already explained this at length in the past. ISC has changed both their release schedule and their policy regarding not allowing new features in a release branch. As a result, they release more frequently than we do, and EOL supported branches sooner than we do. Unbound has different policies and release schedules that are more in line with ours. So in the short term (as in, the next few years) we're better off with unbound in the base. The ideal, long-term solution is to re-think what The Base is, and give users more flexibility at install time. Unfortunately, there is a knee-jerk zomg, we don't want to be like linux! reaction to that idea which (to date) has prevented a rational discussion about it. I hope that changes. Doug -- This .signature sanitized for your protection ___ 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: Replacing BIND with unbound (Was: Re: Pull in upstream before 9.1 code freeze?)
On 07/07/2012 17:47, Darren Pilgrim wrote: On 2012-07-07 16:45, Doug Barton wrote: Also re DNSSEC integration in the base, I've stated before that I believe very strongly that any kind of hard-coding of trust anchors as part of the base resolver setup is a bad idea, and should not be done. We need to leverage the ports system for this so that we don't get stuck with a scenario where we have stale stuff in the base that is hard for users to upgrade. Considering the current root update cert bundle has a 20-year root CA and 5-year DNSSEC and email CAs, Neither of which has any relevance to the actual root zone ZSK, which could require an emergency roll tomorrow. I don't think it's unreasonable to maintain a copy of icannbundle.pem in the source tree Again, that has nothing to do with the actual ZSK, other than providing a way to validate the *existing* one. That's not the issue, at all. -- This .signature sanitized for your protection ___ 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: Replacing BIND with unbound (Was: Re: Pull in upstream before 9.1 code freeze?)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 On 07/08/2012 10:10, Jason Hellenthal wrote: From first impression it seems that drill(1) has a syntax that leaves something to be desired like the eased use of host or dig. So once again, if you need the exact capabilities of ISC host and dig, install them from the port. - -- This .signature sanitized for your protection -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.19 (FreeBSD) iQEcBAEBCAAGBQJP+f4rAAoJEFzGhvEaGryE7e0IAI9oluMoQ6anREfk6aMSGYG2 F8YrL0I/Tz9zid3AR7FEUexPygD5TUHMXF5Tsp2SanBowBx5pju2hslS7GyBuGTM A4mBmVxL3PtRmY/KW55/cIkyV5LPwDPWnul7E7YugQBNPOmAeGIeHwNeNjOLGdV4 Dy3TWnKM+42k9pENezSfeoD83g2Z9xnmAvE1SLOvnyzxMKbPnMmQZ5eikcb1U0WY sfubflPS2OXFgQb/6Qp3rgEpIvij2vBgSl7OJEwXsN01WqN+a7966tqWE4QwZFyD LE5FTijpyKXRpYeyqq/cpZBBdzPSQSi51YvWokF+X5hA/PlVhU8vqTDR+Rg/cLM= =9zzy -END PGP SIGNATURE- ___ 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: Replacing BIND with unbound (Was: Re: Pull in upstream before 9.1 code freeze?)
On 07/08/2012 10:43, Garrett Wollman wrote: On Sun, 08 Jul 2012 02:31:17 -0700, Doug Barton do...@freebsd.org said: Neither of which has any relevance to the actual root zone ZSK, which could require an emergency roll tomorrow. Surely that's why there's a separate KSK. The ZSK can be rolled at any time. The ZSK is rolled on a regular schedule already. But that's irrelevant to any future need to roll the KSK. -- This .signature sanitized for your protection ___ 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: Replacing BIND with unbound (Was: Re: Pull in upstream before 9.1 code freeze?)
On 07/08/2012 13:25, Gabor Kovesdan wrote: On 2012.07.08. 1:17, Doug Barton wrote: Other than authoritative DNS, what features does unbound lack that you want? [Picking up a random mail from the thread.] Other than the functionality, when we replace something, it is also important to do some benchmarks and assure that the performance is not reasonably worse. Agreed, and while I have no concerns in that regard, I leave the actual benchmarking in Dag-Erling's capable hands. :) -- This .signature sanitized for your protection ___ 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: Replacing BIND with unbound (Was: Re: Pull in upstream before 9.1 code freeze?)
On 07/08/2012 07:41, Dan Lukes wrote: The ideal, long-term solution is to re-think what The Base is, and give users more flexibility at install time. Flexibility is double-edged sword. Feel free to replace one resolver with another resolver (but don't do it so often, please). Applications can be patched to fit new API, scripts can be modified to use other command-line utilities. It is OK for me, as long as it is rare big bang. Sorry, you're not understanding what is being proposed. Specifically you're confusing the system stub resolver (the bit that's compiled into libc, and used by binaries) and the resolving name server (BIND). No one is proposing to replace the stub. I'm definitely not interested to make decisions like ... if I will select resolver A at install time, then utility X will not work correctly with them - it work with resolver B only, unfortunately, port P can't be compiled against resolver B because it's maintainer is using A only No one is suggesting anything similar to what you're concerned about. -- This .signature sanitized for your protection ___ 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: Replacing BIND with unbound (Was: Re: Pull in upstream before 9.1 code freeze?)
On 07/08/2012 22:43, Avleen Vig wrote: It would be silly not to keep bind-tools in base. Sounds easy, but not so much in practice. Keeping any of the code doesn't solve the problem of the release cycles not syncing up. And for the vast majority of users needs the tools we will import will be more than adequate. -- This .signature sanitized for your protection ___ 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
Replacing BIND with unbound (Was: Re: Pull in upstream before 9.1 code freeze?)
On 07/07/2012 14:16, Bjoern A. Zeeb wrote: On 3. Jul 2012, at 12:39 , Dag-Erling Smørgrav wrote: Doug Barton do...@freebsd.org writes: The correct solution to this problem is to remove BIND from the base altogether, but I have no energy for all the whinging that would happen if I tried (again) to do that. I don't think there will be as much whinging as you expect. Times have changed. I'm willing to import and maintain unbound (BSD-licensed validating, recursive, and caching DNS resolver) if you remove BIND. I'd object to it. Trading one for another without gaining anything does not help us much. Au contraire. It solves the problem of BIND release cycles not matching up with ours. This is a very important problem to solve. I've already written at length as to what I think the dream solution is, but we don't have anyone willing to code that yet, and even if we did, there is no guarantee that we'd get the buy-in to make it happen. In addition to being a good first step, doing this for DNS will also help us shake out the exact issues you allude to below. Don't get me wrong I have both running for years and even maintain patches for unbound for 2 years now for functionality they do not provide, which named happily gives me. Other than authoritative DNS, what features does unbound lack that you want? If you want to do this, I would prefer a properly laid out action plan as the import is by far the easiest but the integration into various parts of the system is harder. BIND in the base today comes with a full-featured local resolver configuration, which I'm confident that Dag-Erling can do for unbound (and which I would be glad to assist with if needed). Other than that, what integration are you concerned about? ... and just in case, these are sincere project requirement gathering questions, I'm not attempting to be snarky in any way. Doug -- This .signature sanitized for your protection ___ 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: Replacing BIND with unbound (Was: Re: Pull in upstream before 9.1 code freeze?)
On 07/07/2012 16:33, Garrett Wollman wrote: On Sat, 07 Jul 2012 16:17:53 -0700, Doug Barton do...@freebsd.org said: BIND in the base today comes with a full-featured local resolver configuration, which I'm confident that Dag-Erling can do for unbound (and which I would be glad to assist with if needed). Other than that, what integration are you concerned about? The utilities (specifically host(1) and dig(1)) are the only user-visible interfaces I care about. I don't see any need for there to be an authoritative name server in the base system. So long as the resolver works properly and does DNSsec validation I addressed the utils in a previous message, but once more ... ldns (a dependency of unbound) comes with drill, which is a dig-alike tool. I'd like to see us produce a host-alike based on ldns as well, which should be a pretty simple junior hacker task for a motivated group. If those don't do it for you, ports/dns/bind-tools already exists. Doug -- This .signature sanitized for your protection ___ 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: Replacing BIND with unbound (Was: Re: Pull in upstream before 9.1 code freeze?)
On 07/07/2012 16:34, Bjoern A. Zeeb wrote: On 7. Jul 2012, at 23:17 , Doug Barton wrote: On 07/07/2012 14:16, Bjoern A. Zeeb wrote: On 3. Jul 2012, at 12:39 , Dag-Erling Smørgrav wrote: Doug Barton do...@freebsd.org writes: The correct solution to this problem is to remove BIND from the base altogether, but I have no energy for all the whinging that would happen if I tried (again) to do that. I don't think there will be as much whinging as you expect. Times have changed. I'm willing to import and maintain unbound (BSD-licensed validating, recursive, and caching DNS resolver) if you remove BIND. I'd object to it. Trading one for another without gaining anything does not help us much. Au contraire. It solves the problem of BIND release cycles not matching up with ours. This is a very important problem to solve. Right and unbound et al are better? Bind at least gives us long term support releases these days. We just need to make sure we pick them for releases. I've already written at length as to what I think the dream solution is, but we don't have anyone willing to code that yet, and even if we did, there is no guarantee that we'd get the buy-in to make it happen. In addition to being a good first step, doing this for DNS will also help us shake out the exact issues you allude to below. Don't get me wrong I have both running for years and even maintain patches for unbound for 2 years now for functionality they do not provide, which named happily gives me. Other than authoritative DNS, what features does unbound lack that you want? DNS64 as a start. Personally I would classify that as a highly-specialized request, and would point you to the bind* ports. I acknowledge that others may have a different view. I don't care about the auth. support really with what is in base; it is nice that it comes for free and it is nice, that I'll not run into port 53 conflicts on single-IP systems but the only thing we really need is a caching resolver. It's good that we agree on that bit at least. If you want to do this, I would prefer a properly laid out action plan as the import is by far the easiest but the integration into various parts of the system is harder. BIND in the base today comes with a full-featured local resolver configuration, which I'm confident that Dag-Erling can do for unbound (and which I would be glad to assist with if needed). Other than that, what integration are you concerned about? startup scripts; Obviously that would be part of the import, and it should go without saying that I'm glad to help with that as well, if my help is needed. resolvconf, There is code in the rc.d/named script that handles this which can be copied pretty much verbatim (or possibly factored out into its own script). Other than that I'm not aware of any BIND integration for this. named.conf - unbound.conf guides for our users, ACK and not solving the issue that we really want a DNSSEC enabled caching resolver with libc APIs for applications to use DNSSEC in base that people are working on. We will probably need a crpyto and most likely also an external dnssec speaking resolver library for this in the future, but which of the 7 it will be we don't know yet. Yes, but that's a totally different issue. Also re DNSSEC integration in the base, I've stated before that I believe very strongly that any kind of hard-coding of trust anchors as part of the base resolver setup is a bad idea, and should not be done. We need to leverage the ports system for this so that we don't get stuck with a scenario where we have stale stuff in the base that is hard for users to upgrade. I have a POC for this for BIND that I need to finish, and I'm confident that something similar for unbound would not be difficult. Doug -- This .signature sanitized for your protection ___ 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/05/2012 01:28, Peter Jeremy wrote:
On 2012-Jul-05 09:22:25 +0200, Jonathan McKeown
j.mcke...@ru.ac.za wrote:
As for the idea that Linux refugees need extra help to migrate,
that's the sort of thinking that led to things like:
alias dir=ls
Whilst we're on the subject, can we please also have #define BEGIN
{ #define END } wired into gcc to help people migrating from Algol
and Pascal.
Um, this kind of elitist crap really isn't helpful.
If the new feature gets created, and you don't want to use it, turn it
off. No problem.
I appreciate the people who've spoken up as to why they wouldn't want
to use it, but I haven't seen anything yet that says having this
feature is a universally bad idea.
Doug
--
This .signature sanitized for your protection
___
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/04/2012 10:01, Freddie Cash wrote: On Wed, Jul 4, 2012 at 9:51 AM, Simon L. B. Nielsen si...@freebsd.org wrote: On Tue, Jul 3, 2012 at 9:39 PM, Doug Barton do...@freebsd.org wrote: On 07/03/2012 05:39, Dag-Erling Smørgrav wrote: Doug Barton do...@freebsd.org writes: The correct solution to this problem is to remove BIND from the base altogether, but I have no energy for all the whinging that would happen if I tried (again) to do that. I don't think there will be as much whinging as you expect. Times have changed. I'm willing to import and maintain unbound (BSD-licensed validating, recursive, and caching DNS resolver) if you remove BIND. You've got a deal! Unbound requires ldns, which is a good thing. Part of this project would How's the security support for ldns / unbound? For third party software sitting in the 'frontline' that part is rather important. Other than my followup where I expressed total confidence in the folks that produce these tools, I'll leave the advocacy to Dag-Erling. also be to enable drill so that we have a command-line dns lookup tool in the base, but that's trivial once you've got ldns imported. Does that means loosing host(1) ? Yes! Code must be free!11 :) That would be somewhat annoying. Again, see my followup. There's a version of host based on unbound. At least, there's an unbound-host package for Debian Linux: Yes, it's a SMOP. If we produced a BSDL version I'm fairly sure the NLnet Labs guys would be interested. Dag-Erling probably wants to contact them first to see if they are already working on something similar. Doug -- This .signature sanitized for your protection ___ 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/04/2012 11:51, Jason Hellenthal wrote: What would be really nice here is a command wrapper hooked into the shell so that when you type a command and it does not exist it presents you with a question for suggestions to install somewhat like Fedora has done. I would also like to see this feature, which is pretty much universal in linux at this point. It's very handy. I look forward to reviewing your patches to implement it. :) Doug -- This .signature sanitized for your protection ___ 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/04/2012 14:55, Brett Glass wrote: At 06:39 AM 7/3/2012, Dag-Erling Smørgrav wrote: I'm willing to import and maintain unbound (BSD-licensed validating, recursive, and caching DNS resolver) if you remove BIND. I've been using djb, and -- despite its quirks -- I'm very happy with it. Completely aside from its quirks, djbdns is wholly unsuitable in the modern DNS world due to it's poor and/or total lack of support for IDNs and DNSSEC. I'd like to have the option of installing dnscache, with the so-called Jumbo patch, as the default resolver. As soon as you start talking about with/without $option you are talking about a ports install, which is perfectly fine. Other than that, if whoever actually pushes all the rocks uphill to make the installer more modular in this regard decides to include djbdns, more power to them. :) Doug -- This .signature sanitized for your protection ___ 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/04/2012 15:01, Mike Meyer wrote: On Wed, 04 Jul 2012 14:19:38 -0700 Doug Barton do...@freebsd.org wrote: On 07/04/2012 11:51, Jason Hellenthal wrote: What would be really nice here is a command wrapper hooked into the shell so that when you type a command and it does not exist it presents you with a question for suggestions to install somewhat like Fedora has done. I would also like to see this feature, which is pretty much universal in linux at this point. It's very handy. I, on the other hand, count it as one of the many features of Linux that make me use FreeBSD. First, I agree that being able to turn it off should be possible. But I can't help being curious ... why would you *not* want a feature that tells you what to install if you type a command that doesn't exist on the system? Doug -- This .signature sanitized for your protection ___ 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/04/2012 15:55, Jason Hellenthal wrote: Seeing as sudo plays a big part of this No ... not only is sudo not a necessary component, it shouldn't be involved at all. The feature works on debian/ubuntu for regular userspace commands. Doug -- This .signature sanitized for your protection ___ 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
install-prompt for missing features (Was: Re: Pull in upstream before 9.1 code freeze?)
On 07/04/2012 15:57, Yuri wrote: On 07/04/2012 15:08, Doug Barton wrote: First, I agree that being able to turn it off should be possible. But I can't help being curious ... why would you *not* want a feature that tells you what to install if you type a command that doesn't exist on the system? Given the potentially controversial nature of this feature, it's maybe best to almost completely isolate it from the base system and make it into a port. Normally I would agree, but something like this would be *really* valuable to ease the transition for people coming from a Linux background. -- This .signature sanitized for your protection ___ 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: install-prompt for missing features (Was: Re: Pull in upstream before 9.1 code freeze?)
On 07/04/2012 16:41, Jason Hellenthal wrote: On Wed, Jul 04, 2012 at 03:59:29PM -0700, Doug Barton wrote: On 07/04/2012 15:55, Jason Hellenthal wrote: Seeing as sudo plays a big part of this No ... not only is sudo not a necessary component, it shouldn't be involved at all. The feature works on debian/ubuntu for regular userspace commands. What are they using to authenticate for the install ? do you know ? Perhaps I misunderstood what you meant. Certainly you'd need proper permissions for installing something. What I meant was that the concept of prompting for uninstalled stuff does not, and should not require sudo to be involved in any way. Doug -- This .signature sanitized for your protection ___ 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: Better error messages for command not found (was Re: Pull in upstream before 9.1 code freeze?)
On 07/04/2012 17:30, Tim Kientzle wrote: On Jul 4, 2012, at 4:41 PM, Jason Hellenthal wrote: On Wed, Jul 04, 2012 at 03:59:29PM -0700, Doug Barton wrote: On 07/04/2012 15:55, Jason Hellenthal wrote: Seeing as sudo plays a big part of this No ... not only is sudo not a necessary component, it shouldn't be involved at all. The feature works on debian/ubuntu for regular userspace commands. What are they using to authenticate for the install ? do you know ? Huh? What install? Who's talking about install? The version of this I've seen looks like this: $ svn co https://some.url/ svn: Command not found. To use this command, install one of the following packages: devel/subversion devel/subversion-freebsd devel/subversion16 That's all it does: It just prints out a more informative error message. It does not install anything, it requires no special permissions, and does not (as far as I can see) introduce any security or performance problems. The implementation is pretty simple: * A tool for building a database that maps command names to package names. (This would run against a ports tree or package repository. Conceptually, it's pretty similar to how port/package indexes get built today.) * Some way to distribute that database (Probably as part of ISO releases, maybe extend 'portsnap' or 'pkg_add' to update it?) * A program to look up command names in that database and print out the results. * A shell hook to run said program whenever a command not found error occurs. As a first prototype, the database could just be a text file and the look up program could be a shell script that uses grep and sed. Right-O. The db should almost certainly be updated and distributed as part of the (already automated) INDEX generation and distribution process. Doug -- This .signature sanitized for your protection ___ 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/04/2012 21:08, Brett Glass wrote: At 04:03 PM 7/4/2012, Doug Barton wrote: Other than that, if whoever actually pushes all the rocks uphill to make the installer more modular in this regard decides to include djbdns, more power to them. :) I'm not suggesting that everyone will prefer djb, and the last thing I want to do is start a religious war regarding the merits of different resolvers or the efficacy of DNSSEC. I'm merely asking that any change to the base system or the installation procedure allow me to choose this or any of the other most popular resolvers, at install time, with as little pain as possible. And as usual, your patches to implement that feature are eagerly anticipated. -- This .signature sanitized for your protection ___ 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/02/2012 19:08, Robert Simmons wrote: Are there plans to pull the following into head before the code freeze for 9.1? BIND 9.9.1p1 We never change the version of BIND in a release branch. The 9.8 version that's there is up to date. The correct solution to this problem is to remove BIND from the base altogether, but I have no energy for all the whinging that would happen if I tried (again) to do that. Doug -- This .signature sanitized for your protection ___ 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/03/2012 05:39, Dag-Erling Smørgrav wrote: Doug Barton do...@freebsd.org writes: The correct solution to this problem is to remove BIND from the base altogether, but I have no energy for all the whinging that would happen if I tried (again) to do that. I don't think there will be as much whinging as you expect. Times have changed. I'm willing to import and maintain unbound (BSD-licensed validating, recursive, and caching DNS resolver) if you remove BIND. You've got a deal! Unbound requires ldns, which is a good thing. Part of this project would also be to enable drill so that we have a command-line dns lookup tool in the base, but that's trivial once you've got ldns imported. After you get those 3 elements in the base I'm happy to pull BIND out by the roots. Doug -- This .signature sanitized for your protection ___ 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/03/2012 06:36, Mark Felder wrote: On Tue, 03 Jul 2012 07:39:34 -0500, Dag-Erling Smørgrav d...@des.no wrote: I don't think there will be as much whinging as you expect. Times have changed. Agreed; if we need DNS in base (really, why?) then unbound+nsd are prime candidates, but they're healthily maintained in ports...soo... no real advantage. We should not put nsd in the base. There is no need for an authoritative server in the base, the only reason BIND is there is that it is also a resolver, and, of course, hysterical raisins. The dream scenario is one we've discussed in the past: 1. Promote certain ports to system status, with more stringent requirements for both the ports, and the maintainers. 2. Re-tool the installer to give the users choice of which (if any) of the key system components get installed. Obvious choices for this category are the perennial favorites of DNS (resolver) and mail, reasonable arguments can be made for others of course. Whether we do the above or not, ldns/drill should be imported into the base so that we have at least one command line DNS resolution tool. A good junior hacker project would be to make a host(1) clone using ldns. If users want the regular bind tools, ports/dns/bind-tools already exists. Given it's unlikely that actually making the installer more modular will happen before 10-RELEASE, importing unbound is the next best alternative. And regarding the it's a young project issue, I've followed their development closely, I know the people involved, and I've used it for some projects. I have zero hesitation. And for those who are unclear on the problem we're trying to solve, a quick recap. As things have evolved over time the BIND release cycles and ours have diverged. Since we don't update the version of BIND in the base for POLA reasons, for FreeBSD 6, and now 7, this has led to a situation where our oldest release has an unsupported version of BIND. Clearly this is unacceptable. Oh, and to anticipate the traditional zomg! don't turn freebsd into linux!!!11!!! response: First, just because linux does something doesn't make it wrong, and Second, we can definitely add a *little* more modularity (which the users have been asking for as long as I can remember) without turning into linux. And finally, to address the why have a resolver on the system at all? question, one word: DNSSEC. At this time there is no good solution to the problem of the local host system being able to validate a DNSSEC response. The only viable solution _at this time_ is to have a local, validating resolver. (Of course, other solutions are being worked on, but they aren't here yet.) This will become much more important over time as DNSSEC adoption increases, and more things begin to use it (like DANE). Doug -- This .signature sanitized for your protection ___ 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: Browsing over IPv6
On 07/02/2012 04:12, George Mitchell wrote: I've been using IPv6 for quite a few years without problems and I've had no difficulty browsing Many more sites are actually putting, or have put, IPv6 into production since the latest world IPv6 day last month. Some growing pains are inevitable. Doug -- This .signature sanitized for your protection ___ 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: PORTS_MODULES in src.conf: make: don't know how to make instclean. Stop
On 07/02/2012 09:25, Benjamin Kaduk wrote: On Mon, 2 Jul 2012, David Wolfskill wrote: Huh??!? At least as far back as 06 Jan (based on the mtime of /etc/src.conf), I had set up src.conf to read: PORTS_MODULES=x11/nvidia-driver Don't do that. PORTS_MODULES is documented to belong in make.conf, not src.conf. It works fine in src.conf. Please point to the documentation you speak of so that it can be fixed. That said, dougb has tweaked the behavior of PORTS_MODULES recently Yes, this is my mistake, I'll fix it. -- This .signature sanitized for your protection ___ 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: PORTS_MODULES in src.conf: make: don't know how to make instclean. Stop
The problem is fixed now. This time I tested build and install with the same code. :( Sorry for the breakage, Doug -- This .signature sanitized for your protection ___ 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: PORTS_MODULES in src.conf: make: don't know how to make instclean. Stop
On 07/02/2012 13:41, Benjamin Kaduk wrote: On Mon, 2 Jul 2012, Doug Barton wrote: On 07/02/2012 09:25, Benjamin Kaduk wrote: On Mon, 2 Jul 2012, David Wolfskill wrote: Huh??!? At least as far back as 06 Jan (based on the mtime of /etc/src.conf), I had set up src.conf to read: PORTS_MODULES=x11/nvidia-driver Don't do that. PORTS_MODULES is documented to belong in make.conf, not src.conf. It works fine in src.conf. Please point to the documentation you speak of so that it can be fixed. PORTS_MODULES is listed in make.conf.5, and is not listed in src.conf.5. I see. That's a side effect of the wacky way in which src.conf.5 is built, combined with the fact that no one has yet migrated the things in make.conf.5 that predated the creation of src.conf altogether. There are numerous other examples, including KERNCONF and MODULES_OVERRIDE that I have in my src.conf just off the top of my head. Fixing this would be a great task for a doc person who wanted to get more exposure to src stuff. :) From src.conf: The only purpose of src.conf is to control the compilation of the FreeBSD source code, which is usually located in /usr/src. This would seem to not include Ports code (which is usually located in /usr/ports). I think the first usually is the one that is more relevant. However, that sentence is badly phrased to start with. It should probably say something like, The /etc/src.conf file is used for make options that are exclusive to the build process for the base OS. Since PORTS_MODULES falls into that category (even though the code lives in ports, it's part of the base build process), it qualifies. Also, and much more importantly, putting it in src.conf actually works, which you probably should have checked first before commenting. :) I'm pretty sure it's come up in the past that src.conf should only be used for those build options explicitly documented in it, and not other settings Unfortunately, there has been confusion on this point in the past, I agree. However it's important to note that the documentation is not necessarily the final appeal to authority, since we wrote the documentation, and we get it wrong sometimes. :) Doug -- This .signature sanitized for your protection ___ 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: Replacing rc(8) (Was: FreeBSD Boot Times)
On 06/21/2012 05:28 AM, Peter Jeremy wrote: 32.0s - rc scripts (mounting root through VTY login prompt) I think that there is some confusion about what I wrote originally, so let me clarify. From the time that /etc/rc starts through the time that the prompt appears almost all of the time is spent waiting for the services to start. There is very little time spent IN the rc scripts themselves (barring something that is poorly written of course). It's also worth noting that because the time spent in this phase is heavily dependent on what services you're starting, different people are going to have vastly different experiences. So the only way to improve the time from /etc/rc to usable system (whatever that means for the user) is to see what we can parallelize. The problem is that this is a really hard problem. :) And as someone pointed out, changing from a serial to a parallel process is going to be disruptive because it will uncover the inadequately specified dependencies that we have now which are hidden by the serial process ... and that's just the base. The over 800 rc.d scripts in the ports are (sadly) more wrong than right when it comes to specifying their rcorder stuff. This is mostly a holdover from the old days when the local scripts were all run in the same spot regardless of what was in PROVIDE/REQUIRE. Ever since I brought the local scripts into the overall rcorder (over 6 years ago now) we've been refining this, but dealing with this issue has to be something that is carefully considered in the planning for any proposed modifications. Personally, if we were going to undergo the amount of work it would take to handle parallelization of the existing rc.d framework; I'd rather put that work into designing and building a better system that does other things we need in addition to booting faster. To that end I like the direction that the thread is going in terms of discussing what a new system should have. I have some thoughts about that, but I'd like to let others talk for a while first. 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: Replacing rc(8) (Was: FreeBSD Boot Times)
I was working on a reply along similar lines, but instead I'll say that i agree 100% with what Mark said, and thanks to him for saving me a lot of time. :) Richard, with all that said if you still are interested in specs for a test program, I'm still willing to help with that. Just let me know. Doug On 06/20/2012 12:39 AM, Mark Linimon wrote: On Tue, Jun 19, 2012 at 06:45:13PM -0400, Richard Yao wrote: That is already done in Gentoo FreeBSD, or do you want me to do the work for you to integrate OpenRC in the base system? We want you to do the work to prove that it is an improvement. Otherwise it's just another claim. You seem to be missing a couple of principles here, the most important of which is first, do no harm. FreeBSD has as one of its underlying principles not to violate POLA (Principle Of Least Astonishment.) The corollary is that we don't replace code unless we're convinced (not just told) that the replacement is a better solution. If this makes FreeBSD more conservative than the way other OSes do things, so be it. I'm not trying to be harsh here. What I'm saying is that the burden of proof is on the person making the claims it's better to demonstrate that it's so. Otherwise, there are a zillion PRs with patches already in the database for committers to pick up and work on. I already have OpenRC in Gentoo FreeBSD. Taking the time to integrate OpenRC into FreeBSD would be an inefficient use of my time. Not only would I fail to gain any improvements on my systems, but I would divert development time from things that do benefit me. Then I expect the situation to remain unchanged. fwiw, from previous discussions on FreeBSD boot time, ISTR that there are other places where more time is spent. Some analysis to prove that indeed the rc subsystem is the dominant term would be a good starting place. 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
Re: Replacing rc(8) (Was: FreeBSD Boot Times)
On 6/18/2012 9:39 PM, Wojciech Puchar wrote: The latter item is the only place where making changes to rc.d is going to help, and only then by parellelizing, and even then you are not really going to gain much since most things at boot time are serial. grep sleep /etc/rc.d/* usr/local/etc/rc.d/* Sleeps in /etc tend to be there for good reasons, and new ones are vigorously scrutinized. If you see any that you think are dubious, feel free to mention them on freebsd-rc@. In the ports' scripts we tend to be more forgiving, but I've worked with several maintainers to apply more effective solutions where there is a good reason to wait for a dependent service to actually be running. This also brings up a good point, any new rc-alike solution we consider must have support for scripts in ports that is at least as robust as what we have now. Doug -- This .signature sanitized for your protection ___ 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: Replacing rc(8) (Was: FreeBSD Boot Times)
On 6/18/2012 4:05 PM, Richard Yao wrote: Doug, we already have OpenRC implemented. You can install Gentoo FreeBSD in a jail, install regular FreeBSD in another jail and do your own performance comparisons. Bt! Thanks for playing. :) You're the one proposing the change, YOU get to do the performance comparisons. If you want a rough idea of what I personally would consider to be a robust test, don't hesitate to ask. I'm sure others would have ideas as well. Doug -- This .signature sanitized for your protection ___ 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: Replacing rc(8) (Was: FreeBSD Boot Times)
It's unfortunate that this thread evolved into a discussion about replacing rc.d, since that's almost certainly not relevant to the original topic of improving the overall boot time. If you analyze the boot process thoroughly you should see that out of the total time taken to boot, nearly 0 is spent by rc.d actually doing something. Almost all of the actual time is spent waiting for other stuff, either the kernel (primarily) or the services that the system is running actually starting up. The latter item is the only place where making changes to rc.d is going to help, and only then by parellelizing, and even then you are not really going to gain much since most things at boot time are serial. So while talk of how to get your favorite boot-time manager into FreeBSD may be entertaining, it's not likely to be productive, and almost certainly isn't going to help the goal of actually making the boot time faster. But, I'm willing to be proven wrong by someone who actually _implements_ one of these systems and can demonstrate, in a statistically rigorous fashion, how much the boot time is improved. 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: mergemaster bug?
On 06/15/2012 11:37, rank1see...@gmail.com wrote: *** The following files exist in /etc/rc.d but not in /var/tmp/temproot/etc/rc.d/: sshd man src.conf, and search for SSH. You have one of those options defined in your environment. Doug -- This .signature sanitized for your protection ___ 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: boot menu option to disable graphics mode
On 06/13/2012 06:50 AM, Andriy Gapon wrote: on 09/06/2012 19:17 Doug Barton said the following: If this were a problem we didn't already have a solution for, I'd be much more interested in what you're proposing. I wonder if you were in the same mindset when you worked on service(8). This is not to doubt service(8) usefulness, of course. Just drawing a parallel. But in no particular order ... 1. This is not something most users would have to do very often, if at all. 1. Let's not generalize. In order to make intelligent decisions about what changes to include and what changes to exclude we have to measure both the costs, and the benefits. Part of measuring the latter is knowing how many of our users will benefit from the proposed change. The percentage of desktop users that we have is (regrettably) a very small percentage of our total demographic. The percentage of those users who would benefit from this proposed change is smaller still. OTOH, every single FreeBSD user is affected by changes to the boot process. Furthermore, we already have a non-trivial public perception that FreeBSD is a hobbyist OS, by and for the developers first and foremost. I don't want to do anything that contributes to that perception without good reason. 2. It is not a coincidence that I started this thread on this mailing list. I get that. But changes we make to the boot process aren't restricted to the members of this mailing list. 2. We have a variety of different login managers, several of which do things subtly differently, all of which would need ongoing support. The solution as proposed of now does not require any support or modifications. Which solution are you discussing? Marcin's? I think his idea has a lot of merit, but in reference to your particular use case (inhibiting X from starting) it requires the user to know which particular knob (or knobs) is responsible. That's not necessarily a show-stopper, and people who are likely to need this are likely to be able to figure that out. If you're talking about a different proposed solution, please clarify. If people would be willing to implement additional support, then probably they would be doing that because they would want to have that, and to support that. The latter bit is what I'm most concerned about, especially long term. 3. While the changes you're proposing sound simple, the startup stuff has some subtle interactions that we don't like to disrupt without good reason. This is too vague to comment. That doesn't make the point invalid. :) If we have a specific solution that people are excited about, with patches, I'm happy to give it a more detailed review (along with freebsd-rc@ of course). It's also worth pointing out that if all you need is a shell at boot time, you can still do Ctrl-Alt-F1 to get that, without having to change anything. Thank you for opening my eyes. And sorry for using sarcasm again. FWIW I realize that *you* know that already. What I'm trying to do is to get an idea of what people want to accomplish, and make sure that we're not reinventing the wheel. No, that's not what I want. I want X to not start. Thanks for clarifying. And if you find yourself needing to prevent the login manager from starting more often than not, just disable it by default and start it with 'service blah onestart', or use startx. I do need it that often that I'd have to inconvenience each boot. But I also want convenience those time when I need it. My point being that this doesn't come with zero costs, and has very little benefit. That usually spells no in my book. I understand your point. On the other hand, I find the proposed change to have measurable benefit and insignificant cost. This is yes in my book. I think that we disagree on both the relative costs and the relative benefits. That's why I wanted to express my concerns so that others could weigh in. Please also note that I am not asking you to do any work. That sounds great in theory. However given the amount of time that I've spent on refining the boot process, as well as trying to get the boot time down as low as possible; and given the overwhelming importance of the boot process to the OS generally, I have concerns about what you're proposing. Just to be clear, I'm not saying, NO!, I'm saying that if we're going to make changes in this area that we need to understand the landscape very well before we move forward. My other concern, to be perfectly blunt, is that this project not become something where changes are made, and then when users report problems with those changes they are told that they are on their own to come up with the debugging, analysis, and/or fixes for those problems. If you're saying that resources exist to support the design, implementation, testing, commit to HEAD, support in HEAD, MFC(s), and support in the older branches; then I'm glad to hear that. If we don't have those resources, that's a factor we
Re: boot menu option to disable graphics mode
On 06/07/2012 11:10, Andriy Gapon wrote: on 07/06/2012 17:29 Doug Barton said the following: On 06/07/2012 02:57 AM, Gleb Kurtsou wrote: What do you think about adding generic support for overriding *_enable options in rc.conf? I'd like to be able to disable services at boot prompt, e.g. # set rc.slim_enable=no -- overrides slim_enable=yes in rc.conf Similarly rc.pf_enable=no Then introduce x_enable knob (=yes by default) to disable login managers. User will be able to override this setting with # service xdm forcestart Why not just: boot single user fsck -p mount -a $EDITOR /etc/rc.conf[.local] Ah, right. Why provide a way to do something using one command at one prompt (or even toggling a menu option using a single keystroke) when you can already do the same using multiple commands at multiple places (and also trying to not forget to undo your changes later)... I realize you were being sarcastic, but your question deserves an answer. If this were a problem we didn't already have a solution for, I'd be much more interested in what you're proposing. But in no particular order ... 1. This is not something most users would have to do very often, if at all. 2. We have a variety of different login managers, several of which do things subtly differently, all of which would need ongoing support. 3. While the changes you're proposing sound simple, the startup stuff has some subtle interactions that we don't like to disrupt without good reason. It's also worth pointing out that if all you need is a shell at boot time, you can still do Ctrl-Alt-F1 to get that, without having to change anything. And if you find yourself needing to prevent the login manager from starting more often than not, just disable it by default and start it with 'service blah onestart', or use startx. My point being that this doesn't come with zero costs, and has very little benefit. That usually spells no in my book. Doug -- This .signature sanitized for your protection ___ 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: boot menu option to disable graphics mode
On 06/07/2012 02:57 AM, Gleb Kurtsou wrote: What do you think about adding generic support for overriding *_enable options in rc.conf? I'd like to be able to disable services at boot prompt, e.g. # set rc.slim_enable=no -- overrides slim_enable=yes in rc.conf Similarly rc.pf_enable=no Then introduce x_enable knob (=yes by default) to disable login managers. User will be able to override this setting with # service xdm forcestart Why not just: boot single user fsck -p mount -a $EDITOR /etc/rc.conf[.local] ___ 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: boot menu option to disable graphics mode
On 06/07/2012 08:12 AM, Garrett Cooper wrote: I've run into _multiple_ scenarios where this isn't possible because the terminal settings are screwed up in single user mode, and had to resort to `sed -i '' `. If that happens, a) report it! SUM is a very important part of FreeBSD, and it needs to always work. b) There were problems after the cons25 - xterm conversion that have almost all been fixed nowadays c) Try using a simpler shell, like /bin/sh, or even /rescue/sh d) Obviously don't try to do SUM with a shell that is not compiled static hth, 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: Ways to promote FreeBSD?
As someone pointed out when this thread started, it's off-topic for hackers. Please take it to advocacy. -- It's always a long day; 86400 doesn't fit into a short. Breadth of IT experience, and depth of knowledge in the DNS. Yours for the right price. :) http://SupersetSolutions.com/ ___ 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: Forgotten debuging flags in 9.0 RELEASE
On 4/25/2012 7:55 AM, rank1see...@gmail.com wrote: Well, those can be left in place, if they are part of STDOUT, as I leave only STDERR to reach my eyes. And I see exactly those 2 'ln -s ...' lines because they are outputed to STDERR. Right, I have the same issue with mergemaster ever since I redirected stdout from 'make distribution' to /dev/null. John is correct that I simply copied the existing example, my assumption at the time was that 'set -x' there was a cheap way to get some kind of output to let the user know what was being done (similar to what make does by default). I will test a patch to change that to echo'ing something useful to stdout instead unless anyone has an objection. Don't expect the result soon though, super, super, super busy with work/life/etc. atm. And as John pointed out, it's been there for a while. :) Doug -- This .signature sanitized for your protection ___ 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: GSoC: EFI on intel
Eric McCorkle writes: | I'm assessing possible summer of code projects, and the EFI work caught | my attention. I've been running FreeBSD on a macbook for a little under | a year now, and booting on EFI is definitely an interest to me. Does | anyone know if this is still a viable project proposal? I certainly | have the skills to undertake it, I just want to make sure that it stands | a chance of actually being selected. EFI is a good task. For generic PC's we need an X64 format. The current version in FreeBSD is IA32 format. The X64 can boot i386/amd64. Qemu can be used to test both IA32 and X64 formats. I added some notes about this on the wiki at: http://wiki.freebsd.org/IdeasPage#EFI_support_for_FreeBSD.2BAC8-i386_and_FreeBSD.2BAC8-amd64_.28GSoC.29 Qemu is nice since it can runs an UEFI BIOS via the OVMF project and emulate a DOS file system by pointing qemu to a directory. So then it is easy to build something, toss it into a directory, start qemu and test. Thanks, Doug A. ___ 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: Please help me diagnose this crazy VMWare/FreeBSD 8.x crash
On 4/2/2012 3:59 PM, Joe Greco wrote: On 4/2/2012 11:43 AM, Joe Greco wrote: As a user, you can't win. If you don't report a problem, you get criticized. If you report a problem but can't figure out how to reproduce it, you get criticized. If you can reproduce it but you don't submit a workaround, you get criticized. If you submit a workaround but you don't submit a patch, you get criticized. If you submit a patch but it's not in the preferred format, you get criticized. I'm still not sure what you're taking as criticism. Nothing I've said was intended that way, nor should it be read that way. If you feel that you've been criticized by others in the manner you describe, you should probably take it up with them on an individual basis. It certainly seemed to me that As much as I'm sensitive to your production requirements, realistically it's not likely that you'll get a helpful result without testing a newer version. 8.2 came out over a year ago, many many things have changed since then. was an unwarranted criticism for reasons that I've already explained. Everything in that paragraph is a fact. If you feel criticized when people state facts, I'm not sure how much I can help you. Please note, I didn't say, You're an idiot for running old stuff. I even explicitly stated that I understood *why* the OP is running an old version. Nevertheless, the facts are what they are. The only way we can deal rationally with the world is to acknowledge reality and deal with it. Wishing it were otherwise isn't really useful. :) Or perhaps this: And since you can't reliably reproduce the problem, how do you expect us to? I understand that these sorts of bugs are difficult/annoying, etc. Been there, done that. Which would appear to be suggesting that either (or possibly both): 1) The reporter has a duty to be able to reliably reproduce the problem prior to reporting, and/or 2) That there was some unreasonable expectation on the reporter's part that you were expected to reproduce it. Quite the contrary, I was responding to your implication that there is some other answer that we should be able to give the OP, other than Try a newer version. Various people have chimed in on the thread, all have offered suggestions, none of which (AFAICS) have helped. I continue to maintain that the best course of action for the OP would be to try the latest 8-stable. And BTW, there are (at least) 2 reasons for that. First, the bug may actually be fixed. But second, we're in the middle of a release cycle for 8.3 right now. If the bug persists in the latest code it will be easier to get the right eyes onto the problem. That benefits both the OP and the community at large. 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: GSoC: EFI on intel
Eric McCorkle writes: | On 04/03/12 13:22, Doug Ambrisko wrote: | EFI is a good task. For generic PC's we need an X64 format. The current | version in FreeBSD is IA32 format. The X64 can boot i386/amd64. | Qemu can be used to test both IA32 and X64 formats. I added some | notes about this on the wiki at: | http://wiki.freebsd.org/IdeasPage#EFI_support_for_FreeBSD.2BAC8-i386_and_FreeBSD.2BAC8-amd64_.28GSoC.29 | | Qemu is nice since it can runs an UEFI BIOS via the OVMF project | and emulate a DOS file system by pointing qemu to a directory. So | then it is easy to build something, toss it into a directory, start | qemu and test. | | I'm drafting an application right now. I emailed the listed contacts | (Rui Paulo and Andrey Elsukov) a moment ago. | | I've done background research on this already, as part of getting | FreeBSD to work on Mac hardware. QEMU caught my attention as a | testbed. Also, I found out Apple EFI implementations are non-standard. | They specifically look for an HFS+ partition and load a specific file. | The workaround is pretty simple, of course: just wrap the boot loader in | an HFS+ image and write it to a partition reserved for that purpose. | | Anyway, if I'm going to propose this, I need to list possible mentors. | Skill-wise, I'm well equipped to take it on. I anticipate needing | someone who's a committer, preferably with good knowledge of the kernel | sources. Both Rui and Andrey should be able to to fit your need for mentors. I can help with some stuff. It seems you've looked at the Mac side a fair amount. It might be good to look at X64 and IA64. Don't know how much can be shared. There is an efi loader in the tree for IA64. I've only played around with generic PC's (Dell, AMI based systems and qemu). I built grub and had grub boot via efi. Doug A. ___ 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: Please help me diagnose this crazy VMWare/FreeBSD 8.x crash
On 03/30/2012 07:41, Joe Greco wrote: On 3/29/2012 7:01 AM, Joe Greco wrote: On 3/28/2012 1:59 PM, Mark Felder wrote: FreeBSD 8-STABLE, 8.3, and 9.0 are untested As much as I'm sensitive to your production requirements, realistically it's not likely that you'll get a helpful result without testing a newer version. 8.2 came out over a year ago, many many things have changed since then. Doug So you're saying that he should have been using 8.3-RELEASE, then. That isn't what I said at all, sorry if I wasn't clear. The OP mentioned 9.0-RELEASE, and in the context of his message (which I snipped) he mentioned 8-stable. That's what I was referring to. And since both the poster and I made it clear that this doesn't seem to be a case of it fails reliably on a machine of your choosing, just installing random other versions and hoping that it's going to cause a fail ... well, let's just say that doesn't make a whole lot of sense. Or at least it's a recipe for a hell of a lot of busywork, busywork not guaranteed to return any sort of useful result. And since you can't reliably reproduce the problem, how do you expect us to? I understand that these sorts of bugs are difficult/annoying, etc. Been there, done that. In the meantime, it's unrealistic to tell people to use supported releases, to wait fifteen months between releases, and then to criticize people complaining about problems with a supported release for using old code. Just to be clear, I didn't criticize anyone. And I share your frustration with the length of the 8.3 release cycle. I really wish I had a better answer, but as much as you and I may wish that things were different, Try a newer version is the best answer we have atm. Doug -- This .signature sanitized for your protection ___ 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: Please help me diagnose this crazy VMWare/FreeBSD 8.x crash
On 4/2/2012 11:43 AM, Joe Greco wrote: As a user, you can't win. If you don't report a problem, you get criticized. If you report a problem but can't figure out how to reproduce it, you get criticized. If you can reproduce it but you don't submit a workaround, you get criticized. If you submit a workaround but you don't submit a patch, you get criticized. If you submit a patch but it's not in the preferred format, you get criticized. I'm still not sure what you're taking as criticism. Nothing I've said was intended that way, nor should it be read that way. If you feel that you've been criticized by others in the manner you describe, you should probably take it up with them on an individual basis. My experience of FreeBSD as a community is that we tend to be both less critical of users, and less tolerant of it. Especially when compared to other communities that I've interacted with. Doug -- This .signature sanitized for your protection ___ 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: Please help me diagnose this crazy VMWare/FreeBSD 8.x crash
On 3/28/2012 1:59 PM, Mark Felder wrote: FreeBSD 8-STABLE, 8.3, and 9.0 are untested As much as I'm sensitive to your production requirements, realistically it's not likely that you'll get a helpful result without testing a newer version. 8.2 came out over a year ago, many many things have changed since then. 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: Please help me diagnose this crazy VMWare/FreeBSD 8.x crash
On 3/29/2012 7:01 AM, Joe Greco wrote: On 3/28/2012 1:59 PM, Mark Felder wrote: FreeBSD 8-STABLE, 8.3, and 9.0 are untested As much as I'm sensitive to your production requirements, realistically it's not likely that you'll get a helpful result without testing a newer version. 8.2 came out over a year ago, many many things have changed since then. Doug So you're saying that he should have been using 8.3-RELEASE, then. That isn't what I said at all, sorry if I wasn't clear. The OP mentioned 9.0-RELEASE, and in the context of his message (which I snipped) he mentioned 8-stable. That's what I was referring to. If you'll kindly go over to http://www.freebsd.org and look under Latest Releases, please note that 8.2 is a production release. If you don't want it to be a production release, then find a way to make it so, but please don't snipe at people who are using the code that the FreeBSD project has indicated is a current production offering. There are many good reasons not to run arbitrary snapshots on your production gear. It's unrealistic to expect people to run non- RELEASE non-production code on their production gear. We can have that discussion if you don't understand that, drop me a note off- list and I'll be happy to explain it. I can see that you're upset about something, sorry if my message caused you additional stress. I actually understand the realities of production environments quite well, and believe it or not I agree with some of your frustration about how we handle support for our supported releases. We've had various public threads about these issues, which have sparked some quite-lively private discussions amongst our committers, and I'm hoping that once the long-overdue 8.3-RELEASE is out we'll be able to buckle down and start putting some of those ideas into action. Meanwhile, this is still a volunteer project, and as a result sometimes the best way to get attention to a problem is to verify that it hasn't already been fixed. You've been around more than long enough to understand this Joe. We can spend time arguing about what *should* be (actually we can't ...) but my point was in trying to help the OP get the most/best help the fastest way possible. 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: Strong host model in IPv6?
On 3/9/2012 7:02 AM, Alex Yong wrote: I've been playing around with IPv6 networking on FreeBSD release 8.2 and found that there seems to be no strong incoming host model as specified in RFC 1122. First, you're infinitely more likely to get a useful response if you send your message to freebsd-net@. Second, according to https://tools.ietf.org/html/rfc1122 that RFC has been updated quite a bit over the last 23 years. Have you followed that chain upwards to make sure that your concerns are still valid? Doug -- This .signature sanitized for your protection ___ 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: [PREVIEW] bsdconfig(8)
On 3/5/2012 8:24 PM, Devin Teske wrote: On Mar 5, 2012, at 6:20 PM, Andrzej Tobola wrote: On Mon, Mar 05, 2012 at 04:44:53PM -0800, Devin Teske wrote: INSTRUCTIONS: 1. cd /usr/src cd /usr/src/usr.sbin ? Sorry… /usr/src/usr.bin You don't need to be root to run it, so it's going into /usr/bin, not sbin. That's not the dividing line, please read hier(7). This should be introduced as a port in /usr/local/sbin to start with, and then we'll see how it goes from there. 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: BUG: 9.0 stage 2 boot (/boot/boot)
On 03/02/2012 08:52, John Baldwin wrote: On Thursday, March 01, 2012 5:23:11 pm Doug Barton wrote: On 3/1/2012 1:14 PM, John Baldwin wrote: My firefox on my BSD desktop was caching the image. Holding down Shift when clicking reload usually handles this. Only if you already know that FF is incorrectly caching the image. :( True'ish (since incorrectly depends on a lot of details that are outside the scope of this thread) but isn't it always a safe assumption that browsers are doing something other than what we want in order to help us? :) -- This .signature sanitized for your protection ___ 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: [patch] Disable bios probe if acpi is enabled
Sean Bruno writes: | I'm noting that newer machines are completely hosed if we attempt to | probe for bios values. I'm proposing this change. | | -bash-4.2$ p4 diff -du //depot/yahoo/ybsd_7/src/sys/i386/i386/bios.c | --- //depot/yahoo/ybsd_7/src/sys/i386/i386/bios.c 2011-09-16 | 22:47:30.0 | +++ /home/seanbru/ybsd_7/src/sys/i386/i386/bios.c 2011-09-16 | 22:47:30.0 | @@ -84,6 +84,12 @@ | char *p; | | /* | + * Don't do bios probing if acpi is enabled, its | + * pointless and breaks on newer systems | + */ | +if (!resource_disabled(acpi, 0)) | + return; | +/* | * BIOS32 Service Directory, PCI BIOS | */ | That seems reasonable to me. Doug A. ___ 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: BUG: 9.0 stage 2 boot (/boot/boot)
On 3/1/2012 1:14 PM, John Baldwin wrote: My firefox on my BSD desktop was caching the image. Holding down Shift when clicking reload usually handles this. hth, Doug -- It's always a long day; 86400 doesn't fit into a short. Breadth of IT experience, and depth of knowledge in the DNS. Yours for the right price. :) http://SupersetSolutions.com/ ___ 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: PostgreSQL benchmarks (now with Linux numbers)
On 02/23/2012 05:22, John Baldwin wrote: On Wednesday, February 22, 2012 9:59:02 pm Doug Barton wrote: On 02/22/2012 01:42, Ivan Voras wrote: The Dragonfly team has recently liberated their VM from the giant lock and there are some interesting benchmarks comparing it to FreeBSD 9 and a derivative of RedHat Enterprise Linux: http://leaf.dragonflybsd.org/mailarchive/kernel/2011-11/msg8.html Other developments are described in their release notes: http://www.dragonflybsd.org/release30/ The 4.5 times improvement by enabling kern.ipc.shm_use_phys is pretty notable, what prevents us from enabling that by default? It makes all your SYSV SHMs wired. That's fine if you are running a dedicated server using SYSV SHMs where you want that process to use all the RAM in the machine (e.g. a pgqsl server). It's not so great for a general purpose load where you would like an otherwise-idle process using SYSV SHMs to have the SHMs paged out to swap if other processes on the machine need memory and the box is under memory pressure. I see, thanks for that explanation. Doug -- It's always a long day; 86400 doesn't fit into a short. Breadth of IT experience, and depth of knowledge in the DNS. Yours for the right price. :) http://SupersetSolutions.com/ ___ 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: PostgreSQL benchmarks (now with Linux numbers)
On 02/22/2012 01:42, Ivan Voras wrote: The Dragonfly team has recently liberated their VM from the giant lock and there are some interesting benchmarks comparing it to FreeBSD 9 and a derivative of RedHat Enterprise Linux: http://leaf.dragonflybsd.org/mailarchive/kernel/2011-11/msg8.html Other developments are described in their release notes: http://www.dragonflybsd.org/release30/ The 4.5 times improvement by enabling kern.ipc.shm_use_phys is pretty notable, what prevents us from enabling that by default? Doug -- It's always a long day; 86400 doesn't fit into a short. Breadth of IT experience, and depth of knowledge in the DNS. Yours for the right price. :) http://SupersetSolutions.com/ ___ 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: 8 to 9: Kernel modularization -- did it change?
On 02/21/2012 02:49, Tom Evans wrote: On Mon, Feb 20, 2012 at 9:10 PM, Doug Barton do...@freebsd.org wrote: On 02/20/2012 06:44, Tom Evans wrote: Whatever happened to POLA? This change surprised me, wasn't mentioned in /usr/src/UPDATING, You're supposed to compare your existing kernel config to the new GENERIC every time you do a major version upgrade. That would have made the change quite obvious. Dumb stupid user - great argument Doug. Umm ... I didn't call anyone dumb, stupid, or any other names. It's been the common practice for major version upgrades since day 1. The whole reason we bump the major number is so that we can make changes that are incompatible with the previous major version. As I am just a dumb stupid user, all I looked at were the kernel release notes for 9: http://www.freebsd.org/releases/9.0R/relnotes-detailed.html#KERNEL Where none of this is mentioned. At all. I have nothing to do with the release notes, you should talk to hrs@ if you find them deficient. OTOH, some things are so fundamental that I can see how it wouldn't occur to him to include the detailed procedure in the release notes. Meanwhile, one could argue that this topic should be mentioned in more detail in the handbook. Feel free to create a PR for this and if no one else gets to it, I will. Doug -- It's always a long day; 86400 doesn't fit into a short. Breadth of IT experience, and depth of knowledge in the DNS. Yours for the right price. :) http://SupersetSolutions.com/ ___ 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: 8 to 9: Kernel modularization -- did it change?
On 02/20/2012 08:54, Alex Goncharov wrote: ,--- You/Tom (Mon, 20 Feb 2012 14:44:09 +) * | On Sat, Feb 18, 2012 at 1:14 AM, Doug Barton do...@freebsd.org wrote: | Because loading modules through loader.conf is | veeryy slooww I added an rc.d script called | kld that will load the specified modules after disks are mounted. This | is at least an order of magnitude faster. | Come off it, loading modules from loader.conf takes seconds off disk, | out of the 2+ minute total boot up. In my testing, which I posted around the time that I wrote and added the kld script, each module takes a second or two from the boot loader, whereas the 5 modules I load routinely take less than a second in total. | There may be benefit on slow | media, but in the general case I see no benefit (which might explain | why not many people are bothering to change their working configs to | save 2s on bootup). So don't make the change. I don't really care how much time you want to waste while your system boots. :) Seconded. As many have noticed, the veeryy slooww and order of magnitude faster claim has not been supported by empirical evidence in this discussion. That's because I already posted it a long time ago, and it's been confirmed by others on many occasions. Short version, the mechanism used by the loader to pull the bits off the disk is *always* going to be slower than reading them from the booted disk. I understand that you guys are new to this topic, so I'm happy to give you time to catch up, test it for yourself, etc. If instead of .002 sec the module loading takes .02, It's closer to 1.5 seconds per module, on average. nobody cares. And here's where you're making the biggest mistake. You're assuming that the only use case that's important is the one that you're familiar with. This isn't even close to true. For embedded systems speeding up the boot is critical. It's also important for people who use FreeBSD systems to make money, where every second of downtime translates to dollars lost. The fact that one can spread configuration and initialization parameters across several non-hierarchically-related entities (rc.conf, loader.conf, device.hints) somewhat arbitrarily, seems not right to me. A) It's not arbitrary, and B) That's an emotional response to a technical topic. Take a step back and try to understand the system, and why it's designed the way it is, separate from your emotions about it. That will help you make better technical decisions. Personally, I don't care about winning 10 seconds on a boot So, don't use kld_list. It won't hurt *my* feelings one bit. :) Doug -- It's always a long day; 86400 doesn't fit into a short. Breadth of IT experience, and depth of knowledge in the DNS. Yours for the right price. :) http://SupersetSolutions.com/ ___ 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: 8 to 9: Kernel modularization -- did it change?
On 02/20/2012 06:44, Tom Evans wrote: wrt to sound drivers no longer being built as modules, I wonder why this change has been made. I don't recall a mass of people complaining that they couldn't load drivers, Then you haven't been paying attention. :) Whatever happened to POLA? This change surprised me, wasn't mentioned in /usr/src/UPDATING, You're supposed to compare your existing kernel config to the new GENERIC every time you do a major version upgrade. That would have made the change quite obvious. Doug -- It's always a long day; 86400 doesn't fit into a short. Breadth of IT experience, and depth of knowledge in the DNS. Yours for the right price. :) http://SupersetSolutions.com/ ___ 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: 8 to 9: Kernel modularization -- did it change?
On 02/20/2012 07:23, Patrick Powell wrote: Oooh! Ahhh! Just what I was looking for. l will extract this from 9 and put it on my system. Glad you like it. :) One thing though, you're actually better off updating to the latest -stable of whatever branch you're using, some work has gone into making the rcorder come out right for this. Much better than having to edit the loader.conf and/or having to create a rc.local script. -- It's always a long day; 86400 doesn't fit into a short. Breadth of IT experience, and depth of knowledge in the DNS. Yours for the right price. :) http://SupersetSolutions.com/ ___ 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: 8 to 9: Kernel modularization -- did it change?
On 02/19/2012 08:13, per...@pluto.rain.com wrote: Given the context of the thread, this: loading modules through loader.conf is veeryy slooww ... seemed to be an objection to modularizing the kernel. The only way you could come to that conclusion is if you didn't carefully read my post. -- It's always a long day; 86400 doesn't fit into a short. Breadth of IT experience, and depth of knowledge in the DNS. Yours for the right price. :) http://SupersetSolutions.com/ ___ 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: 8 to 9: Kernel modularization -- did it change?
On 02/18/2012 10:43, per...@pluto.rain.com wrote: Doug Barton do...@freebsd.org wrote: loading modules through loader.conf is veeryy slooww ... Is it noticeably slower to load (say) a 6MB kernel + 2MB of modules than to load an 8MB kernel? I don't know, that wasn't the problem I was trying to solve. If your question is, 6 + 2-in-loader-conf then I imagine that it would be about the same speed, maybe a little slower due to extra file open-read-close cycles. If it's 6 + 2-in-kld_list then I imagine it would be quite a bit faster than an 8 M kernel, but I look forward to the results of your testing. :) Doug -- It's always a long day; 86400 doesn't fit into a short. Breadth of IT experience, and depth of knowledge in the DNS. Yours for the right price. :) http://SupersetSolutions.com/ ___ 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
