Developments
In this section the people, personalities and debates on the @fedora-devel mailing list are summarized.
Contributing Writer: Oisin Feeley
Removal of non-X Consoles (continued)
The furore over the future removal of text-mode consoles (see FWN#144 "Non-X System Consoles to be Removed"[1]) continued throughout the week. The original thread saw some support for the idea expressed[2] by Nicolas Mailhot on the basis that "[...] non-X-console input is a mess [...] font support has fossilized, and support for modern high resolution screens is severely lacking [...]" Nicholas was especially concerned[3] with the maintenance burden imposed by the text-mode console "[...] as someone who is an upstream maintainer for my language of some of the bits the console use[s]."
[1] https://fedoraproject.org/wiki/FWN/Issue143#Non-X.System.Consoles.to.be.Removed
[2] https://www.redhat.com/archives/fedora-devel-list/2008-September/msg01341.html
[3] https://www.redhat.com/archives/fedora-devel-list/2008-September/msg01347.html
Upon being pressed by Dominik Mierzejewski for evidence of a lack of proper maintenance Nicolas listed[4] a series of problems including the stagnation of the console layout database and the console font set. Dmitry Butskoy begged[5] to separate the concepts of "console" and "serial tty" and also for the retention of the text-mode console. Dominik promised to try to find a colleague to shoulder the maintenance burden but Nicolas had already given up[6] in disgust. In response elsewhere to Seth Vidal's argument that the text console did no harm and should be left alone Nicholas expanded[7] on the maintenance costs of "all sorts of packaging rules designed to avoid hitting console limitations and problems" and bugs filed because of the confusion caused by two text stacks.
[4] https://www.redhat.com/archives/fedora-devel-list/2008-September/msg01373.html
[5] https://www.redhat.com/archives/fedora-devel-list/2008-September/msg01381.html
[6] https://www.redhat.com/archives/fedora-devel-list/2008-September/msg01388.html
[7] https://www.redhat.com/archives/fedora-devel-list/2008-September/msg01396.html
Les Mikesell got to the heart of the problem when he asked[8] "I think I'm confused by the term 'non X consoles'. Is that something different than the native text mode you see before X starts?" He also recommended using FreeNX/NX instead of using the console. Nicolas responded[9] that there were "[...]two different things. A VT to which you can attach an X session, a serial port, a remote SSH, mingetty... and the software stack used to display locally the VT text and collect user input." Nicolas saw the "low-level VT bit" as fundamentally sound but the "current console software stack" as "rotten." Les sought[10] further clarification of this distinction between "[...] the low level part that works in character mode and expects some hardware to supply and render the fonts [...]" and "[...] software other than X that renders custom fonts[.]"
[8] https://www.redhat.com/archives/fedora-devel-list/2008-September/msg01353.html
[9] https://www.redhat.com/archives/fedora-devel-list/2008-September/msg01354.html
[10] https://www.redhat.com/archives/fedora-devel-list/2008-September/msg01422.html
Denis Leroy wondered[11] if there was "[...] an X-based mingetty replacement actually exists ? Something that's proven to be sufficiently fail-safe (will work even with half-broken X configurations and such?)" and although Nicolas did not know of one he speculated[12] "[...] as soon as much of the hardware pocking is moved from xorg to the kernel and X can be run as a normal user "X-based mingetty replacement" will be just running a x term fullscreen in an autoconfigured X instance. Of course one could theoretically write a much lighter solution using only freetype (cairo, pango?) and an xkb-config parser." Denis's concern seemed to be that often a Ctrl+Alt+F1 to mingetty was the only way to kill hanging desktop applications. Colin Walters suggested[13] making "[...] Ctrl-Alt-Backspace just break server grabs instead of killing the server (and of course fix the bugs in the apps that hang while holding a server grab)."
[11] https://www.redhat.com/archives/fedora-devel-list/2008-September/msg01401.html
[12] https://www.redhat.com/archives/fedora-devel-list/2008-September/msg01407.html
[13] https://www.redhat.com/archives/fedora-devel-list/2008-September/msg01366.html
There were multiple expressions of disapprobation often coupled with use cases. Some of these led Chris Snook to exclaim[14] "Unless I've missed something huge, virtual terminals aren't going away. What may or may not be going away is the x86 video BIOS text mode, to be replaced with a kernel framebuffer, which precludes the use of console fonts, which very few people ever mess with. The console itself will remain. Someone please correct me if I'm wrong." [[DaveAirlie|Dave Airlie] confirmed[15] this understanding and added "[...] vga text mode will not be enabled by default, you will need to pass nomodeset if you want to use vga text mode. Welcome to the 1990s." Alan Cox made[16] the correction that framebuffer console support fonts but that framebuffers did not work on all machines, screen reader technology and remote management cards.
[14] https://www.redhat.com/archives/fedora-devel-list/2008-September/msg01417.html
[15] https://www.redhat.com/archives/fedora-devel-list/2008-September/msg01445.html
[16] https://www.redhat.com/archives/fedora-devel-list/2008-September/msg01484.html
OpenVPN and resolv.conf
Ahmed Kamal asked[1] for help in scratching an itch and started a concise, meaty thread. His particular problem was that he wanted to overwrite /etc/resolv.conf with new DNS servers obtained over a vpn tunnel, this is apparently done automatically in "Windows".
[1] https://www.redhat.com/archives/fedora-devel-list/2008-September/msg01304.html
The suggestion to use NetworkManager was made by Paul Wouters and Dan Williams agreed[2] and added the explanation that it "[...] mediate[d] between services [including PPP, PPtP, DHCP, openvpn, and vpnc] that need to update your DNS information." The alternative is that each service needs to handle /etc/resolv.conf itself.
[2] https://www.redhat.com/archives/fedora-devel-list/2008-September/msg01313.html
The idea of a default caching daemon was floated[3] by Simo Sorce. As he envisioned it, the services/tools, such as OpenVPN, would "[...] tell the caching daemon which IP ranges and which domains their provided forwarders should be consulted for. All dynamic so that as soon as one daemon goes away, the caching DNS will notice and revert queries to the default DNS.} Nils Philippsen agreed[4] heartily and added that "[i]deally, it should be something which isn't restricted to class A/B/C like reverse DNS (seems to be), but which would route DNS requests based on arbitrary domain name or IP-range criteria to the desired name servers" and Paul Howarth provided[5] the further reason that changes to /etc/resolv.conf are often not picked up by processes. This latter point spawned a discussion on the demerits of the glibc stub resolver (which is too simplistic) and the consequent use of the deprecated gethostbyname in individual applications. Dan Williams recommended using lwresd (a stripped-down, caching-only nameserver available to clients which use the BIND 9 lightweight resolver library) or for more complex setups a local caching nameserver. Although Simo Sorce disagreed[6] with Dan that many applications were simply using gethostbyname he agreed that "[a] caching nameserver that can be instructed what to do when conditions change is what we really need."
[3] https://www.redhat.com/archives/fedora-devel-list/2008-September/msg01349.html
[4] https://www.redhat.com/archives/fedora-devel-list/2008-September/msg01485.html
[5] https://www.redhat.com/archives/fedora-devel-list/2008-September/msg01490.html
[6] https://www.redhat.com/archives/fedora-devel-list/2008-September/msg01632.html
Ahmed asked[7] whether dnsmasq or other daemons were able to "[direct] name resolution to specific servers according to IP ranges and/or domain names, with the option of adding/removing servers on the fly?" and Richard W.M. Jones[8] confirmed that this was indeed possible. Adam Tkac suggested[9] that this could be done with view statements in BIND and the gauntlet of how to do this for CIDR and domain names was thrown down[10] by Nils. A detailed sub-thread followed which indicated what while possible it was not pretty.
[7] https://www.redhat.com/archives/fedora-devel-list/2008-September/msg01498.html
[8] https://www.redhat.com/archives/fedora-devel-list/2008-September/msg01500.html
[9] https://www.redhat.com/archives/fedora-devel-list/2008-September/msg01508.html
[10] https://www.redhat.com/archives/fedora-devel-list/2008-September/msg01523.html
Adam Tkac shared[11] the information that his TODO list includes the addition of NetworkManager support to BIND and Simo Sorce explained [12] that nscd was not a solution for a local caching nameserver "[...] as not all type of queries can be fulfilled by the glibc interface. For example SRV/TXT records ... Also nscd is not smart enough to understand network condition and adapt it's behavior." Simo agreed that it would be nice if "[...] bind could consult different DNSs based 1) on the DNS name to be queried, and B) the reverse IP to be queried" so that on slow links only the necessary queries would be directed through the VPN.
[11] https://www.redhat.com/archives/fedora-devel-list/2008-September/msg01509.html
[12] https://www.redhat.com/archives/fedora-devel-list/2008-September/msg01510.html
Fedora 10 Feature Owner Request
John Poelstra requested[1] all those owning a Feature[2] to take some actions on their feature page so that the beta release notes and announcements are accurate. He provided a list of twenty one feature pages which "have not been updated since the Feature Freeze on 2008-09-11 and/or are not 100% complete."
Kevin Kofler was among those who had been watching the progress of OpenChange (see FWN#133 "Help Wanted: Samba4, Heimdahl, OpenChange"[3]) and noted[4] that due to the decision[5] of Andrew Bartlett to orphan the feature it needed a new owner if Fedora 11 was to offer OpenChange.
Another of the listed pages was that for the Echo icon theme and Luya Tshimbalanga asked if he should add a release note to the effect that echo was now the default. Rahul Sundaram confirmed that this would be helpful.
The Eclipse-3.4 (Ganymede) page was updated[6] by [JeffJohnston|Jeff Johnston]].
[1] https://www.redhat.com/archives/fedora-devel-list/2008-September/msg01471.html
[2] http://fedoraproject.org/wiki/Features/Policy/Definitions
[3] http://fedoraproject.org/wiki/FWN/Issue133#Help.Wanted:.Samba4.2C.Heimdahl.2C.OpenChange
[4] https://www.redhat.com/archives/fedora-devel-list/2008-September/msg01482.html
[5] https://www.redhat.com/archives/fedora-devel-list/2008-September/msg00522.html
[6] https://www.redhat.com/archives/fedora-devel-list/2008-September/msg01548.html
system-autodeath Becomes Reality
Seth Vidal announced[1] that he had implemented his previously discussed (FWN#140 "System Autodeath"[2]) idea to automatically remove networking capabilities from machines which lacked system updates. The intent is to prevent non-maintained machines from being exploited.
[1] https://www.redhat.com/archives/fedora-devel-list/2008-September/msg01716.html
[2] https://fedoraproject.org/wiki/FWN/Issue140#System.Autodeath
Seth implemented the concept as a daily cronjob which tests a configured "death date" against the current time. For the week leading up to the "death date" log messages warn that on the specific date the default route will be deleted. He requested feedback and improvements.
Matt Miller was content but suggested[3] beefing up the manpage with details of the consequences of removing the default route. Seth noted that he was happy to accept patches.
[3] https://www.redhat.com/archives/fedora-devel-list/2008-September/msg01779.html
A fraught note was introduced when Stephen Warren declared[4] that if this were a default then, in combination with the proposed textconsole removal (see this FWN#144 "Removal of non-X Consoles (continued)") and the modesetting changes[5], he was thinking about switching distros. Rahul Sundaram responded[6] that modesetting was going to be a feature of all distros soon and the conversation veered[7] into explaining that the replacement for RHGB, named "Plymouth" had a sane text-mode fallback for unsupported chipsets. As much of Stephen's angst was due to a perceived abandonment of those using non-Free drivers Rahul pointed out that the nouveau drivers might work. Richard Hughes listed[8] 2-D and xrandr as supported with kernel modesetting coming soon due to Maarten Maathuis's work. He warned: "Don't even try 3D yet. It does work, but only if the moon is waxing, and your pet cat is called Oliver."
[4] https://www.redhat.com/archives/fedora-devel-list/2008-September/msg01782.html
[5] http://fedoraproject.org/wiki/FWN/Issue143#Graphics.Modesetting.Changes
[6] https://www.redhat.com/archives/fedora-devel-list/2008-September/msg01783.html
[7] https://www.redhat.com/archives/fedora-devel-list/2008-September/msg01789.html
[8] https://www.redhat.com/archives/fedora-devel-list/2008-September/msg01802.html
Back on the main topic of the thread Seth stated[9] that system-autodeath was not intended to be part of the default install: "This is just a nicety for sysadmins or local-respin maintainers who would like to put a dropdead date on their releases." In response to Stephen's recollection Seth also stated[10] this point clearly. A general disagreement with the idea of exposing such a feature was expressed[11] by James Hubbard on the basis that the user should be forced to change a config file to prevent against accidental installation errors.
[9] https://www.redhat.com/archives/fedora-devel-list/2008-September/msg01784.html
[10] https://www.redhat.com/archives/fedora-devel-list/2008-September/msg01788.html
[11] https://www.redhat.com/archives/fedora-devel-list/2008-September/msg01850.html
Fedora Not "Free" Enough for GNU?
A long-running thread which was started[1] on 07-09-2008 by Michel Salim continues to attracted some heated discussion over the fact that Fedora is not recognized as a 100% Free software distribution by GNU although a derivative named "BLAG" (see also FWN#139[2]) is recognized as FLOSS.
[1] https://www.redhat.com/archives/fedora-devel-list/2008-September/msg00428.html
[2] http://fedoraproject.org/wiki/FWN/Issue139#Small.Machine.SIG
The central stumbling block seemed[3] to be best stated by Gregory Maxwell as "[...] Fedora doesn't yet strip the binary firmware provided by the Linux kernel (and still provides some re-distributable binary firmware in other packages, the microcode package and alsa-firmware I think)." Gregory described the situation as unfortunate due to both the lack "[...] of acknowledgement it deserves, and the FSF is indirectly promoting Ubuntu, a distribution which is, as far as I can tell, a primary driving factor in new users using and depending on proprietary software." This latter being a reference to the recognition of gNewSense as FLOSS.
[3] https://www.redhat.com/archives/fedora-devel-list/2008-September/msg00435.html
There had been previous very heated threads on this subject (during one of FWN's holidays) centered around the efforts of Alexandre Oliva to produce a "kernel-libre" and the interaction of this project with other efforts and approaches within the kernel community. David Woodhouse added[4] the excellent news that "We are almost at the point where we can do a spin which remedies [the difficulties of stripping out the non-Free firmware]." He explained that soon a completely separate package instead of a sub-package of the normal kernel build will allow others to produce alternative packages of firmwares for which source code is available. Tom Callaway was worried[5] that there was still firmware entangled in the kernel source code and noted the need for an audit. Rahul Sundaram supplied[6] a link to a Debian inventory of firmwares.
[4] https://www.redhat.com/archives/fedora-devel-list/2008-September/msg01603.html
[5] https://www.redhat.com/archives/fedora-devel-list/2008-September/msg01605.html
[6] https://www.redhat.com/archives/fedora-devel-list/2008-September/msg01606.html
Other interesting points in the discussion touched on the rationales which have been often advanced for refusing to supply source to firmwares. These involve regulatory compliance (often for radio devices). Alan Cox was suspicious of such arguments based[7] on the history of examples such as ISDN code which "[...] was approved. You could change it but then it became unapproved and not permitted in some countries." He described this as a racket run by the phone companies which imploded once the need to ensure robustness became important (due to terrorist threats.) Ignacio Vazquez-Abrams listed[8] some of the other rationales.
[7] https://www.redhat.com/archives/fedora-devel-list/2008-September/msg01745.html
[8] https://www.redhat.com/archives/fedora-devel-list/2008-September/msg01737.html