<?xml version="1.0" encoding="UTF-8"?><rss version="2.0"
	xmlns:content="http://purl.org/rss/1.0/modules/content/"
	xmlns:dc="http://purl.org/dc/elements/1.1/"
	xmlns:atom="http://www.w3.org/2005/Atom"
	>
<channel>
	<title>Comments on: This is progress? (iftab vs. udev)</title>
	<atom:link href="http://bethesignal.org/blog/2008/04/16/this-is-progress-iftab-vs-udev/feed/" rel="self" type="application/rss+xml" />
	<link>http://bethesignal.org/blog/2008/04/16/this-is-progress-iftab-vs-udev/</link>
	<description>where we're going, we don't need roads...</description>
	<pubDate>Mon, 13 Oct 2008 12:51:45 +0000</pubDate>
	<generator>http://wordpress.org/?v=2.6.2</generator>
		<item>
		<title>By: Arf</title>
		<link>http://bethesignal.org/blog/2008/04/16/this-is-progress-iftab-vs-udev/#comment-3139</link>
		<dc:creator>Arf</dc:creator>
		<pubDate>Wed, 07 May 2008 02:20:59 +0000</pubDate>
		<guid isPermaLink="false">http://bethesignal.org/?p=1059#comment-3139</guid>
		<description>Reminds me of my favourite comment from a /etc file, also about needless complexity (SysV-ness in this case, from stock /etc/init.d/inetsvc on some version or other of Solaris):

