Date: Wed, 13 Jun 2012 15:18:37 -0700 From: Doug Barton <dougb@FreeBSD.org> To: Andriy Gapon <avg@icyb.net.ua> Cc: freebsd-hackers@FreeBSD.org Subject: Re: boot menu option to disable graphics mode Message-ID: <4FD911BD.3090505@FreeBSD.org> In-Reply-To: <4FD89A8E.6070103@icyb.net.ua> References: <4FD05C16.9040905@FreeBSD.org> <20120607084738.GT85127@deviant.kiev.zoral.com.ua> <4FD06CD3.3080602@FreeBSD.org> <20120607095741.GA1361@reks> <4FD0BAC6.6000304@FreeBSD.org> <4FD0EEB1.10103@FreeBSD.org> <4FD37727.60705@FreeBSD.org> <4FD89A8E.6070103@icyb.net.ua>
next in thread | previous in thread | raw e-mail | index | archive | help
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 need to consider before moving forward. Doug
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?4FD911BD.3090505>