tag:blogger.com,1999:blog-14471576312203615192024-02-19T09:48:34.749+01:00knurdThorsten Leemhuishttp://www.blogger.com/profile/12285919704852601523noreply@blogger.comBlogger77125tag:blogger.com,1999:blog-1447157631220361519.post-16314819621410752482023-04-17T08:00:00.008+01:002023-04-17T20:25:28.708+01:00How would you change Fedora, if you became its supreme leader<h2 style="text-align: left;"></h2><p><b>TLDR:</b> If some magic wizard would make me Fedora's supreme ruler, I'd morph the release model into one similar to that of Firefox or the Linux kernel. I'd also dramatically increase relations to RPM Fusion, so that we together can finally make things easy and robust that Fedora itself can't or doesn't want to provide. And of course: immutable operating systems FTW!</p><p></p><h2 style="text-align: left;"><b>A thought experiment</b><br /></h2><p>Nearly 20 years ago I became interested in contributing to what just a few months later morphed into the Fedora Project. These became my first steps as an Open Source contributor. Despite this I managed to become <a href="https://gregdekspeaks.wordpress.com/2007/01/10/thorsten-leemhuis-fedora-legend/ ">a teeny tiny bit known</a> in the Fedora world and might even have influenced <a href="https://fedoraproject.org/wiki/User:Thl">a little</a>. My focus after some years shifted to the Linux kernel, but Fedora is still dear to my heart. Its upcoming anniversary hence made me wonder multiple times:</p><p><b>Would a modern version of my younger self start contributing to Fedora?</b></p><p>My brain always comes to a conclusion along these lines:<br /></p><p><b>That's highly unlikely, because today's Fedora Linux is kinda uncool and somewhat oldish!</b></p><p>Funnily enough at the same time something in my head yells: "Some of what makes Fedora Linux uncool and oldish is what helps making it so great! And you for sure don't want it to become yet another rolling release distro similar to 'cool' distros like Arch Linux and Tumbleweed!". Which lead me to a thought experiment of megalomania this blog post is about:<br /><br /><b>If I could dictate how Fedora Linux operates, what would I change to make it cool again while ensuring its stays great?</b><br /></p><div class="separator" style="clear: both; text-align: center;"><a href="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEjahx-1Ee6AGraUwx3ndAWOCcl5moR8F2OpIudDtr8JD9zl6wVydY9vw6sgJNS-j6Cbm_uUF9lgBr6FwmePx3GDJAI7ZVQMU6oRnaPPnzubZVpsgtrP4ZGDMGOjNCcLhxVSKbL6ppjC-gKb2m6FYAvOWlbExBk2IL4yMGGjtAzqLl0Z3scVWtmhamit/s834/Screenshot%20from%202023-04-15%2010-43-15.png" style="margin-left: 1em; margin-right: 1em;"><img border="0" data-original-height="416" data-original-width="834" height="229" src="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEjahx-1Ee6AGraUwx3ndAWOCcl5moR8F2OpIudDtr8JD9zl6wVydY9vw6sgJNS-j6Cbm_uUF9lgBr6FwmePx3GDJAI7ZVQMU6oRnaPPnzubZVpsgtrP4ZGDMGOjNCcLhxVSKbL6ppjC-gKb2m6FYAvOWlbExBk2IL4yMGGjtAzqLl0Z3scVWtmhamit/w458-h229/Screenshot%20from%202023-04-15%2010-43-15.png" width="458" /></a></div><h2 style="text-align: left;">What Thorsten as Fedora's ultimate leader would aim for </h2><p style="text-align: left;">Well, here are the two things that would be at the top of my todo list:</p><p style="text-align: left;">1. Switch to a <b>more modern release model</b> that better suites these times and serves mainly two goals:</p><p style="text-align: left;"> a) Have a <b>quick release pace with t</b><b>wo distro streams</b>. The first stream would target users that want fresh software relatively quickly, but don't want a rolling release distro. The second stream<b> </b>would target users which prefer software that (1) whenever possible went through a proper field test in Fedora's first stream and (2) withholds major changes whenever possible to one "jump" release per year.</p><p style="text-align: left;"> b) Make Fedora's devel streams <b>help upstream software developers</b> a lot more forging their future versions into shape: with more cooperation in this place we'll help each other tremendously and thus make FLOSS itself better.</p><p style="text-align: left;">2. Broadly increase the cooperation with external projects to <b>make things (a) simple and (b) robust</b> that many users want to do, but Fedora can not (for legal reasons) or does not want to (like software that is not FLOSS) provide.</p><p style="text-align: left;">So how to actually do this? Well, that requires separate sections to explain.</p><h2 style="text-align: left;">A modern release model</h2><p style="text-align: left;">Every few weeks a new release with new features and once a year one version becomes the base for a new LTS series that quickly supersedes the previous one – that's a modern development scheme that among others was made popular by Firefox.</p><p style="text-align: left;">I would make Fedora Linux follow that model on a distro level: it better suits the times, is more attractive, and has benefits for stabilizing the distro and the software it contains.</p><p style="text-align: left;"></p><div class="separator" style="clear: both; text-align: center;"><a href="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEgqgQzP85VXNHS0pETnkB44QR8SIA39AbJPlbGk3PkQH9vuEs-i5zpYnIvzcGzEONgOQdPbA7DoshUYMeb9twjtrFP9uVQst4mNbfmL41LC4uGdqASVrvtMziK3L9VvuxxePC-ebu2jUTZtU4wF_9vOxt6dhJm6qdWTwesWeQG_wJsedw_Q4KFh92ZD/s598/Screenshot%20from%202023-04-15%2012-23-22.png" style="margin-left: 1em; margin-right: 1em;"><img border="0" data-original-height="471" data-original-width="598" height="252" src="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEgqgQzP85VXNHS0pETnkB44QR8SIA39AbJPlbGk3PkQH9vuEs-i5zpYnIvzcGzEONgOQdPbA7DoshUYMeb9twjtrFP9uVQst4mNbfmL41LC4uGdqASVrvtMziK3L9VvuxxePC-ebu2jUTZtU4wF_9vOxt6dhJm6qdWTwesWeQG_wJsedw_Q4KFh92ZD/s320/Screenshot%20from%202023-04-15%2012-23-22.png" width="320" /></a></div><p></p><p style="text-align: left;">I already hear some of your yelling "this will lead to unreliable releases", "it requires too much resources", "this will never work", and many similar things. But people yelled such things when the Linux kernel and Firefox switched to this model, too. Now look at them: the quick pace with small steps turned out to be great for both users and developers. That's why I would make Fedora follow a similar scheme. <br /></p><p style="text-align: left;">How? Well, like this:</p><p style="text-align: left;">* Morph the current Fedora Linux into a "<b>Fedora Deft Linux</b>" (alternatively "Fedora Agile" – or maybe just continue calling it "Fedora Linux"). It would be similar to the Fedora Linux releases we have now, just with a much quicker release pace of *four* weeks. Each release immediately would immediately replace the previous one and rolled out like any other update -- just like Firefox 111 becomes EOL and is replaced by Firefox 112 when the latter is launched.</p><p style="text-align: left;">* Create a "<b>Fedora Steady</b>" (or "Fedora Linux Longterm") that follows the same release pace (just like Firefox ESR follows the same pace as Firefox). It normally would only bring new software versions that already have proven themselves at least one cycle in "Fedora Deft". Base software like anaconda, compilers and toolchains would only be updated once a year in a coordinated "jump release", where they are mass-synced/merged from a Fedora Deft release where they have proven themselves. The approach is similar to Firefox ESR and Linux longterm kernels. This stream would be the de facto successor for the "Fedora Linux <current version -1>" release (e.g. Fedora Linux 36 now and soon F37 once F38 is out).</p><p style="text-align: left;">Yes, this will require package maintainers to meddle sometimes, as we deal with thousands of upstreams that work at different paces and release schedules – and for some upstreams switching to a new release is the best or only sane way to address security issues. But the quick release pace would make this easier. And we deal with these sorts of problems in today's Fedora every day already, hence that meddling would not be much different in a "two Fedora streams" scheme.</p><p style="text-align: left;"></p><div class="separator" style="clear: both; text-align: center;"><a href="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEjFa3HxmhSwPuwX-JvioCm6r1eWLJrI2XQjrp_HC3V7w1du2SXluEU49gVSLiTrF9qPvSat4OEWUYHoRHRdgZRFtnVznzGG2_MyV0EV-qOYx0GKWXD7gsytvOBIvdL2nJc3J1aErOa3jk6Adxi5jB8u_pSYmAEc2zKBvhoos3HmhDnqnrciFBpcEkgG/s596/Screenshot%20from%202023-04-15%2012-25-23.png" style="margin-left: 1em; margin-right: 1em;"><img border="0" data-original-height="395" data-original-width="596" height="212" src="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEjFa3HxmhSwPuwX-JvioCm6r1eWLJrI2XQjrp_HC3V7w1du2SXluEU49gVSLiTrF9qPvSat4OEWUYHoRHRdgZRFtnVznzGG2_MyV0EV-qOYx0GKWXD7gsytvOBIvdL2nJc3J1aErOa3jk6Adxi5jB8u_pSYmAEc2zKBvhoos3HmhDnqnrciFBpcEkgG/s320/Screenshot%20from%202023-04-15%2012-25-23.png" width="320" /></a></div><br /> The new approach allows one crucial thing we don't do currently: <b>properly field-test a new version</b> (say when the Linux kernel jumps from the 6.1.y. to 6.2.y series) <b>in one stream first </b>(e.g. Deft) before users that fear unstable software get it as an update (e.g.Steady). That being said, there is one additional thing it'd do to reduce the friction between goal and reality:<p></p><p style="text-align: left;"> * <b>When upstream maintain regular and longterm branches</b> (e.g. Firefox vs Firefox ESR; Linux stable kernel vs longterm kernel; KDE regular vs KDE LTS; …), give users the <b>option to choose</b> which of they they want to use. Hence ship both of them in Deft and Steady; Deft by default would use the normal branch, Steady the longterm branch.</p><p style="text-align: left;">Both Deft and Steady of course would need updates-testing channels, just like the two current Fedora releases have one. Normally only security updates should come through here to the users, everything else should wait till the next release – no big deal, it's at max just 4 weeks away. But if upstream mixes security fixes and new features in new releases, they are fine as regular update first in Deft and a few days or a week later in Steady as well, as long as packagers ensured they got some testing in Fedora's devel streams beforehand – ideally while those releases were still in beta. Which brings me to another aspect:</p><p style="text-align: left;">New Fedora Deft releases of course would need to be prepared somewhere. This would be done in two addition development streams: <br /></p><p style="text-align: left;">* "<b>Fedora Devel</b>" would be the successor for Rawhide and regularly ship the latest versions -- and for somewhat reliable upstreams also pre-releases of software that is expected before the overnext Deft release. That for example would include Firefox Beta (which Fedora currently does not ship in Rawhide) or pre-releases of the next mainline kernel. But only when that software is meant to be stable enough for users that don't mind pre-releases or snapshots in beta quality – hence don't ship Firefox Nightly or Linux kernel merge window snapshots (which Rawhide currently ships) here . </p><p style="text-align: left;"> * A "<b>Fedora Pioneer</b>" stream at the start of a new Fedora Deft devel cycle would simply incorporate any changes from Fedora Devel, unless there are strong reasons to avoid some update. Then stabilize the upcoming stream over the following weeks until the next Fedora Deft is released. It's thus like a beta, but I would avoid that term, as it's too scary.</p><p style="text-align: left;"></p><div class="separator" style="clear: both; text-align: center;"><a href="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEiW3jUJBWW6J6IZPvrkvox3whUtaTbHnrBP3YjX3Fkf3fYSYvZuopha7bpuk7OnJKabmQ2piqy3W-5yFLEFdq8AbnVMjdjdM_guOVneC94M2iTUEe4n_kBGod-q1J9GaVMPV4tmcTJ5v9WvigHUX3Pah1IXabX7itxHrvi9yNav3sLck-V4qp_VA-R3/s754/Screenshot%20from%202023-04-15%2012-28-57.png" style="margin-left: 1em; margin-right: 1em;"><img border="0" data-original-height="754" data-original-width="726" height="320" src="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEiW3jUJBWW6J6IZPvrkvox3whUtaTbHnrBP3YjX3Fkf3fYSYvZuopha7bpuk7OnJKabmQ2piqy3W-5yFLEFdq8AbnVMjdjdM_guOVneC94M2iTUEe4n_kBGod-q1J9GaVMPV4tmcTJ5v9WvigHUX3Pah1IXabX7itxHrvi9yNav3sLck-V4qp_VA-R3/s320/Screenshot%20from%202023-04-15%2012-28-57.png" width="308" /></a></div><br /> This scheme would help upstream getting their software into shape for their next release, which benefits both Fedora and the whole world of FLOSS. To avoid big problems, normalize epochs: if a new upstream version turns out to be problematic, just revert to the older version and delay the switch to the newer upstream version by one Deft cycle, which is only four weeks away – no big deal. <br /><p></p><p style="text-align: left;">A new beta version of a software packaged in Fedora thus would go to Fedora devel; if it's considered good enough it at the start of the next cycle could move to Fedora Pioneer, where first the beta and later the final is tested and polished over the course of four weeks. From there the version would move to Fedora Deft, where it would be for four more weeks; this version or a later version would go to Fedora Steady, either right at that point or in Steady's yearly "jump release".</p><p style="text-align: left;">New versions of upstream software thus would reach Deft users within about four to eight weeks; everybody that wants it quicker would have to use Fedora Pioneer.</p><h2 style="text-align: left;">Make things simple and robust that Fedora does not provide</h2><p style="text-align: left;">Most users want their operating system to "just work": they don't care much if something requires patent encumbered software or proprietary drivers. And they don't care if it's Fedora or somebody else's fault, if something they want to do is hard to realize or breaks frequently on updates. They will simply switch to another Linux distribution that works better for them – and of course will never forget their bad experience with Fedora. </p><p style="text-align: left;">That's why<b> installing and using patent encumbered software or proprietary drivers needs to be easy and robust in Fedora </b>for the latter to be successful.</p><p style="text-align: left;">Those things currently are not easy and robust. The root of the problem is Fedora's stance on patent encumbered software and its tight focus on FLOSS. I'd definitely *not* change this, as it's right to draw these two lines. I'd do something else: <br /></p><p style="text-align: left;"><b>I'd made Fedora cooperate more with external projects that provide solutions for the things that Fedora can't or doesn't want to support.</b> Flatpak, Flathub, and Fedora's support for them already became quite good and is even getting better with Fedora 38. Hence it's mainly the interaction between the Fedora Project and <b>RPM Fusion</b> that I'd improve to make Fedora Linux better and more attractive. </p><p style="text-align: left;"></p><div class="separator" style="clear: both; text-align: center;"><a href="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEiP65Tutvf6qEEPD-c3r40RabKR4qrpBeU14O9j-L9Cx2eqAnv84mE2MbAbAMPuYmMGWs2OQNn3NfLl24-IqWfZRSLh6RQV3_N4ZkDbf-ejuBuXMnvDZAlLD8sFpGMa1BBlgcibqJWr2OFlKxVJFy1_JHNOWAi17QTUpDYvzR69X6YaTmRM6bSkdy43/s499/Screenshot%20from%202023-04-15%2011-43-52.png" style="margin-left: 1em; margin-right: 1em;"><img border="0" data-original-height="372" data-original-width="499" height="239" src="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEiP65Tutvf6qEEPD-c3r40RabKR4qrpBeU14O9j-L9Cx2eqAnv84mE2MbAbAMPuYmMGWs2OQNn3NfLl24-IqWfZRSLh6RQV3_N4ZkDbf-ejuBuXMnvDZAlLD8sFpGMa1BBlgcibqJWr2OFlKxVJFy1_JHNOWAi17QTUpDYvzR69X6YaTmRM6bSkdy43/s320/Screenshot%20from%202023-04-15%2011-43-52.png" width="320" /></a></div><br /> This is what I'd do:<p></p><p style="text-align: left;">- Make <b>enabling RPM Fusion</b> free or non-free something that users can do in<b> just one step</b> – ideally one that doesn't require a command line at all, but a "curl https://example.com/rpmfusion-free-install.sh | sudo bash" is fine, if anything else is impossible for legal reasons. </p><p style="text-align: left;">- When above "one step install" is performed, <b>automatically switch over all installed packages to their non-encumbered versions</b> from RPM Fusion (e.g. uninstall Fedora's ffmpeg-free and install ffmpeg – either directly or in an overlay on ostree-based Fedora variants). Additionally install additional software that would be in Fedora's default install if that was possible (possible candidates would be video players like Celluloid for Fedora Workstation or Vlc for the Fedora KDE Plasma Desktop Edition). Ideally it's something in dnf and rpm-ostree that would handle this, due to the related aspect raised in the next point.</p><p style="text-align: left;">- If some software is available in both Fedora and RPM Fusion, make dnf/rpmos-tree install the packages from the latter by default when the user installs them – e.g. when the user runs "dnf install audacity" a week after installing Fedora and enabling RPM Fusion, he should<b> by default get audacity-freeworld from there and *not* the audacity package from Fedora</b>. In similar scope, install typically used add-ons from RPM Fusion by default on package installation – e.g. when user runs "dnf install qmmp" dnf should automatically install qmmp-plugins-freeworld from RPM Fusion to complement Fedora's qmmp package. </p><p style="text-align: left;">- Better ensure that updates on the Fedora side <b>don't break</b> something for users that have related packages from RPM Fusion installed. For example ensure that a mesa update does not cause trouble for users that have mesa-va-driver-freeworld installed (something that recently happened every a few times <a href="https://bugzilla.redhat.com/show_bug.cgi?id=2161338">with to good solution in sight</a>).</p><p style="text-align: left;">- I'd make using <b>Nvidia's graphics drivers more robust</b>. Things got better in recent years, but there is still quite a bit of room for improvement. Shipping the latest longterm kernel as an option in Fedora (see the section about Fedora Deft and Steady above) would help here and allow users to avoid occasional breakage due to new Linux mainline releases only Nvidia can fix. But there is more that can be done – for example automatic fallback to nouveau if Nvidia's driver doesn't work (while telling users about it once the system booted so they can take action). Also: "akmods are fragile; it's a really ugly hack only meant for corner cases – e.g. users of rawhide or people that don't use Fedora's kernel" (these are the words of the original akmod author). Avoid the risks by shipping pre-compiled kernel-modules, which is very hard or impossible to do currently (side note: maybe Nvidia's new open source kernel driver will obsolete that problem, so maybe it's not worth spending too much time on – not sure).</p><div class="separator" style="clear: both; text-align: center;"><a href="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEh8dXXgIrjTpVF7wCxhuw0ZCrLZbfaIHgH2fNHK_cLkIhRZ9UrbteSJLtzfE-jYBKFven-ETmmWRZlFCpnsBBLYGWe8ZymifjrqgHJEcMSlmRscgPegSvABwFs1QyFGOSqBfsJnR4VrvwEAcIPHSsg6RyUx_lmrjYaPr7Y31zVBtjcmjSR91X2sVDgK/s602/Screenshot%20from%202023-04-15%2012-33-17.png" style="margin-left: 1em; margin-right: 1em;"><img border="0" data-original-height="343" data-original-width="602" height="182" src="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEh8dXXgIrjTpVF7wCxhuw0ZCrLZbfaIHgH2fNHK_cLkIhRZ9UrbteSJLtzfE-jYBKFven-ETmmWRZlFCpnsBBLYGWe8ZymifjrqgHJEcMSlmRscgPegSvABwFs1QyFGOSqBfsJnR4VrvwEAcIPHSsg6RyUx_lmrjYaPr7Y31zVBtjcmjSR91X2sVDgK/s320/Screenshot%20from%202023-04-15%2012-33-17.png" width="320" /></a></div><p style="text-align: left;"> - Related: when the user chose to use RPM Fusion non-free on a system with a nvidia gpu, make the install magic described in the first two points above also install Nvidia's driver -- but only semi-automatically, after telling the user about the risks of such drivers and showing them the drivers EULA. And it should likely suggest switching to the latest longterm kernel, too.</p><p style="text-align: left;">Obviously some of the work to realize this needs to be done on the Fedora side, some in RPM Fusion. But <b>the Fedora Project needs to drive all these changes</b> (or at least guide them) whenever legally possible, as if we like it or not: Fedora needs RPM Fusion (or something like it) to be appealing for many users. That's why doing this is even in the interest of Fedora's main sponsor, as it will ensure Fedora is relevant in the market and attracts a strong user base – which is needed for Fedora to fulfill the goal the main sponsor created Fedora for in the first place.</p><h2 style="text-align: left;">Closing words and more thoughts<br /></h2><p style="text-align: left;">Disclaimer: I know that this is not a good sales pitch; if I had wanted to make it one, I'd have asked others for feedback on the idea and this text before publishing this post. Maybe I should have done it. But I'm not that well known in the Fedora world any more, hence I guess this post won't have much of an impact anyway – and writing things down already took way more time than I wanted it to. At least it finally cleared my head, as the idea to write a blog post like this was circulating in my brain for a year or two already; the upcoming Fedora anniversary finally motivated me to sit down and type it in...</p><p style="text-align: left;">Believe it or not, there are quite a few other things on my mind that I wanted to write about, too. But doing that properly would have required even more time; and they are not as important to me as the two topics I wrote about above. But for completeness, here in very short form is what "Thorsten, the imagined Fedora despot" also would do:</p><p style="text-align: left;">- ensure continued or even intensified investment in the immutable concept (e.g. Silverblue, Toolbox, et al.)</p><p style="text-align: left;">- ensure continued or even intensified investment in supporting Flatpak and Flathub</p><p style="text-align: left;">- talk to other distros to make packaging easier for all of us: a lot of man-power is wasted because packagers on various distros do the same thing over and over again without much peer coordination</p><p style="text-align: left;">- ensure continued investment in making package building possible straight from git repositories</p><p style="text-align: left;">- increase coordination with other distros and upstreams to better handle and coordinate bug tracking – ideally by convincing upstreams to have downstream bug reports, so that users of say Debian, Fedora, or openSUSE will easily find reports a problem an Arch Linux user filed that happens on all distros</p><p style="text-align: left;">- tone down the "package ownership" thing a bit and make package a bit more a wikipedia style</p><p style="text-align: left;">- discourage patching upstream software in Fedora even more, to ensure packagers submit their changes upstream, unless there are very strong reason to carry a patch in Fedora</p><p style="text-align: left;"><b></b></p><div class="separator" style="clear: both; text-align: center;"><b><a href="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEgx2FsJBFUPuDuEzEVdVMfpu52pnByB6XMLuvgValu4accwDTuvS7vEkh1pfU_1boSRYhaOA0qxzP4rQSjhSADbBjarGb7ECDnvGkf15VGwjP_lVRG_3QMem1vpBOpJFLznzXqkpRKtxUoDHlk1LNsj5YLZ-6tE2vLqiqO95mUZ77koH8tW4uHL28_b/s379/Screenshot%20from%202023-04-15%2012-30-24.png" style="margin-left: 1em; margin-right: 1em;"><img border="0" data-original-height="219" data-original-width="379" height="185" src="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEgx2FsJBFUPuDuEzEVdVMfpu52pnByB6XMLuvgValu4accwDTuvS7vEkh1pfU_1boSRYhaOA0qxzP4rQSjhSADbBjarGb7ECDnvGkf15VGwjP_lVRG_3QMem1vpBOpJFLznzXqkpRKtxUoDHlk1LNsj5YLZ-6tE2vLqiqO95mUZ77koH8tW4uHL28_b/s320/Screenshot%20from%202023-04-15%2012-30-24.png" width="320" /></a></b></div><p>Ohh boy. This became quite a blog post. Sorry. Never meant to be that long, but I guess I nevertheless even forgot a thing or two.
Remember: This was written by someone that is not much active in
the Fedora world these days – and all just a "What would I do as supreme
ruler" thought experiment of megalomania. But even as a supreme ruler I'd not
immediately set out and realize my ideas – I'd first discuss and fine-tune them together with stakeholders and the community. </p><p><b>EOF</b></p><p>P.S.: feel free to add comments about this idea to <a href="https://social.linux.pizza/@knurd42/110213619550132131">my fediverse posting about this text</a>.</p><p></p>Thorsten Leemhuishttp://www.blogger.com/profile/12285919704852601523noreply@blogger.com0tag:blogger.com,1999:blog-1447157631220361519.post-45189087825441417322021-01-04T10:05:00.003+01:002023-04-17T08:15:35.089+01:00Package names can be false friends, too, as (linux|kernel)-headers show<p><i><b>TLDR</b></i>: The `kernel-headers` packages in Fedora, RHEL, or CentOS do not carry the files you get by installing `linux-headers-$(uname -r)` on Debian based distros. If you want to build add-on modules for the kernels in Fedora, RHEL, or CentOS, you need to install `kernel-devel` instead. Fun fact: I consider both approaches to package naming flawed.</p><h3 style="text-align: left;">False friends</h3><p>Packages in different, unrelated distros sometimes have similar names, but nevertheless contain something entirely different. People that don't keep this in mind are sometimes going to have a bad time. </p><p></p><div class="separator" style="clear: both; text-align: center;"><a href="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEhL92awWK5LGwEasFfBD8p6hNoa-TB03_-gYiqCynQrzN-Fygqp9JToU-RaMoBScN6HLI0Rkf0KHYyY2OM0-5EPAS2WSURO4Aoch4exUIILAvEKRxTi13kPqnIY4KbZ1GwEnpcwzuoYSEU/s500/4sh9w8.jpg" style="margin-left: 1em; margin-right: 1em;"><img border="0" data-original-height="499" data-original-width="500" src="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEhL92awWK5LGwEasFfBD8p6hNoa-TB03_-gYiqCynQrzN-Fygqp9JToU-RaMoBScN6HLI0Rkf0KHYyY2OM0-5EPAS2WSURO4Aoch4exUIILAvEKRxTi13kPqnIY4KbZ1GwEnpcwzuoYSEU/s320/4sh9w8.jpg" width="320" /></a></div>There is one area where this afaics causes trouble quite often: when building add-on modules for your distro's kernel. On Debian or Ubuntu quite a few people learned: before starting the compiler, one has to install additional files by running a command like `apt-get install linux-headers-$(uname -r)`. That's why it's easy to assume the `kernel-headers` package fulfils the same job in Fedora, RHEL, or CentOS. But it's a wrong assumption and will lead to failure, because `kernel-headers` packages in the RH-universe contains something totally different.<br /><p></p><br />The two package names are thus something like '<a href="https://en.wikipedia.org/wiki/False_friend">false friends</a>': they look or sound similar, but differ significantly in meaning.<br /><p></p><br /><div class="separator" style="clear: both; text-align: center;"><a href="https://en.wikipedia.org/wiki/False_friend" style="margin-left: 1em; margin-right: 1em;"><img border="0" data-original-height="813" data-original-width="1067" src="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEjA2cM8D2P9-Qcp_vmfAttt_fyDCIDUzNoKrlz6a5dkiPhN0n_FV7EYNA5oF8Pigqz18O8aFBGRIaiDkzjHlLkv7TgjC_9nOykmmzgFgu15zVY__wQbufn-a-cBTPz6Y9XQ32Oe3s9WL-E/s320/Bildschirmfoto+von+2020-12-28+06-34-12.png" width="320" /></a></div><p>You actually need to install a package called `kernel-devel` to build add-on modules for the kernel from Fedora, RHEL, or CentOS . They also ship a `kernel-headers` package, but don't bother with it, it's not directly needed.<br /></p><h3 style="text-align: left;">Neither package name is fully accurate</h3><p>You now might wonder, which of the two approaches in naming is corrent: `linux-headers-foo` or `kernel-devel`? The short answer from my point of view: neither, as both names are a bit off.<br /><br />To understand why, let's take a closer look at the Linux kernel – that what is being packaged here and thus should be a strong indicator of what's right or wrong. When looking at the sources you'll actually find something that is relevant in this context: a make target called `headers_install`. The help text describes it as 'Install sanitised kernel headers to INSTALL_HDR_PATH'.<br /></p><p>That doesn't tell much, so people familiar with `linux-headers` packages might quickly jump to conclusions like 'that will install the files needed for building add-on modules'. But that not the case, as the files installed by this target are something entirely different: the ```kernel headers for use by userspace```. They ```<i>[…] describe the API for user space programs attempting to use kernel services. These kernel header files are used by the system’s C library (such as glibc or uClibc) to define available system calls, as well as constants and structures to be used with these system calls. […]</i>```.<br /></p><p>Those quotes are from the Linux kernel documentation. To read them in full context head over to <a href="https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/plain/Documentation/kbuild/headers_install.rst">`Documentation/kbuild/headers_install.rst` in the Linux sources</a> or to <a href="https://www.kernel.org/doc/html/latest/kbuild/headers_install.html">its rendered version on kernel.org</a>.<br /></p><div class="separator" style="clear: both; text-align: center;"><a href="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEiiPy3xGBIls9huikGkC7SdZHeG0-sK8WxT-NR8abBarzhXWbG3jdOpPlMDvKjp6nyRYWxmk-CoLuyIhfb32yGGXS58nvJVfQSzunLbEvZOTCdogls_XwGcF8d4g0Nx9M2UfOrhgzcmihk/s1133/Bildschirmfoto+von+2020-12-29+14-01-52.png" style="margin-left: 1em; margin-right: 1em;"><img border="0" data-original-height="872" data-original-width="1133" src="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEiiPy3xGBIls9huikGkC7SdZHeG0-sK8WxT-NR8abBarzhXWbG3jdOpPlMDvKjp6nyRYWxmk-CoLuyIhfb32yGGXS58nvJVfQSzunLbEvZOTCdogls_XwGcF8d4g0Nx9M2UfOrhgzcmihk/s320/Bildschirmfoto+von+2020-12-29+14-01-52.png" width="320" /></a></div><p>The files installed by `make headers_install` are not really relevant when it comes to building kernel modules, but crucial in a totally different situation: when building your system's C library. That's why <a href="http://linuxfromscratch.org/lfs/view/development/chapter05/linux-headers.html">'Linux from Scratch (LFS)' installs them right before compiling the GNU C Library (glibc)</a>.<br /><br />The Debian-universe ships the files installed by `make headers_install` in a package called `linux-libc-dev`. The RH-universe on the other hand ships them in a package called `kernel-headers`. <br /></p><h3 style="text-align: left;">Missing link<br /></h3><p style="text-align: left;">So if `make headers_install` does not install the files needed for building add-on modules, what make target will install them? Thing is: the Linux kernel does not offer a make target to do just that. It never has.<br /><br />The concept of shipping all the files for building add-on modules originated in the distro world somewhere. I don't known when and where exactly. I first saw it in Fedora in its early days (2003? 2004?), when Arjan van de Veen was maintaining the Fedora kernel (IIRC). He simply made the RPM install section collect the files needed for building modules and shipped them in a new sub-package of the kernel package. The latter was and still is shipped in a package called `kernel` and the sub-package got the name `kernel-devel`. That's why you need to install this package when you want to build add-on modules.<br /><br />That approach followed a familiar pattern in the RH-universe, where development files are always in '-devel' sub-packages. It's thus totally normal for users to install `foo-devel` if they want to build something for or on top of a software shipped in a package named `foo`. It's not that different from the Debian-universe, which uses '-dev' instead.<br /></p><h3 style="text-align: left;">Choice of names<br /></h3><p style="text-align: left;">Other distros also started packaging the files to build add-on kernel modules, but chose other names for the sub-package. The Debian-universe, which ships the Linux kernel in a package called `linux`, settled on packages with the prefix `linux-headers`. I don't known how it came to this or if `linux-dev` was even considered. <br /><br />Is 'headers' an appropriate suffix, even if `make headers_install` installs something different? </p><p style="text-align: left;">Decide yourself. In Fedora 33 the kernel-devel package currently contains about 16.500 files. About 12.000 of them indeed are header files (their file names end with '.h'). Then there are a bit more than 4100 files called `Makefile` or `Kconfig`, which are needed for configuration and building. Then there are about 80 files containing C code and about 250 other files: some scripts (perl, python, coccinelle), more Kbuild stuff and a few other things. </p><p style="text-align: left;">In other words: there is a bit more than headers in there, but they dominate. Nevertheless I still think it wasn't the best idea to use `linux-headers` as prefix. That's mainly for two reasons: (1) a 'linux-dev' prefix would have been more in line with the approach used by other packages in the Debian-universe; (2) it's confusing users, as the kernel installs something different when running `make headers_install`. </p><p style="text-align: left;">But to be fair on the second point here: I did not dig down into the history books, but I strongly suspect the prefix `linux-headers` was chosen and established before `make headers_install` was introduced; that was in September 2006 with Linux 2.6.18.<br /><br />But in the end it doesn't matter if I find the term appropriate or not: in the Debian-universe the term `linux-headers` and the purpose of these packages is well established these days. Changing it is likely not worth the trouble. People just need to be made aware they need to install `kernel-devel` on Fedora, RHEL, and CentOS when they would install `linux-headers-$(uname -r)` on Debian, Ubuntu or distros based on them.</p><table align="center" cellpadding="0" cellspacing="0" class="tr-caption-container" style="margin-left: auto; margin-right: auto;"><tbody><tr><td style="text-align: center;"><a href="https://xkcd.com/1860/" style="margin-left: auto; margin-right: auto;"><img border="0" data-original-height="435" data-original-width="303" height="320" src="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEiIy3pcDyJT_ONwyi04aqEjS81iuB3dP1r3Kpl2x4Epghq_FJBED1V_R1H99NA8LBmEoLMgMhFg7bxXsE1HNGu9LOENCn0NgrxvKYubRNB-LeNSsrZUFzwXlTKp_aUOL3BFKyIgjPJ2Iso/s320/communicating.png" /></a></td></tr><tr><td class="tr-caption" style="text-align: center;"><a href="https://xkcd.com/1860/">xkcd/Randall Munroe, CC BY-NC 2.5</a></td></tr></tbody></table><h3 style="text-align: left;">Bonus feature: Fedora is wrong, too</h3><p style="text-align: left;">Earlier I mentioned that I consider both `linux-headers` and `kernel-devel` flawed, but only explained what's wrong with the former. Well, it's a bit nitpicking, but the problem with the package name used in the RH-universe is on the other side of the dash. Nobody in the RH-universe would put Firefox in a package `browser` or LibreOffice in a package called `officesuite`. But somehow a kernel named 'Linux' was put in a package called `kernel`.<br /><br />But whatever, fixing this would likely also create more trouble then it's worth. And it's only going to become a problem if Fedora ever decides to ship other kernels (like GNU Hurd or the FreeBSD kernel) in parallel to Linux (like Debian GNU/kfreeBSD).</p><h3 style="text-align: left;">Appendix A: Older headers are totally fine</h3><p>Fun
fact: the
packages `linux-libc-dev` or `kernel-headers` mentioned above (those that contain the files that `make headers_install` installs) sometimes look outdated in
Linux distributions, as they sometimes stay on a older version while way newer
kernels with higher version numbers get installed while updating the
system. Don't worry about it, as there is a reason for this. It's
actually explained in the kernel documentation file referred to above:<br /><br />```<i>Kernel
headers are backwards compatible, but not forwards compatible. This
means that a program built against a C library using older kernel
headers should run on a newer kernel (although it may not have access to
new features), but a program built against newer kernel headers may not
work on an older kernel.</i>```.<br /><br />In other words: don't update
`linux-libc-dev` or `kernel-headers` if you want to ensure code you
compile works on older Linux kernel versions. That for example might be the kernel
found on and installed by the installation ISO, which people will use
before they update their systems (which some users never do). But don't
worry too much about this aspect, for most software that won't matter
anyway.</p><h3 style="text-align: left;">Appendix B: Why did nobody upstream the concept behind `linux-headers`/`kernel-devel`?</h3><p style="text-align: left;">Still reading? Seems like you are really curios! Good, because I got something more for you.<br /><br />I explained `make headers_install` above and mentioned the Linux kernel has no make target to install the files that are shipped in packages like `linux-headers` and `kernel-devel`. I don't known why such a make target is missing upstream, but I suspect it's the usual: nobody set down to clean one approach up and submit it upstream (apart from that approach used by the `make bindeb-pkg` target).<br /><br />But it's IMHO clearly something that would be useful to have upstream: all big distro have packages like that and create it manually, which is error prone; having such a make target upstream would also be handy for people that compile and install their kernel locally, too.</p><p style="text-align: left;">I more than once considered upstreaming this functionally, but never found the time to do so. Or, to be more precise: I never found the motivation(™). ;-)<br /><br />For the foreseeable future that won't change. I hope someone else will pick this task up. How about you? I guess it would be a good learning exercise and shouldn't be too hard. Looks to me like you might not even have to know C to implement this! Knowing a bit or two about Makefiles might come in handy, but I guess even that is not needed for someone really motivated!</p><p style="text-align: left;"><i>Closing words: If you spot anything here that you consider false or misleading please let <a href="https://fedoraproject.org/wiki/User:Thl">me know</a>; especially when it is in one of those sections about the Debian-universe and its packaging, because that's not really my area of expertise. I'm happy to update this text to fix mistakes or provide additional details if they are important to know in this context.</i><br /></p>Thorsten Leemhuishttp://www.blogger.com/profile/12285919704852601523noreply@blogger.com0tag:blogger.com,1999:blog-1447157631220361519.post-16454096589339087542020-06-23T09:38:00.002+01:002020-06-23T12:08:16.279+01:00kcbench, the Linux kernel compile benchmark, version 0.9.0 is outHello, is this thing still on? Looks like I have not blogged here in nearly 10 years. Uhhps. But today there is a reason to write something again:<br />
<br />
I released <b>kcbench 0.9.0</b>. Kcbench is a simple <b>Linux kernel compile benchmark</b> that downloads the Linux sources and measures the time it takes to build the kernel. This is how it looks:<br />
<div class="separator" style="clear: both; text-align: center;">
<a href="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEjvozfdTckoaxtLKwi0_GHI_q0u8__IeDhzC5QggdfD0hvlyPIiRIvNh9mM2ZP3UqMPEBco56Go4EQpZ6bx8OfSgMauHjRHhV9aBCZMwyGP8paoZPc49r_v-dvoWnPYstFOTib-bMhFNnw/s1600/Bildschirmfoto+von+2020-06-23+12-26-06.png" imageanchor="1" style="margin-left: 1em; margin-right: 1em;"><img border="0" data-original-height="612" data-original-width="1088" height="360" src="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEjvozfdTckoaxtLKwi0_GHI_q0u8__IeDhzC5QggdfD0hvlyPIiRIvNh9mM2ZP3UqMPEBco56Go4EQpZ6bx8OfSgMauHjRHhV9aBCZMwyGP8paoZPc49r_v-dvoWnPYstFOTib-bMhFNnw/s640/Bildschirmfoto+von+2020-06-23+12-26-06.png" width="640" /></a></div>
<div class="separator" style="clear: both; text-align: center;">
</div>
<br />
One can use the benchmark to <b>compare different machines</b>, just make sure they use a similar compiler. Kcbench can perform <b>stress tests</b>, too. It's also useful to find the <b>optimal number of jobs for compiling source code</b>, as 'just use all cores' sometimes is not the fastest setting.<br />
<br />
For example, on a AMD Ryzen Threadripper 3990X (64 cores/128 threads) a lot of people will expect compiling with 128 jobs (`make -j 128`) will be fastest. But while testing kcbench on a such a processor it turned out that at least the testes machine built a Linux kernel quite a bit <b>faster with only 64 jobs</b> (and thus utilizing only the real cores): <br />
<div class="separator" style="clear: both; text-align: center;">
<a href="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEjSA8kUu_5vm6-izh6vkYlsMWre9TAGKjxkgARgwcR1GwEws0eSh9PZyRugXXsNHXmD2Fmd0oRunu5NzEkjaAV6rBzItrpPxkFSyg_iS7wKgFkdzmeTiJhAityaAc35wrN8C9gfmtC1Qzc/s1600/Bildschirmfoto+von+2020-06-22+17-56-12.png" imageanchor="1" style="margin-left: 1em; margin-right: 1em;"><img border="0" data-original-height="841" data-original-width="1145" height="468" src="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEjSA8kUu_5vm6-izh6vkYlsMWre9TAGKjxkgARgwcR1GwEws0eSh9PZyRugXXsNHXmD2Fmd0oRunu5NzEkjaAV6rBzItrpPxkFSyg_iS7wKgFkdzmeTiJhAityaAc35wrN8C9gfmtC1Qzc/s640/Bildschirmfoto+von+2020-06-22+17-56-12.png" width="640" /></a></div>
<span id="goog_1969903293"></span><br />
<br />
<div style="text-align: left;">
There was no time for a closer inspection, but it looks like memory and its caches might have been a bottleneck that lead to this. It was different on a AMD EPYC 7742 (128 cores/256 threads), as using 256 jobs there lead to the best result:</div>
<div style="text-align: center;">
<a href="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEitrMeyRXUJ6860sfVpvy7zgubAd2qpt_ZbFyD4_i8OUgt5IoMfgVavermXu0Ev76XVbRdFszIMjRyiXtqWNDtDeo3qKJ7IKMmkwH9_Q_P7WQCgpvsMjHC137uwG0m5krKbj0K0uZ7xICc/s1600/Bildschirmfoto+von+2020-06-22+20-04-01.png" style="margin-left: 1em; margin-right: 1em;"><img border="0" data-original-height="412" data-original-width="1014" height="260" src="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEitrMeyRXUJ6860sfVpvy7zgubAd2qpt_ZbFyD4_i8OUgt5IoMfgVavermXu0Ev76XVbRdFszIMjRyiXtqWNDtDeo3qKJ7IKMmkwH9_Q_P7WQCgpvsMjHC137uwG0m5krKbj0K0uZ7xICc/s640/Bildschirmfoto+von+2020-06-22+20-04-01.png" width="640" /></a></div>
For more about kcbench see the <a href="https://gitlab.com/knurd42/kcbench/">project page at gitlab</a>, the <a href="https://gitlab.com/knurd42/kcbench/-/blob/master/README.md">README</a> and the man-pages for <a href="https://gitlab.com/knurd42/kcbench/-/raw/master/kcbench.man1.md">kcbench</a> and <a href="https://gitlab.com/knurd42/kcbench/-/raw/master/kcbenchrate.man1.md">kcbenchrate</a>. The rate variant is one of the big new enhancements in the new version. Instead of compiling one kernel really fast kcbenchrate compiles one kernel on each CPU to measure the rate and keep the all cores busy all the time. See the man-pages for a more detailed explanation of the approaches the two use. Cross-compilation is supported now, too. To learn about all the other improvements in <a href="https://gitlab.com/knurd42/kcbench/-/releases/v0.9.0">kcbench v0.9.0 see its release page</a>.<br />
<br />
The new kcbench including kcbenchrate is in Fedora Rawhide. It's also in updates-testing for <a href="https://bodhi.fedoraproject.org/updates/FEDORA-2020-eba45aa596">Fedora 31</a> and <a href="https://bodhi.fedoraproject.org/updates/FEDORA-2020-740479e5ec">Fedora 32</a> currently and will be moved to the proper updates repositories in a few days.Thorsten Leemhuishttp://www.blogger.com/profile/12285919704852601523noreply@blogger.com0tag:blogger.com,1999:blog-1447157631220361519.post-43928535792448227922011-07-16T20:16:00.010+01:002011-07-17T16:59:26.373+01:00Why I'm not posting much on Google+ – or – My big problem with Google+<div style="text-align: left;"><span style="font-size:100%;">The "tldr"-version: Google+ has lots of nice things, but in its current state it does not look like a solution that could replace twitter (and identi.ca) for me at all. In fact I'd need something like tags or topic-streams (that people could select when adding me to their circles) for my messages before I'd feel more comfortable to write public posts on G+ </span><span style="font-size:100%;">more that occasional</span><span style="font-size:100%;">.<br /><br /></span></div><span style="font-size:100%;">The detailed version: It seems the people that added me to their circles mainly know me from one of four aspects of my life:<br /></span><ol><li><span style="font-size:100%;">my work for heise.de and c't</span></li><li><span style="font-size:100%;">English translations of that work published on "<a href="http://h-online.com/open/">The H</a>"</span></li><li><span style="font-size:100%;">my contributions to Fedora</span></li><li><span style="font-size:100%;">this strange thing called real-life (</span><span style="font-size:100%;">good 3D effects!) </span></li></ol><span style="font-size:100%;">Sending out just one public information stream to those people afaics would only make very few of them happy; I'd feel like spamming them with crap they are clearly not interested in.<br /><br />Among the reasons for that view are simple language problems: I was born and live in Germany and speak German most of the time – but I know lots of people from the US, the UK and other countries and most of them do not know more that five German words. Many of them added me to their circles nevertheless; I'm also in a lot of circles where I don't know the people at all; hence I don't know their interest in me or their language preferences. I could avoid annoying them with German posts by writing in English all the time when doing public posts – but that's a crappy workaround (one I suppose might annoy some of my German friends over time) and not a real solution for the underlying problem.<br /><br />Yes, you are of course right, that is a problem on Twitter as well. But I solved that easily by using multiple accounts right from the start, which is not easy with G+. Using three accounts also mostly circumvents the problem I indicated in the beginning: Different people are interested in different things and only they can decide what they are interested in.<br /><br />Here is how I do it with twitter:<br /></span><ul><li><span style="font-size:100%;">My main account is <a href="http://twitter.com/thleemhuis">@thleemhuis</a>. Just like everybody else I use it to tweet things from my real life (including work). Most of the tweets are German, some are English; almost all of the followers are from Germany or understand German afaics</span></li><li><span style="font-size:100%;">I use <a href="http://twitter.com/kernellogauthor">@kernellogauthor</a> to tweet about things in the Linux kernel area I stumble upon; it is a kind of bonus and an additional communication channel for readers of my Kernel-Log (<a href="http://bit.ly/dPrByw">DE</a>, <a href="http://bit.ly/nKP3Ix">EN</a>). Almost all tweets are English (I assume most Germans that read the Kernel Log know English well enough) and kernel related. It has 266 subscribers (some more on identi.ca) and only a handful of them follow @thleemhuis as well</span></li><li><span style="font-size:100%;">Many English speaking people also know me from all the contributions I did to Fedora in the past few years (I'm mostly inactive in that area right now); I follow them via <a href="http://twitter.com/knurd666">@knurd666</a> and provide them with a English tweet there now and then; only a handful of them follow @thleemhuis or @kernellogauthor<br /></span></li></ul><span style="font-size:100%;">IOW: I have three kinds of followers (something like 500 on twitter </span><span style="font-size:100%;">in total </span><span style="font-size:100%;">and 200 more on identi.ca) that seems to be interested in stuff I do, but there are only very few people (I assume less than 5) that follow all three accounts; and yes, I occasionally mention the different accounts on each other, so it's not a secret I use multiple accounts...<br /><br />I'd really like to feed them with information from my life or work via Google+, too, but I can not see how to do that efficiently, because right now I have to know that people are interested in; on twitter those that follow me can decide on their own. That's why G+ seems so alien and wrong to me. Something like predefined tags, streams or "outgoing circles" people could select when they add me could help. But maybe that's to complicated; and maybe my situation is special and shows a problem other do not encounter.<br /><br />P.S.: Yes, maybe I'm thinking to much as someone that wants to maximize the group of people he can reach </span>--<span style="font-size:100%;"> maybe that has something to do with my day ob ;-)<br /></span>Thorsten Leemhuishttp://www.blogger.com/profile/12285919704852601523noreply@blogger.com3tag:blogger.com,1999:blog-1447157631220361519.post-87221812238623296082010-09-30T19:42:00.002+01:002010-09-30T19:45:54.390+01:00New Intel graphics drivers releasedThe Fedora developers among you will be aware: there is a <a href="https://fedoraproject.org/wiki/Test_Day:2010-09-30_Intel">Fedora Test Day with a focus on the Intel graphics card driver</a> today (Thursday the 30th). The X.org driver that is being tested afaics is xorg-x11-drv-intel (also known as xf86-video-intel) version 2.12.0, release 6.fc14 -- the latest F14 build <a href="http://koji.fedoraproject.org/koji/packageinfo?packageID=7794">as of today</a>.<br /><br />Oh, and something else happened today: After three months of development Carl Worth released a xf86-video-intel version 2.13.0. Quoting the <a href="http://thread.gmane.org/gmane.comp.freedesktop.xorg.drivers.intel/1752">release announcement</a>: "[...] With the many bug fixes in this release, we encourage everyone using 2.12 to upgrade to 2.13. [...]"<br /><br />So people that participate in the testing today might run into bugs that that are fixed in 2.13 or in its pre-release already. But what is even worse from my point of view: With the new and recently <a href="http://lists.fedoraproject.org/pipermail/devel-announce/2010-September/000694.html">ratified Fedora updates policy</a> it seems unlikely to me that Fedora 14 will update to 2.13 ever (note: unlikely still means it's possible!).<br /><br />My head simply fails to understand why that is the right thing to do in this and similar cases. Even worse: lot's of other distributions have similar policies, so it's take months or years till the fixes the Intel developers worked out in the past three months make their way to regular end users.Thorsten Leemhuishttp://www.blogger.com/profile/12285919704852601523noreply@blogger.com4tag:blogger.com,1999:blog-1447157631220361519.post-56291573063496284752010-06-05T14:08:00.003+01:002010-06-05T14:11:51.157+01:00Visiting LinuxTag and Red Hat Summit 2010Blog entry for my fellow readers that visit LinuxTag (next week) or Red Hat Summit/JBoss World 2010 (starting in two and a half weeks from now):<br /><ul><li>I'm in Berlin for LinuxTag next Saturday (on my own efforts).</li><li>I'm in Boston for the whole Summit to report about it for my employer.</li></ul>So if you want to meet me in real life simply look out for me or sent a mail to arrange a meeting.<br /><br />BTW, looks like I might stay in Boston till Sunday afternoon, so I will have some free time once the Summit is over and all work done. Please let me know if you have any good suggestion how to best spent that time it in Boston! tia!Thorsten Leemhuishttp://www.blogger.com/profile/12285919704852601523noreply@blogger.com0tag:blogger.com,1999:blog-1447157631220361519.post-53263774393037079352009-11-11T22:28:00.001+01:002009-11-11T22:30:48.916+01:00What questions would you like to ask the Candidates for the Fedora Board, FESCo, and FAMSCO?As you may have heard already, several seats of the Fedora Board, FESCo, and FAMSCO are up for election soon(¹). Right now we are in the nomination period, which will be followed by a "Candidate Questionnaire." That means we'll give candidates a list of questions to answer by private mail within one week after the nomination period closed; the results will be publish soon after that to make sure they are available to the public before the Town Hall meetings on IRC happen.<br /><br />Candidates may choose to answer (or not) those questions as they see fit. Voters can use the answers to get an impression of what the candidate think or plan to do while serving for the committees they are nominated for. That should help to get a interesting discussion running during the IRC Town Hall meetings; furthermore, those people that can't or don't want to participate in the IRC meetings can use the answers to make a more informed vote.<br /><br />Hence we need to prepare a few good questions that we can send to the candidates once the nomination period ends. And that's where I need *your help* now:<br /><br />If you have one or more questions you'd like to send to the candidates simply go and add them to:<br /><br />https://fedoraproject.org/wiki/Elections/F13_Questionnaire<br /><br />It just takes a minute or two, so best to do it right now -- otherwise you might get distracted and forget about it. ;-)<br /><br />I'll take care of the remaining work to review, sort, and clean up the questions(²); after that I'll send them to the candidates soon after the nomination period ended. Hence, I need your question suggestions by around the 15th November 17:00 UTC latest to get a chance to prepare everything in time.<br /><br />So please go to the wiki now and add at least one hard question! The answers will help Fedora contributors to chose whom to vote for! Thanks in advance for your help .<br /><br />CU<br />knurd<br /><br />(¹) If you haven't read about it yet see<br />https://fedoraproject.org/wiki/Elections for details.<br /><br />(²) If you want to get involved or review the questions before I send them please drop me a line and I'll try to get that arranged; maybe we can arrange a quick, informal IRC meeting on Sunday evening if there is interest<br /><br />P.S.: This blog post is mainly meant to get spread via planet.fedoraproject.org ;-)Thorsten Leemhuishttp://www.blogger.com/profile/12285919704852601523noreply@blogger.com1tag:blogger.com,1999:blog-1447157631220361519.post-81560022550792488102009-11-01T18:10:00.005+01:002009-11-01T18:55:03.698+01:00New RPM Fusion packages: nvidia drivers for F12, staging drivers for F11 and F12Just FYI:<br /><ul><li>the nvidia graphics drivers finally showed up again in the RPM Fusion repository for rawhide (the current public rawhide to be precise, e.g. what becomes Fedora 12 soon)</li><li>Most drivers from the linux-staging tree are disabled in the kernels that Fedora ships (among them a few wifi drivers like rtl8187se) . That's a good thing, as they are often of highly questionable quality (¹, ²). But some people nevertheless what them, as they own hardware that needs them(³). Those people from now on can get them easily for Fedora 11 and Rawhide/Fedora 12 by installing kmod-staging from RPM Fusion.<br />Please note that:<br /><ul><br /><li>the drivers for Fedora 11 are in rpmfusion-free-updates-testing currently and build for the kernel that is in Fedora's updates-testing repo; thus to use them you need to run something like "yum --enablerepo='*testing' install kmod-staging" and reboot into the kernel that is installed to use them<br /></li><li>you need to install kmod-staging-PAE if you use a PAE kernel on your x86-32 machine<br /></li><li>there are no akmod-staging package at this time<br /></li><li>the package doesn't contain all the drivers from the staging tree; in case you miss one just file a bug in bugzilla.rpmfusion.org and tell the packager to enable it<br /></li></ul></li></ul>Also note that it might take some hours till the mirror yum chooses for you offers the packages, as they were uploaded to the master repo just a few minutes before this blog posting got published.<br /><br />We thank you for your attention and we wish you a pleasant flight.<br /><br />(¹) that's the long story short<br /><br />(²) don't expect the drivers to work well; NetworkManager for example will in have problems with some of the WiFi drivers in staging-kmod. In most cases that will be the fault of the driver <span style="font-style: italic;">and not</span> NetworkManager, thus filing NetworkManager bugs that occur with staging drivers is likely a waste of your time.<br /><br />(³) friends don't let friends buy hardware which need's staging (or even worse: proprietary) drivers on LinuxThorsten Leemhuishttp://www.blogger.com/profile/12285919704852601523noreply@blogger.com0tag:blogger.com,1999:blog-1447157631220361519.post-88291660788823254772009-06-27T16:15:00.006+01:002009-06-27T16:28:19.604+01:00Presentations from LinuxTag / Fudcon Berlin 2009 available; Tomorrow: HackfestsMy presentations on LinuxTag and Fudcon Berlin 2009 went mostly well. Biggest problem when looking back now: Seems it was more then enough stuff to talk for 90 or 100 minutes, but I only had a hour in total :-/.<br /><br />Want to look at the slides? Follow these links:<br /><ul><li>German, LinuxTag: "<a href="http://www.leemhuis.info/files/talks/linuxtag09-kernel-log.pdf">Überblick über aktuelle Entwicklungen des Linux-Kernels</a>"</li><li>English, FUDCon: "<a href="http://www.leemhuis.info/files/talks/linuxtag09-rpmfusion.pdf">What is RPM Fusion and why it is really important for Fedora (and how you can help to make it better!)</a>"</li></ul>Another problem: <a href="https://fedoraproject.org/wiki/FUDCon:Berlin_2009_attendees">There are so many people here at FUDCon</a> and I more and more get the impression that the list with people I "want to meet, shake hands with and talk to for a while, to get a better connection between faces, email addresses, nicks, and (those sometimes overrated) real names" isn't getting shorter as fast as it should to meet everyone in the remaining time. Seems I need to speed up somehow...<br /><br /><a onblur="try {parent.deselectBloggerImageGracefully();} catch(e) {}" href="http://fedoraproject.org/w/uploads/9/9b/ThorstenLeemhuis_LeemhuisThorsten-med.jpg"><img style="margin: 0pt 0pt 10px 10px; float: right; cursor: pointer; width: 194px; height: 250px;" src="http://fedoraproject.org/w/uploads/9/9b/ThorstenLeemhuis_LeemhuisThorsten-med.jpg" alt="" border="0" /></a> It's the same for you? If yes and if you ever wanted to talk to the crazy troublemaker that did or does a lot of work for Fedora, EPEL and Livna/RPM Fusion then just grab me and start to talk to me when you see me walking by or sitting somewhere. The photo on the right shows how I look like, just imagine some mostly inconspicuous glasses on the nose. Ohh, and the hair is a bit shorter right now (I guess nature will do it's best to fix that over time).<br /><br />BTW, again some informations for the FUDConners: I plan a small "RPM Fusion" <a href="https://fedoraproject.org/wiki/FUDCon:Berlin_2009#BarCamp_and_Hackfests">hackfest</a> for tomorrow *if* people are interested in one. There is no real plan what to do exactly besides the general idea: Do some work to improve RPM Fusion, and work out the details on the fly. Want to join? Then just <a href="https://fedoraproject.org/wiki/FUDCon_Berlin_and_LinuxTag_2009_talks">watch the wiki</a> and the usual places at FUDCon for details!Thorsten Leemhuishttp://www.blogger.com/profile/12285919704852601523noreply@blogger.com0tag:blogger.com,1999:blog-1447157631220361519.post-41716612825646809372009-06-25T09:28:00.003+01:002009-06-25T09:46:08.259+01:00thl and knurd @ LinuxTag 2009 and Fudcon Berlin 2009I just arrived in Berlin at the fairgrounds where <a href="http://www.linuxtag.org/2009/en/">LinuxTag 2009</a> and <a href="http://fedoraproject.org/wiki/FUDCon:Berlin_2009">Fudcon 2009</a> are held. I'm staying till Sunday evening, but like so often I have to split my attention and time as I'm partly here for my employer and partly for fun/<a href="http://fedoraproject.org">Fedora</a> (<a href="http://thorstenl.blogspot.com/2008_06_01_archive.html">just like</a> last year at Red Hat Summit Boston). <br /><br />As usual that's creating some interesting problems where I ideally wound like to be at two places at the same time :-/<br /><br />Friday will get most complicated. I for example can't visit the <a href="http://fedoraproject.org/wiki/Jan_Wildeboer_-_Keynote">Fudcon-Keynote from Jan Wildeboer</a>, as I'm giving a <a href="http://www.linuxtag.org/2009/de/program/freies-vortragsprogramm/mittwoch/vortragsdetails.html?talkid=563">"Kernel-Log" talk</a> as part of the "Kernel Track" of LinuxTag at just the same time. That wasn't planed like that, but seems Jonathan Corbet canceled his trip and thus can't give his well know and always interesting "The Kernel report"; I three or four weeks ago was asked to fill the position and accepted (presentation is basically finished; luckily Linus closed the merge window a few hours ago). Note that I'm giving that talk in German, not in English, as Jonathan would have done.<br /><br />I also have time and space problems for <a href="http://spevack.livejournal.com/84441.html">the barcamp pitching</a> session at 5 pm local time: Together with Nils Magnus from LinuxTag e.V. / Linux New Media I'm moderating the <a href="http://www.linuxtag.org/2009/en/program/freies-vortragsprogramm/mittwoch/vortragsdetails.html?talkid=571">Kernel Kwestioning</a> at that time, where the audience can ask some kernel developers on stage a few questions. <br /><br />And that are only the hard scheduled events which I really can't miss. I also want (have?) to hear at least two of the other talks (<a href="http://www.linuxtag.org/2009/en/program/freies-vortragsprogramm/mittwoch/vortragsdetails.html?talkid=567">Union Mounts</a> and <a href="http://www.linuxtag.org/2009/en/program/freies-vortragsprogramm/mittwoch/vortragsdetails.html?talkid=569">Ksplice</a>) from the Kernel track on LinuxTag, so I likely walk back and forth between Kernel track and Fudcon a lot on Friday. But I hope to join the Fudcon crowd early for Fudpub in the evening -- I mean, I likely *have to*, as the Fudpub otherwise might run out of pizza and drinks before I arrive (you know how Fedorians are...). <br /><br />Remains to be seen how long I can stay at Fudpub, as I still have to prepare my presentation on RPM Fusion which I'm giving at 2 pm on Saturday on Fudcon. I'll give that talk in English -- I'm not completely sure yet if that works out, but I guess I have to give it a try sooner or later. So remember to bring eggs and tomatoes to throw them on the stage if my English is way to worse ;-)<br /><br />So, see you on LinuxTag and Fudcon! <a href="http://fedoraproject.org/wiki/File:ThorstenLeemhuis_LeemhuisThorsten-med.jpg">This is how I look like</a>. But note, I had to buy a add-on a few months ago: now with glasses (often, not always) ;-)<br /><br />P.S.: Headline-Explanation: those that contribute to Fedora for a long while will remember that I used to be known as "thl" in the Fedora -world initially. But I already was and still am "thl" at work and a few years ago decided it might be better to use a different nick in the Fedora world -- after a bit of thinking I chose "knurd". That way it's at least a bit harder (especially on IRC!) to get the connection "Ohh, the thl that writes the kernel-log for c't/heise.de/the-h is also the one that contributes to Fedora", which I think is a good thing. But it's not really a secret anyway, as rare blog entry like this make it obvious. But trying to keep it a real secret would not work anyway, as the name "Thorsten Leemhuis" quite rare, so it's not that hard to find out anyway.Thorsten Leemhuishttp://www.blogger.com/profile/12285919704852601523noreply@blogger.com1tag:blogger.com,1999:blog-1447157631220361519.post-60574130880108424532009-06-17T21:12:00.002+01:002009-06-17T21:27:16.741+01:00rpmfusion-{,non}free-remix-kickstarts -- or -- knurdixThere was always the idea to build a linux distribution with RPM Fusion packages within the <a href="http://rpmfusion.org/">RPM Fusion</a> project -- e.g. live media and installer spins ^w <a href="http://fedoraproject.org/wiki/Remix">remixes</a> that are basically a distribution like Fedora under a different name and with some packages from RPM Fusion. There is/was <a href="https://www.redhat.com/archives/fedora-announce-list/2008-September/msg00015.html">Omega 10</a>, which until now never became the official spin for one reason or another. Recently some other work was done to get one step closer to create a official "Fedora Remix" from RPM Fusion sooner or later:<br /><br />RPM Fusion since a few weeks contains the packages <a href="http://cvs.rpmfusion.org/viewvc/rpms/rpmfusion-free-remix-kickstarts/?root=free">rpmfusion-free-remix-kickstarts</a> and <a href="http://cvs.rpmfusion.org/viewvc/rpms/rpmfusion-nonfree-remix-kickstarts/?root=nonfree">rpmfusion-nonfree-remix-kickstarts</a> in the repositories for Fedora 11 and Rawhide. They just like the Fedora package <a href="https://fedorahosted.org/spin-kickstarts/">spin-kickstarts</a> contain kickstart files that can be used to create your own linux distribution live-image using the Fedora Package Collection and Fedora's <a href="https://fedoraproject.org/wiki/FedoraLiveCD">livecd-tools</a>. A installer image is still on the todo list and might need some fixes in anaconda and the rpmfusion-{,non}free-release packages afaics.<br /><br />The kickstart files in the two RPM Fusion packages are pretty basic: They simply include the kickstart files from Fedora, remove the Fedora branding, add the generic branding and add the repo definitions for RPM Fusion. That's basically it, because the comps groups from RPM Fusion extend the groups that Fedora defines and thus you automatically get all the packages you want depending on what's defined in the RPM Fusion comps files -- that is for example gstreamer-plugins-ugly and gstreamer-ffmpeg in the case of the Gnome groups and xine-lib-extras-freeworld for the KDE remix.<br /><br />As a proffce of concept I created four remixes (Desktop and KDE for i586 and x86_64) for testing purposes and uploaded them to <a href="http://knurd.crazyfrogs.org/remixes/fedora/11/">to the web</a> for public testing. But warning: They are basically untested and just meant to show what's possible. Ohh, and due to the lack of a better name I just called them "knurdix" ;-) We'll need to find a different name for the official RPM Fusion images (which might be simply "RPM Fusion" or something else that sounds better).<br /><br />Hopefully those packages and the kickstart files in it can help to get some people interested in the idea of a RPM Fusion remix -- maybe enough people to build and maintain official "Fedora remixes" with packages from RPM Fusion" in the long term. If you are interested to help just <a href="http://lists.rpmfusion.org/mailman/listinfo/rpmfusion-developers">join the rpmfusion-developers</a> list and share your ideas. Or get in contact with <a href="http://fedoraproject.org/wiki/User:Thl">me</a> directly, but the mailing list is the preferred way.Thorsten Leemhuishttp://www.blogger.com/profile/12285919704852601523noreply@blogger.com0tag:blogger.com,1999:blog-1447157631220361519.post-42121417882767449022009-06-12T14:35:00.004+01:002009-06-12T14:45:13.157+01:00Make things easy<a href="http://news.gmane.org/find-root.php?message_id=20090612084622.60198b0e%40lxorguk.ukuu.org.uk">Alan Cox recently on LKML</a>:<br /><pre wrap="">[...] If nobody else is interested then you can do the reviewing/acking<br />because clearly nobody else cares if you make a mistake. And if they do<br />then they'll be motivated to add resources to assist you ;) [...]<br /></pre>Sometimes I wonder if we should apply a similar concept in Fedora/RPM Fusion land more often.Thorsten Leemhuishttp://www.blogger.com/profile/12285919704852601523noreply@blogger.com0tag:blogger.com,1999:blog-1447157631220361519.post-25268811703124203092009-06-01T13:23:00.004+01:002009-06-01T13:46:46.608+01:00Leave kmods in RPM Fusion, but make sure they work wellIn short: Fedora IMHO should not ship separate packages with kernel modules (so called "kmod packages") as part of the package collection. But Fedora afaics needs to make sure things like kmods work well, even if they are not used in the Fedora package collection.<br /><br />Verbose variant: Recently there was another(¹) <a href="http://thread.gmane.org/gmane.linux.redhat.fedora.devel/113748/focus=113820">discussion on fedora-devel</a> about allowing packages with kernel-modules in the Fedora package collection. I'm one of the drivers of the original "kmod" packaging standard for kernel-modules in Fedora and take care of it in RPM Fusion these days (which uses a modified version). So obviously I have a strong interest in the area. <br /><br />Nevertheless I stayed away from the discussion and I guess many would have been surprised if I'd shared my option: It doesn't make much (if any) sense to package kernel modules as separate packages in Fedora. The main reason for this option: Everything lands in one package repository anyway(²), so it's much easier for everyone to get the bits into Fedora's proper kernel package directly. And I agree with the suggested approach way to make that happen as well: get the modules upstream, e.g. in linus' "vanilla" kernel (and not the staging area), then Fedora will get them automatically. <br /><br />But: Some widely used kernel-modules will never make it upstream. For others (like some of those in linux-staging) it's a long way that takes a lot of time, because the code of those modules often is in a bad shape; until that's fixed and an improved variant merged a lot of people are nevertheless willing to use the ugly code we have today, because for them it's often better than throwing hardware away. <br /><br />Fedora ignores those cases -- afaics because they are "not the right thing to do" or maybe "politically incorrect". One can argue if that is right or wrong for Fedora, but that's a topic for a different blog entry. The real point I'm up to: users still want to get the modules they need. Thus they will either work around it locally, use/contribute to repositories like RPM Fusion, or switch to a distribution that offers them what they want.<br /><br />The latter is something that is neither in the interest of Fedora or Red Hat. Hence I'd say it would be good if Fedora would make sure that things like kmods work well, *even if they are not used within Fedora* -- just like Red Hat makes sure that Oracle DBs work fine on RHEL (which uses kmods in RHEL5, so RHEL would benefit from proper kmod support and testing in Fedora as well). But that's not the case right now(³), which makes Fedora sometimes annoying or hard to use. <br /><br />(¹) There have been a lot similar discussion around kmods over the past years.<br /><br />(²) My option might be different if we had something like a "extras"/"unsupported" add-on repositories within Fedora, as that would make it obvious "hey, these modules are not part of the upstream kernel/might not work so well/might suddenly go away again".<br /><br />(³) Note that the main problem afaics is on the Fedora side, so it's not really fixable for RPM Fusion. I outlined the details in <a href="https://www.redhat.com/archives/fedora-devel-list/2008-August/msg00041.html">a posting to fedora-devel</a> last August, but nothing happened. There are ways to work around the problem using a yum-plugin. But that is not a real fix, because the problem is not specific to kmods -- it happens with a lot of other packages as well in cases where a RPM Fusion package depends on a specific version of a package that is part of Fedora (xine-lib and xine-lib-extras-freeworld for example). And yes, sorry, I don't have the skills to fix the problem myself. But I don't think I have to -- Fedora afaics is meant to be a community where people with different skills work on different areas of the project to make the whole thing better.Thorsten Leemhuishttp://www.blogger.com/profile/12285919704852601523noreply@blogger.com1tag:blogger.com,1999:blog-1447157631220361519.post-22908772473675011052009-05-23T12:39:00.004+01:002009-05-27T09:30:37.121+01:00Fedora 11, kernel-PAE, and what it means for your x86-32 systemThere is one small change in Fedora 11 that I guess will confuse Fedora and RPM Fusion users with x86-32 (aka i386/ix86) systems quite a lot, but afaics did not get enough attention yet:<br /><ul><li><a href="http://fedoraproject.org/wiki/Features/ArchitectureSupport">By default, the PAE kernel will be used on 32-bit hardware, where appropriate</a>(¹).</li></ul>"Appropriate" is not really explained -- maybe because it's a bit hard to sum up without going into the boring details. But basically it boils down to: The kernel with PAE support will be installed by Fedora 11 for x86-32 on the majority of x86-compatible systems that have been manufactured in the past three or four years(¹). So likely on your system as well if you are running a x86-32 distro on a modern system.<br /><br /><b>The important part</b>: the package containing the kernel with PAE support is not called "kernel" -- it's called "kernel-PAE" instead. And that's not the only package where "-PAE" is used as suffix. That has major certain consequences on systems where Fedora 11 installs kernel-PAE:<br /><ul><li>when you build kernel modules with akmods, dkms, or manually, then you from now on need to install kernel-PAE-devel instead of kernel-devel </li><li> similar for kernel-modules: instead of "yum install kmod-nvidia" your now need to type "yum install kmod-nvidia-PAE". Yum otherwise will try to install the matching kernel without PAE support for you, which (in short without the boring details) is something you most of the time don't want(²).</li></ul>In other words: the change in Fedora 11 makes lots of howtos, FAQs, articles on the net and in computer magazines confusing, wrong, misleading or harmful (depending on view and specific howto/FAQ/article), because most of those docs don't consider the above fact (yet).<br /><br />And that's not Fedora's fault -- PAE kernels are around for a long time in Fedora already. But they were used only on a minority of systems. Most (not all!) of those that have written today's howtos, FAQs or articles were likely either not aware of it or chose to ignored it to keep things simple.<br /><br />That's backfiring now. So go and spread the news on mailing lists, forums and other places where it might be of interest. Feel free to copy-n-paste this whole text or simply point to this blog entry. Thanks in advance!<br /><br />(¹) E.g. since processors with NX bit became mainstream; NX stands for NoeXecute and is also called Enhanced Virus Protection by AMD and xD-Bit by Intel<br /><br />(²) not sure, but maybe the yum-plugin "yum-fedorakmod" could have made yum to the right thing and install the proper kmod for the PAE kernel. I never tried and it doesn't matter much as the plugin is not available in the Fedora or RPM Fusion repositories for F11. If someone wants take care of yum-fedorakmod and wants to get it into RPM Fusion then please drop me a line.Thorsten Leemhuishttp://www.blogger.com/profile/12285919704852601523noreply@blogger.com1tag:blogger.com,1999:blog-1447157631220361519.post-75571511482943047252009-05-23T13:25:00.000+01:002009-05-23T13:17:27.879+01:00yum install thunderbird-enigmailThe <a href="http://rpmfusion.org/">RPM Fusion</a> Free package repositories now(¹) contain the popular thunderbird extension <a href="http://enigmail.mozdev.org/home/index.php">enigmail</a> for F9, F10, F11/rawhide and EL-5. To install it just <a href="http://rpmfusion.org/Configuration">configure RPM Fusion</a> and run:<br /><br /><span style="font-family:courier new;"># yum install thunderbird-enigmail</span><br /><br />Big "thanks!" goes to <a href="http://blog.famillecollet.com/">Remi Collet</a> for packaging it up and submitting it for Review in RPM Fusion.<br /><br />The package is especially helpful for users of rawhide/Fedora 11, as the enigmail homepage doesn't offer prebuild extensions for the thunderbird beta that Fedora 11 contains. It's also nice for users of Fedora for x86-64, as the add-ons on the enigmail homepage sometimes were outdated.<br /><br />Additional note: Normally RPM Fusion doesn't take any packages that are suitable for Fedora to avoid getting in Fedora's way. But earlier attempts to get thunderbird-enigmail into Fedora have failed, so we took it; hopefully the package can be moved to Fedora sooner rather than later!<br /><br />(¹) might take up to something like 32 hours till your yum sees it due to mirror lag and metadata cachingThorsten Leemhuishttp://www.blogger.com/profile/12285919704852601523noreply@blogger.com3tag:blogger.com,1999:blog-1447157631220361519.post-52898509981045322992009-05-19T16:07:00.002+01:002009-05-19T16:09:49.588+01:00What questions would you like to ask the Fedora Board or FESCo Candidates?Several seats of the Fedora Board and FESCo are up for election soon(¹). Right now we are in the nomination period, which will be followed by a "Candidate Questionnaire." That means we give candidates a list of questions to answer by mail before the Town Hall meetings on IRC happen.<br /><br />Candidates may choose to answer (or not) those questions as they see fit. Voters can use the answers to get an impression of what the candidate think or plan to do while serving for the Board or FESCo. That should help to get a interesting discussion running during the IRC Town Hall meetings. Furthermore, those people that can't or don't want to participate in the IRC meetings can use the answers to make a more informed vote.<br /><br />Hence we need to prepare a few good questions that we can send to the candidates once the nomination period ends. And that's where I need <b class="moz-txt-star"><span class="moz-txt-tag">*</span>your help<span class="moz-txt-tag">*</span></b>: If you have one or more questions you'd like to send to the candidates simply go and add them to:<br /><br /><a class="moz-txt-link-freetext" href="https://fedoraproject.org/wiki/Elections/Questionnaire">https://fedoraproject.org/wiki/Elections/Questionnaire</a><br /><br />It just takes a minute or two, so best to do it right now -- otherwise you might get distracted and forget about it. ;-)<br /><br />I'll take care of the remaining work to review, sort, and clean up the questions(²), and send them to the candidates after the nomination period ends. Hence, I need them by around the 27th of May. I'll later collect the answers from the candidates and put them up for pubic consumption to give people enough time to read them before the town hall meetings start.<br /><br />So go to the wiki and add at least one hard question! The answer will help Fedora contributors to chose whom to vote for!<br /><br />Thanks for your help in advance.<br /><br />(¹) If you haven't read about it yet see <a class="moz-txt-link-freetext" href="https://fedoraproject.org/wiki/Elections">https://fedoraproject.org/wiki/Elections</a> for details.<br /><br />(²) If you want to get involved or review the questions before I send them please drop me a line and I'll try to get that arrangedThorsten Leemhuishttp://www.blogger.com/profile/12285919704852601523noreply@blogger.com0tag:blogger.com,1999:blog-1447157631220361519.post-38914321550454941592009-05-19T15:46:00.003+01:002009-05-19T16:00:56.999+01:00UnprofessionalDear <a href="http://gnome.org/">GNOME project</a>,<br /><br />thanks for running the "GNOME 3.0 General Sociological Research" survey and putting the results <a href="http://live.gnome.org/UsabilityProject/UsabilityTests/GnomeGeneralResearch">online</a>.<br /><br />A small note: If you ask people if they use foo, bar, baz or foobar and most people select foo, that that's it. Nothing more. And definitely don't conclude "Nearly <sup>3</sup>/<sub>4</sub> of the people use foo for it's stability, compatibility and ease of use", because the latter part is a personal option if there wasn't a question "why do you use foo" with checkboxes "stability", "compatibility" and "ease of use" next to it.<br /><br />Personal opinions like that render the whole conclusion unbelievable and make things look highly unprofessional.Thorsten Leemhuishttp://www.blogger.com/profile/12285919704852601523noreply@blogger.com2tag:blogger.com,1999:blog-1447157631220361519.post-20832788475852509702009-02-28T16:04:00.002+01:002009-02-28T16:08:05.505+01:00rpmusrtools?The <a href="https://fedoraproject.org/wiki/Rpmdevtools">rpmdevtools</a> are in Fedora for quite a while now and really helpful in a lot of situations. So are the tools in the <a href="http://wiki.linux.duke.edu/YumUtils">yum-utils</a>. But the tools in those two packages don't completely satisfy all my needs, hence I (ages ago) wrote a few small scripts that do some additional magic:<br /><ul><li>run "rpm -V" on all the packages and look out for packages where files are (a) missing or (b) corrupted; the script as a bonus (c) can even print out config files that have been modified (which likely should be part of a separate script, as that might be handy for backup purposes); if likely (d) should offer to reinstall packages that have missing or corrupted files<br /></li><li>run something like "find /bin/ /boot/ /etc/ /lib/ /opt/ /sbin/ /usr/ /var/" with "-type f" and/or "-type d" and let rpm check if the list of files and/or directories that find outputs are owned by a package -- complain if not; that's quite a lot of work for the system and takes a while to complete, but often turns up a whole lot of old and obsolete cruft that is lying in some hidden corner of the hard disk just waiting to get erased (just checked a random machine; 3241 files sum up to 380 MByte...)<br /></li><li>run something like "find /boot/ /etc/ /opt/ /usr/ /var/" with "-name '*.rpmnew'" "-name '*.rpmsave'"; go through the list of files find outputs, show a "diff -u" and offer the user to either<ul><br /><li>run tools like <a href="http://meld.sourceforge.net/">meld</a> or <a href="http://kdiff3.sourceforge.net/">kdiff3</a> to merge the files(¹) and remove the .rpm{new,save}-file afterwards<br /></li><li>replace the file with its .rpm{new,save}-pendant (or do it semi-automatically if sha1sums are identical)<br /></li><li>delete the .rpm{new,save}-file<br /></li><li>do nothing</li></ul><br /></li><li>a script that calls all the above tests as well as "package-cleanup" sequentially with the options "--problems", "--orphans", and "--dupes" to generate a report of "unusual" things<br /></li></ul>All my scripts are quite rough and not really ready for general consumption. But I wonder if it would be worth to collect scripts like these (a lot of users likely have similar scripts), pick the best ones, clean them up in a fedorahosted project and ship them in a package "rpmusrtools" within the fedora repositories.<br /><br /><span style="font-weight: bold;">Dear reader:</span> Would you find such a package useful? Or are there already such scripts/tools somewhere in the big Fedora package collection and I'm just not aware of them?<br /><br /><span style="font-size:85%;">(¹) that works quite well for a lot of config files, but breaks horrible for those that have lots of comments in them that try to explain each and every option and/or variable :-(( it get even worse if those comments change every few months.<br /><br />So this goes to the authors of dovecot, postfix, squid, and other software that has lots of comments in their default config files: "Config files are for configuration and should not contain lots of comments that get adjusted every few months, as those make it really hard to merge older (modified) config files with new one; in the future please consider to explain all option in a proper document like a man-page instead please and remove the comments from the config files! Thanks in advance! Yours truly, Thorsten Leemhuis"</span>Thorsten Leemhuishttp://www.blogger.com/profile/12285919704852601523noreply@blogger.com4tag:blogger.com,1999:blog-1447157631220361519.post-17502299914799220942009-02-13T07:47:00.008+01:002009-02-17T13:01:21.580+01:00rpm.livna.org is not deadrpm.livna.org is unreachable -- but that are just temporary DNS problems, so the rumors of livna's death are greatly exaggerated. rpm.livna.org will stay as a add-on to the repositories from <a href="http://rpmfusion.org/">RPM Fusion</a> for the foreseeable future.<br /><br />The rpm.livna.org mirrors still work and yum will automatically use one of them. You can find the release-rpm on mirrors like the one on <a href="http://ftp-stud.fht-esslingen.de/pub/Mirrors/">http://ftp-stud.fht-esslingen.de/pub/Mirrors/</a> in case you need it for a fresh Fedora install.<br /><br /><span style="font-weight: bold;">Update</span>: The DNS for livna.org will likely be unavailable for at least a few days, likely a week or more. So spread the news to make sure everyone is aware of the fact that rpm.linva.org is still alive and remains usable thanks to the mirrors.<br /><br /><span style="font-weight: bold;">Update2</span>: Use this command to enable livna on a fresh install:<br /><pre>su -c 'rpm -Uvh http://ftp-stud.fht-esslingen.de/pub/Mirrors/rpm.livna.org/livna-release.rpm'</pre>After that adjust the repo file to let it retrieve the mirrorlist from one of the mirrors:<br /><pre>su -c "sed -i 's|http://rpm.livna.org/mirrorlist|http://ftp-stud.fht-esslingen.de/pub/Mirrors/rpm.livna.org/mirrorlist|' /etc/yum.repos.d/livna.repo"</pre>The latter command should be used as workaround on exiting Fedora install as well if yum is unable to retrieve the mirrorlist!Thorsten Leemhuishttp://www.blogger.com/profile/12285919704852601523noreply@blogger.com9tag:blogger.com,1999:blog-1447157631220361519.post-58849898215137669772009-02-16T06:28:00.003+01:002009-02-16T06:38:49.314+01:00I really wish we could get rid of ".fcXY" as disttag in rawhideI really wish we would get rid of using ".fcXY" as disttag in rawhide because it <a href="https://www.redhat.com/archives/fedora-test-list/2009-February/msg00660.html">confuses way to many people</a> when they find packages with tags like "fc7" on their fresh rawhide install... Simply using ".1" as disttag imho would be the best solution.<br /><pre>$ rpmdev-vercmp 1.2-3.1 1.2-3-fc10<br />0:1.2-3.1 is newer</pre>Then packages that (for good reasons) don't get rebuild during one or two devel cycles don't have disttags from older fedora releases in their package names. But people didn't like it back when I proposed it some years ago. :-/ Hopefully someone sooner or later comes up with a better idea. ".fcn" for "Fedora Collections newest" maybe?<br /><pre>$ rpmdev-vercmp 1.2-3.fcn 1.2-3-fc10<br />0:1.2-3.fcn is newer</pre>Thorsten Leemhuishttp://www.blogger.com/profile/12285919704852601523noreply@blogger.com5tag:blogger.com,1999:blog-1447157631220361519.post-55527453450013439632009-01-22T19:28:00.003+01:002009-01-23T07:16:54.678+01:00Some notes on RHEL 5.3Congrats to the RHEL team for getting RHEL 5.3 out. Some random thoughts that sprung to my mind when looking closer at it:<br /><ul><li>The <a href="https://www.redhat.com/archives/rhelv5-announce/2009-January/msg00000.html">release announcement</a> (short), the <a href="http://www.redhat.com/f/pdf/rhel/RHEL_5p3_wp_0109_web.pdf">Red Hat Enterprise Linux 5.3 Technical Overview</a> (medium sized) and the <a href="http://www.redhat.com/docs/en-US/Red_Hat_Enterprise_Linux/5/html/Release_Notes/index.html">release notes</a> (all the details) are really great resources to see what's new in the latest RHEL release. I wish we had similar documents for each new Fedora release (yes, we have the release notes, but they contain a lot of boring details regular Fedora users already know).<br /></li><li>The kernel and dmraid in RHEL 5.3 now support dmraid 4/5/10. Alasdair, Heinz, others in RH: can you *please* speed up now to get <a href="http://people.redhat.com/%7Eheinzm/sw/dm/dm-raid45/">that code</a> (which is developed for quite some time now) upstream for Linux 2.6.30 to make sure it gets into Fedora 11 and from there into RHEL 6? I guess many users would be glad about that, as a lot of newer amd, intel and nvidia chipsets for desktop mainboards support RAID 5.<br /></li><li>Many thanks in advance to the CentOS folks that already started to work on CentOS 5.3<br /></li><li>I guess it will be an interesting comparison if somebody would compare the number of improvements (and their impact) that RHEL did between 5.2 and 5.3 with those that Ubuntu LTS 8.04.2 brings ;-) <span style="font-weight: bold;">[Update</span> 20090123]: Bad timing, 8.04.2 came out just a few hours after I wrote this; <a href="https://wiki.ubuntu.com/HardyReleaseNotes/ChangeSummary/8.04.2">list of changes is available</a> [<span style="font-weight: bold;">/Update]</span><br /></li></ul>Thorsten Leemhuishttp://www.blogger.com/profile/12285919704852601523noreply@blogger.com1tag:blogger.com,1999:blog-1447157631220361519.post-60582953562540292312009-01-18T20:25:00.002+01:002009-01-18T20:28:02.319+01:00Communication is important<b>Short version</b>: More and more decisions in <a href="http://fedoraproject.org/">Fedora</a> are done on IRC and in other places you have to be aware of; that itself would be no problem if the mailing lists would stay in the loop to make sure people cat raise their option before something is decided. But that's often not the case. The Fedora Project needs to improve here, as proper communication between contributors and those that make the decisions is a key factor for a community project.<br /><br /><b>Long version</b>: Cut'n'pasted below is a part from a post that some time ago was send to some random fedora mailing list by someone that's quite important in <a href="http://fedoraproject.org/">Fedora</a>:<br /><pre>I get the fact that you resent being in a timezone and location that<br />makes it difficult for you to participate in higher bandwidth forms of<br />communication (irc, phone, face to face). I can't help that. However<br />I'm not about to force the entire Fedora project slow to a crawl just so<br />that every thought, comment, discussion, fart, whatever happens via a<br />public email. That's just ridiculous. People will continue to talk on<br />IRC, will continue to chat via IM, will continue to talk on phones, and<br />will even *shock* talk in person! Ideas, proposals, and even a decision<br />or two, depending on the group, will be made in these ways. Deal with<br />it.</pre>Statements like this are one of the reasons why I'm not as active in Fedora anymore as I was two or three years ago.<br /><br />Sure, the one that wrote above para made a lot of good points. Face-to-face or IRC meetings are important and often help a lot to drive things forward. And we all afaics don't want a totally bureaucracy Fedora with hundreds of rules that express how decisions or other things have to be done; I actually tend to say we actually have way to many rules in some places already and need to get rid of a few (but that's a different topic).<br /><br />But in the end above para sounded to me: be on FUDCon, IRC, or right hallway at a specific time on a specific place on earth or you have no chance to influence things. It might not have been meant that way, but that's what my mind made out of when reading it. Partly that's because I got the impression that more and more things in Fedora actually work in a "be there at the right time and place if you want to get heard"-way. Obviously that's bad for a lot of contributors due to time zone differences, job, vacation, or other real life issues getting in the way; which, obviously again, is bad for a community project that has contributors from places spread all over the world, as it excludes some contributors from getting involved or from influencing decisions.<br /><br />That's why mailing lists (or a similar form of time-zone-independent communication) IMHO are very important for community projects with lots of contributors. But Fedora seems to move more and more things away from the public lists to other places -- especially IRC is used more and more desperate that we know there are people that don't want or can't join IRC.<br /><br />Moving things to IRC wouldn't be such a big problem if important things that come up for decision in IRC or other places get announced properly 2 or 3 days beforehand on the lists. But that's often not the case, hence people that can't make the meetings get no real chance to see what coming up -- hence they can't share their options before something is up for vote. But that's IMHO a very very important factor for a community project, as contributors want to feel "heard" and have a chance to influence stuff, as that makes them feel as part of the project (and not like a citizen of a state where you can elect the decision makers every few months or year) -- even if the outcome in the end is not what the contributor wanted initially, as everyone knows (or at least should) that you can't get everything you want every time (<a href="http://jeremy.zawodny.com/i/pony.jpg">a pony anyone?</a>).<br /><br />What makes things even worse: Now and then there are insufficient summaries from Fedora IRC meetings; the board is the big exception here while rel-eng often is not writing a summary at all. Sure, writing those summaries is a boring task -- I know that, as I had to write a lot of them for FESCo and the EPEL Steering Committee in the old days. But it's worth it, as a quick summary (even if it misses some details) is way easier to read then a log from a IRC meeting; that helps people to know what's up which again gives them the important feeling that they are part of the project. Not even trying to write summaries IMHO is a bit like top-posting and not removing unnecessary parts when replying to a mails on a mailing list: it might be easier and quicker for you, but a lot harder and time consuming for all those out there that want to know what's up. It shows disrespect for the community.<br /><br />Time and place independent communication also is not only important for IRC but also for conferences. That why I'd like to say "Thanks" to Karsten Wade aka quaid for his recent blog post "<a href="http://iquaid.org/2009/01/16/where-are-your-fudcon-session-notes/">Where are your FUDCon session notes?</a>". And also thanks to all those that put <a href="https://fedoraproject.org/wiki/FUDCon:FUDConF11_BarCamp_schedule">videos from the recent FUDCon sessions online</a>. Albeit those OTOH are a bit like IRC meetings without summaries -- watching them just like reading IRC meeting logs takes a lot of time and at least for me often has a bad "benefit per time ratio" :-/ . But as I said earlier: You can't always get what you want and this is a area where that's the case ;-)Thorsten Leemhuishttp://www.blogger.com/profile/12285919704852601523noreply@blogger.com1tag:blogger.com,1999:blog-1447157631220361519.post-37530956479409259392008-12-13T18:01:00.002+01:002008-12-13T18:08:13.981+01:00Fedora and support for new hardwareAs some people will know: At work I have to deal with brand new hardware (especially CPUs, graphic cards, motherboards, printers, scanners) a lot. One of the two(¹) main reasons why I (and some of my colleagues) use Fedora when it comes to test new hardware for compatibility with linux: Stable Fedora releases regularly get new versions of kernel, sane, xorg-drv-*, and some other hardware-related software as regular update during their lifetime; that improves support for hardware (and especially new hardware) a whole lot over time, as those updates to new versions also bring lots of new and updated drivers. OpenSuse or Ubuntu don't do things like that -- you are either forced to run the devel tree to get new drivers or you have to wait six to eight months till the next release comes out.<br /><br />But when I took a closer look at Fedora 10 I really was disappointed when I noticed that both gutenprint and hplip (likely the two most important packages with printer drivers) were far from up2date -- especially for gutenprint that sucked, as gutenprint 5.2.1 had brought support for <a href="http://www.heise-online.co.uk/news/Gutenprint-5-2-1-drivers-for-Linux-and-Mac-OS-X-improve-printer-support--/111788">a whole variety of new printers</a> one month before Fedora 10 came out. <br /><br />But that won't matter much anymore soon: <a href="http://cyberelk.net/tim/">Tim Waugh</a>(²), prepared updates for Fedora 10 that bring <a href="https://admin.fedoraproject.org/updates/F10/FEDORA-2008-10872">gutenprint</a> and <a href="https://admin.fedoraproject.org/updates/F10/FEDORA-2008-11236">hplip</a> up to the latest upstream version. Many thanks for your work twaught!<br /><br />Ohh, and while at it also many thx to davej, cebbert, kylem, ajax, nphilipp and all the other package maintainers that update packages like kernel, xorg-drv-*, sane, and others to the latest upstream versions now and then in stable releases. I (and I guess lot of people that buy new hardware now and then) really appreciate your work!<br /><br />(¹) the other: Fedora most of the time doesn't contain drivers or patches that are not yet upstream or on the way upstream. So if it works in Fedora then it most of the time should work on other dists that have the same or a higher version of software like kernel, xorg-drv*, ...<br /><br />(²) he seems to be a bit more cautiously than some of the Fedora packagers (not sure if that's good or bad) -- the maintainers of packages like kernel or openoffice.org for example had incorporated beta released of their software before the feature freeze and updated that to the final later. Hence that software was up2date when F10 came out; but that is likely a whole lot of work (which otoh helps both Fedora and upstream to get the software in better shape)Thorsten Leemhuishttp://www.blogger.com/profile/12285919704852601523noreply@blogger.com0tag:blogger.com,1999:blog-1447157631220361519.post-83337795193009657302008-12-02T18:25:00.004+01:002008-12-02T18:49:16.758+01:00New toyWe not only got <a href="http://thorstenl.blogspot.com/2008/11/number-3-ginger.html">a new cat</a> -- we (or, to be precise: my girlfriend) also got a netbook. A <a href="http://www.samsung.com/us/consumer/detail/features.do?group=computersperipherals&type=mobilecomputing&subtype=netbook&model_cd=NP-NC10-KA02US">Samsung NC10</a> in white:<br /><a onblur="try {parent.deselectBloggerImageGracefully();} catch(e) {}" href="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEjr8NRZv2vDKpFCDYSi9YEN7yR-ic1FdKYXcUcyd52LmHjKgENhTogAP-IzHEriN9EjMtTUsqLEHaEGcvVIbxP33I0hdUjWA-Nn-aEhLMAnJ5m3ay2xe8ZwGQyk15zJALzD5Do8FK5RFOA/s1600-h/nc10_004.jpg"><img style="margin: 0px auto 10px; display: block; text-align: center; cursor: pointer; width: 320px; height: 268px;" src="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEjr8NRZv2vDKpFCDYSi9YEN7yR-ic1FdKYXcUcyd52LmHjKgENhTogAP-IzHEriN9EjMtTUsqLEHaEGcvVIbxP33I0hdUjWA-Nn-aEhLMAnJ5m3ay2xe8ZwGQyk15zJALzD5Do8FK5RFOA/s320/nc10_004.jpg" alt="" id="BLOGGER_PHOTO_ID_5275247536021102546" border="0" /></a>The Fedora 10 installed just fine -- no problems at all. <a href="http://www.leemhuis.info/files/misc/dmesg-samsung-nc10.txt">Dmesg</a>, lspci:<br /><pre>00:00.0 Host bridge [0600]: Intel Corporation Mobile 945GME Express Memory Controller Hub [8086:27ac] (rev 03)<br /> Kernel driver in use: agpgart-intel<br />00:02.0 VGA compatible controller [0300]: Intel Corporation Mobile 945GME Express Integrated Graphics Controller [8086:27ae] (rev 03)<br />00:02.1 Display controller [0380]: Intel Corporation Mobile 945GM/GMS/GME, 943/940GML Express Integrated Graphics Controller [8086:27a6] (rev 03)<br />00:1b.0 Audio device [0403]: Intel Corporation 82801G (ICH7 Family) High Definition Audio Controller [8086:27d8] (rev 02)<br /> Kernel driver in use: HDA Intel<br /> Kernel modules: snd-hda-intel<br />00:1c.0 PCI bridge [0604]: Intel Corporation 82801G (ICH7 Family) PCI Express Port 1 [8086:27d0] (rev 02)<br /> Kernel driver in use: pcieport-driver<br />00:1c.2 PCI bridge [0604]: Intel Corporation 82801G (ICH7 Family) PCI Express Port 3 [8086:27d4] (rev 02)<br /> Kernel driver in use: pcieport-driver<br />00:1d.0 USB Controller [0c03]: Intel Corporation 82801G (ICH7 Family) USB UHCI Controller #1 [8086:27c8] (rev 02)<br /> Kernel driver in use: uhci_hcd<br />00:1d.1 USB Controller [0c03]: Intel Corporation 82801G (ICH7 Family) USB UHCI Controller #2 [8086:27c9] (rev 02)<br /> Kernel driver in use: uhci_hcd<br />00:1d.2 USB Controller [0c03]: Intel Corporation 82801G (ICH7 Family) USB UHCI Controller #3 [8086:27ca] (rev 02)<br /> Kernel driver in use: uhci_hcd<br />00:1d.3 USB Controller [0c03]: Intel Corporation 82801G (ICH7 Family) USB UHCI Controller #4 [8086:27cb] (rev 02)<br /> Kernel driver in use: uhci_hcd<br />00:1d.7 USB Controller [0c03]: Intel Corporation 82801G (ICH7 Family) USB2 EHCI Controller [8086:27cc] (rev 02)<br /> Kernel driver in use: ehci_hcd<br />00:1e.0 PCI bridge [0604]: Intel Corporation 82801 Mobile PCI Bridge [8086:2448] (rev e2)<br />00:1f.0 ISA bridge [0601]: Intel Corporation 82801GBM (ICH7-M) LPC Interface Bridge [8086:27b9] (rev 02)<br /> Kernel modules: iTCO_wdt, intel-rng<br />00:1f.2 IDE interface [0101]: Intel Corporation 82801GBM/GHM (ICH7 Family) SATA IDE Controller [8086:27c4] (rev 02)<br /> Kernel driver in use: ata_piix<br />00:1f.3 SMBus [0c05]: Intel Corporation 82801G (ICH7 Family) SMBus Controller [8086:27da] (rev 02)<br /> Kernel driver in use: i801_smbus<br /> Kernel modules: i2c-i801<br />02:00.0 Ethernet controller [0200]: Atheros Communications Inc. AR242x 802.11abg Wireless PCI Express Adapter [168c:001c] (rev 01)<br /> Kernel driver in use: ath5k_pci<br /> Kernel modules: ath5k<br />03:00.0 Ethernet controller [0200]: Marvell Technology Group Ltd. 88E8040 PCI-E Fast Ethernet Controller [11ab:4354] (rev 13)<br /> Kernel driver in use: sky2<br /> Kernel modules: sky2<br /></pre>I didn't test everything yet, but suspend, hibernate and wifi worked out of the the box. Regulating the display brightness does not work using the function keys -- but it works using the gnome-applet.<br /><br />Seems the wifi-LED does not work; and when I once disabled wifi using the hotkeys I could only get it to work again by restarting the system -- not sure, maybe it was just a hickup or something like that. I'll investigate further over the next few days.Thorsten Leemhuishttp://www.blogger.com/profile/12285919704852601523noreply@blogger.com1tag:blogger.com,1999:blog-1447157631220361519.post-21648982278133310392008-12-01T19:59:00.002+01:002008-12-01T20:05:51.321+01:00Read the same paragraphs every half year?I really wanted to read the <a href="http://docs.fedoraproject.org/release-notes/f10/en_US/">Fedora 10 Release Notes</a>, but when I did I quickly got distracted. Later I asked myself why and gave it a second try with the goal: watch closely why you got distracted.<br /><br />I first noticed that I had missed the <a href="http://docs.fedoraproject.org/release-notes/f10/en_US/index.html#sn-Fedora_10_overview">brief overview</a> at the bottom of the first page. I simply had hit "Next" on the top of the first page, as I expected it to be just the index, like it's iirc is in so many multiple-page howtos -- <a href="http://tldp.org/LDP/abs/html/">abs</a> is just a random example here.<br /><br />I further noticed that the text it a bit hard to read, as all the links are written in plain text within the text -- so you have to skip them with the eyes when you try to read continuously. To stress this a bit more compare yourself, which to you think is quicker and easier to read:<br /><ul><li>Features for Fedora 10 are tracked on the feature list page: <a href="http://www.fedoraproject.org/wiki/Releases/10/FeatureList">http://www.fedoraproject.org/wiki/Releases/10/FeatureList</a></li></ul><ul><li>Features for Fedora 10 are tracked on the <a href="http://www.fedoraproject.org/wiki/Releases/10/FeatureList">feature list page</a>.</li></ul>I then got to <a href="http://docs.fedoraproject.org/release-notes/f10/en_US/What_is_New_for_Installation_and_Live_Images.html#sn-Installation_notes">section 2.1</a> and read: "<b>Anaconda</b> is the name of the Fedora installer. This section outlines issues related to <b>Anaconda</b> and installing Fedora 10." I don't like the bold writing -- I find is distracting. But I know, some people like that. The real problem is something else and gets even more obvious in the whole <a href="http://docs.fedoraproject.org/release-notes/f10/en_US/What_is_New_for_Installation_and_Live_Images.html#sn-Installation_media">section 2.1.1</a>: Most if not all existing Fedora users know all of that already.<br /><br />And that IMHO is the big problem of the whole release notes. Sure, these information are important for new Fedora users and hence they need to be written somewhere. But these information are just boring for all the existing Fedora users out there. The new information between all the old and well know stuff on the other hand is very important to existing Fedora users -- we want them to read it (which most do not afaics). Thus I'm really wondering if we should provide a second version of the release notes that only provides information that are really new -- then users that come from the previous release only have to read that document, which like is a lot shorter.<br /><br />I'm not even sure how hard it would be to create that section release note set -- maybe running a diff over the old and new version, cut'n'past the relevant paragraphs where something important changed and put them into one document. <br /><br />P.S.: Another thing that I dislike in the Fedora 10 Release Notes: Why isn't there a single-page version online that would make searching something a whole lot easier. Example: I knew there was a paragraph in the release notes regarding the flash-plugin. Hence i browsed to the <a href="http://docs.fedoraproject.org/release-notes/f10/en_US/">Fedora 10 Release Notes Index</a>, typed "/flash" in Firefox to find it, but failed. I tried some other keywords like "plugin" and failed as well. After a while I gave up and asked Google with the search term "flash-plugin site:http://docs.fedoraproject.org/release-notes/f10/en_US/" -- then I quickly found what I was looking for. Works, but only is you know how to use Google properly :-/Thorsten Leemhuishttp://www.blogger.com/profile/12285919704852601523noreply@blogger.com1