# Run inetd in "standalone" mode (-s flag) so that it doesn't have
# to submit to the will of SAF.  Why did we ever let them change inetd?</description>
		<content:encoded><![CDATA[<p>Reminds me of my favourite comment from a /etc file, also about needless complexity (SysV-ness in this case, from stock /etc/init.d/inetsvc on some version or other of Solaris):</p>
<p># Run inetd in &#8220;standalone&#8221; mode (-s flag) so that it doesn&#8217;t have<br />
# to submit to the will of SAF.  Why did we ever let them change inetd?</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: Simone Deponti</title>
		<link>http://bethesignal.org/blog/2008/04/16/this-is-progress-iftab-vs-udev/#comment-3132</link>
		<dc:creator>Simone Deponti</dc:creator>
		<pubDate>Sun, 27 Apr 2008 00:13:26 +0000</pubDate>
		<guid isPermaLink="false">http://bethesignal.org/?p=1059#comment-3132</guid>
		<description>Uh, I remember ages ago I had a gentoo box I used as router, and not having mappings sucked.
So I dived into udev and came up with something that looks a lot like those new rules.
Even if it is ugly, it's better because udev can then be used to have all sorts of nice stuff, like permanent mappings of SCSI disks (by default, gentoo used to call the first "alive" disk /dev/sda, hence fucking up the fstab in case the first disk died), and this way you learn udev syntax.
Unified is better.</description>
		<content:encoded><![CDATA[<p>Uh, I remember ages ago I had a gentoo box I used as router, and not having mappings sucked.<br />
So I dived into udev and came up with something that looks a lot like those new rules.<br />
Even if it is ugly, it&#8217;s better because udev can then be used to have all sorts of nice stuff, like permanent mappings of SCSI disks (by default, gentoo used to call the first &#8220;alive&#8221; disk /dev/sda, hence fucking up the fstab in case the first disk died), and this way you learn udev syntax.<br />
Unified is better.</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: Jan de Groot</title>
		<link>http://bethesignal.org/blog/2008/04/16/this-is-progress-iftab-vs-udev/#comment-3100</link>
		<dc:creator>Jan de Groot</dc:creator>
		<pubDate>Wed, 16 Apr 2008 23:07:50 +0000</pubDate>
		<guid isPermaLink="false">http://bethesignal.org/?p=1059#comment-3100</guid>
		<description>Today I cloned a basic installation of debian using rsync onto another server. After rebooting, the initscripts told me that eth0 and eth1 were not present. Instead, my interfaces were named eth2 and eth3, because eth0 and eth1 were already taken by the dynamic generated udev rules.</description>
		<content:encoded><![CDATA[<p>Today I cloned a basic installation of debian using rsync onto another server. After rebooting, the initscripts told me that eth0 and eth1 were not present. Instead, my interfaces were named eth2 and eth3, because eth0 and eth1 were already taken by the dynamic generated udev rules.</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: Dan Nicholson</title>
		<link>http://bethesignal.org/blog/2008/04/16/this-is-progress-iftab-vs-udev/#comment-3099</link>
		<dc:creator>Dan Nicholson</dc:creator>
		<pubDate>Wed, 16 Apr 2008 18:10:12 +0000</pubDate>
		<guid isPermaLink="false">http://bethesignal.org/?p=1059#comment-3099</guid>
		<description>I don't know what Ubuntu does, but there was work done last year by the ifrename and udev maintainers to make ifrename take over the device renaming if it is present in iftab.

http://thread.gmane.org/gmane.linux.hotplug.devel/11089

It would seem to require wireless-tools-29 + udev-107 + a udev rule to run ifrename.</description>
		<content:encoded><![CDATA[<p>I don&#8217;t know what Ubuntu does, but there was work done last year by the ifrename and udev maintainers to make ifrename take over the device renaming if it is present in iftab.</p>
<p><a href="http://thread.gmane.org/gmane.linux.hotplug.devel/11089" rel="nofollow">http://thread.gmane.org/gmane.linux.hotplug.devel/11089</a></p>
<p>It would seem to require wireless-tools-29 + udev-107 + a udev rule to run ifrename.</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: martin</title>
		<link>http://bethesignal.org/blog/2008/04/16/this-is-progress-iftab-vs-udev/#comment-3097</link>
		<dc:creator>martin</dc:creator>
		<pubDate>Wed, 16 Apr 2008 16:21:29 +0000</pubDate>
		<guid isPermaLink="false">http://bethesignal.org/?p=1059#comment-3097</guid>
		<description>I think you *could* just add a shell script that reads iftab and gets called from udev.
But one of the design goals of udev is to avoid shell scripts in as many as possible cases for speed reasons. The old hotplug system is said to have wasted tons of time while booting by doing things with bash.

I don't really understand the whole udev bashing thing. I think udev is nicely flexible and only has minimal policy in the c code. It's basicly a big matching and dispatch engine. And still flexible because you can call out to programs when really needed. But is it worth to introduce a helper to read iftab and include iftab and the helper into the initramfs too? more places for things that need to go into initramfs isn't so great for usability either, is it?</description>
		<content:encoded><![CDATA[<p>I think you *could* just add a shell script that reads iftab and gets called from udev.<br />
But one of the design goals of udev is to avoid shell scripts in as many as possible cases for speed reasons. The old hotplug system is said to have wasted tons of time while booting by doing things with bash.</p>
<p>I don&#8217;t really understand the whole udev bashing thing. I think udev is nicely flexible and only has minimal policy in the c code. It&#8217;s basicly a big matching and dispatch engine. And still flexible because you can call out to programs when really needed. But is it worth to introduce a helper to read iftab and include iftab and the helper into the initramfs too? more places for things that need to go into initramfs isn&#8217;t so great for usability either, is it?</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: Quentin Hartman</title>
		<link>http://bethesignal.org/blog/2008/04/16/this-is-progress-iftab-vs-udev/#comment-3095</link>
		<dc:creator>Quentin Hartman</dc:creator>
		<pubDate>Wed, 16 Apr 2008 15:38:09 +0000</pubDate>
		<guid isPermaLink="false">http://bethesignal.org/?p=1059#comment-3095</guid>
		<description>I totally agree. I got hit by this change just the other day. I find it really irritating when important functional aspects of the system are silently changed. It leaves me scratching my head and looking foolish while I try to find a resolution to aproblem I _used_ to know how to handle. I don't agree that replacing a well understood and readable config file with less accessible one if a good thing, but if it must change, AT LEAST LET US KNOW THAT IT HAS CHANGED! Put it in detailed release notes, _something_!Leaving people to discover things like this while in the thick of it is just rude.</description>
		<content:encoded><![CDATA[<p>I totally agree. I got hit by this change just the other day. I find it really irritating when important functional aspects of the system are silently changed. It leaves me scratching my head and looking foolish while I try to find a resolution to aproblem I _used_ to know how to handle. I don&#8217;t agree that replacing a well understood and readable config file with less accessible one if a good thing, but if it must change, AT LEAST LET US KNOW THAT IT HAS CHANGED! Put it in detailed release notes, _something_!Leaving people to discover things like this while in the thick of it is just rude.</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: jdub</title>
		<link>http://bethesignal.org/blog/2008/04/16/this-is-progress-iftab-vs-udev/#comment-3094</link>
		<dc:creator>jdub</dc:creator>
		<pubDate>Wed, 16 Apr 2008 15:37:40 +0000</pubDate>
		<guid isPermaLink="false">http://bethesignal.org/?p=1059#comment-3094</guid>
		<description>@davidz: For the particular use case through which I discovered this change, I don't care about the name, nor find it interesting. But it needs to be consistent.

I realised a couple of weeks ago that it has been a &lt;em&gt;very&lt;/em&gt; long time indeed since I last edited &lt;tt&gt;/etc/network/interfaces&lt;/tt&gt; on any machine (thanks to dhcp everywhere and/or NetworkManager on desktops/laptops. :-)</description>
		<content:encoded><![CDATA[<p>@<a href="http://bethesignal.org/blog/2008/04/16/this-is-progress-iftab-vs-udev/#comment-3093">davidz</a>: For the particular use case through which I discovered this change, I don&#8217;t care about the name, nor find it interesting. But it needs to be consistent.</p>
<p>I realised a couple of weeks ago that it has been a <em>very</em> long time indeed since I last edited <tt>/etc/network/interfaces</tt> on any machine (thanks to dhcp everywhere and/or NetworkManager on desktops/laptops. <img src='http://bethesignal.org/wp-content/plugins/tango-smilies/tango/face-smile.png' alt=':-)' class='wp-smiley' width='16' height='16' /></p>
]]></content:encoded>
	</item>
	<item>
		<title>By: davidz</title>
		<link>http://bethesignal.org/blog/2008/04/16/this-is-progress-iftab-vs-udev/#comment-3093</link>
		<dc:creator>davidz</dc:creator>
		<pubDate>Wed, 16 Apr 2008 15:31:56 +0000</pubDate>
		<guid isPermaLink="false">http://bethesignal.org/?p=1059#comment-3093</guid>
		<description>Uhm. Is this a trick? I mean, why is the interface name _interesting_ and why do you _care_? The interface name is a freaking cookie and that's it. 

I mean, I'd understand if you are building some kind of 24/7 server with failover, bonding support etc. then you might need to run scripts in userland that needs a stable reference to a device.

Me? For things like laptops or desktops I stopped caring about things like network interface names ever since NetworkManager grew VPN support. So it's just been clickity-click for me since. With the occasional whining to Dan Williams's mom about Dan breaking NetworkManager of course ;-) 

Of course I'm setting myself up to be flamed here.</description>
		<content:encoded><![CDATA[<p>Uhm. Is this a trick? I mean, why is the interface name _interesting_ and why do you _care_? The interface name is a freaking cookie and that&#8217;s it. </p>
<p>I mean, I&#8217;d understand if you are building some kind of 24/7 server with failover, bonding support etc. then you might need to run scripts in userland that needs a stable reference to a device.</p>
<p>Me? For things like laptops or desktops I stopped caring about things like network interface names ever since NetworkManager grew VPN support. So it&#8217;s just been clickity-click for me since. With the occasional whining to Dan Williams&#8217;s mom about Dan breaking NetworkManager of course <img src='http://bethesignal.org/wp-content/plugins/tango-smilies/tango/face-wink.png' alt=';-)' class='wp-smiley' width='16' height='16' /> </p>
<p>Of course I&#8217;m setting myself up to be flamed here.</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: jdub</title>
		<link>http://bethesignal.org/blog/2008/04/16/this-is-progress-iftab-vs-udev/#comment-3092</link>
		<dc:creator>jdub</dc:creator>
		<pubDate>Wed, 16 Apr 2008 14:29:52 +0000</pubDate>
		<guid isPermaLink="false">http://bethesignal.org/?p=1059#comment-3092</guid>
		<description>@Scott James Remnant: Not possible to build udev rules out of &lt;tt&gt;/etc/iftab&lt;/tt&gt; at runtime?

@Joe Shaw: Yeah, that is pretty sucky, and a fairly good reason to consider keeping mildly  more human-grokkable files as 'frontend' configuration to udev rules.</description>
		<content:encoded><![CDATA[<p>@<a href="http://bethesignal.org/blog/2008/04/16/this-is-progress-iftab-vs-udev/#comment-3087">Scott James Remnant</a>: Not possible to build udev rules out of <tt>/etc/iftab</tt> at runtime?</p>
<p>@Joe Shaw: Yeah, that is pretty sucky, and a fairly good reason to consider keeping mildly  more human-grokkable files as &#8216;frontend&#8217; configuration to udev rules.</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: jdong</title>
		<link>http://bethesignal.org/blog/2008/04/16/this-is-progress-iftab-vs-udev/#comment-3091</link>
		<dc:creator>jdong</dc:creator>
		<pubDate>Wed, 16 Apr 2008 14:04:08 +0000</pubDate>
		<guid isPermaLink="false">http://bethesignal.org/?p=1059#comment-3091</guid>
		<description>The difference is that the file is in a *completely* nonobvious location for somebody who has been a Linux veteran and used to the /etc/iftab file for years.


iftab doesn't seen to make any mention that it's deprecated or one should see the latter udev file either.</description>
		<content:encoded><![CDATA[<p>The difference is that the file is in a *completely* nonobvious location for somebody who has been a Linux veteran and used to the /etc/iftab file for years.</p>
<p>iftab doesn&#8217;t seen to make any mention that it&#8217;s deprecated or one should see the latter udev file either.</p>
]]></content:encoded>
	</item>
</channel>
</rss>
