<?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"
	xmlns:sy="http://purl.org/rss/1.0/modules/syndication/"
	
	>
<channel>
	<title>
	Comments on: End of year HAMMER update	</title>
	<atom:link href="https://www.dragonflydigest.com/2008/01/02/end-of-year-hammer-update/feed/" rel="self" type="application/rss+xml" />
	<link>https://www.dragonflydigest.com/2008/01/02/end-of-year-hammer-update/</link>
	<description>A running description of activity related to DragonFly BSD.</description>
	<lastBuildDate>Tue, 08 Jan 2008 00:38:32 +0000</lastBuildDate>
	<sy:updatePeriod>
	hourly	</sy:updatePeriod>
	<sy:updateFrequency>
	1	</sy:updateFrequency>
	<generator>https://wordpress.org/?v=7.0</generator>
	<item>
		<title>
		By: Joe "Floid" Kanowitz		</title>
		<link>https://www.dragonflydigest.com/2008/01/02/end-of-year-hammer-update/comment-page-1/#comment-17608</link>

		<dc:creator><![CDATA[Joe "Floid" Kanowitz]]></dc:creator>
		<pubDate>Tue, 08 Jan 2008 00:38:32 +0000</pubDate>
		<guid isPermaLink="false">http://www.shiningsilence.com/dbsdlog/index.php/2008/01/02/2586.html#comment-17608</guid>

					<description><![CDATA[I think this has already been bikeshedded to death, but I&#039;m reminded...

In-band signaling seems really novel until the moment you encounter the nightmare situation of a filesystem with files containing the signaling characters.  @@ isn&#039;t a very common combination, but I&#039;m sure it must happen somewhere.

To keep the universe in alignment, it feels like there should be a mount option to turn that on or off, and the equivalent functionality available via the out-of-band &#039;mess of options&#039; technique (...or should we just grow a way to pass an &quot;options&quot; string straight through from tools and let filesystems eat it or ignore it?...)...

I also had this idea about using something like named pipes to access historical data (is that a job for varsyms?), but I&#039;m not sure how dangerously recursive that could get.  On the one hand, it seems like it should be possible/desirable to back those up or copy them around as references/symlinks, but on the other, if you&#039;re relying on a persistent pointer to historical data rather than copying or marking that data into the current working set you want to preserve....  [The FS could specifically preserve historical data that has open references, I guess, but then it has to keep track of all those, and if you remove and recreate the reference, you could be in for a nasty surprise...]

I&#039;ve been meaning to review the mailing lists and raise this there, but I&#039;ve had negative spare time in the past few months, so y&#039;all get an incoherent blog comment instead. ^^]]></description>
			<content:encoded><![CDATA[<p>I think this has already been bikeshedded to death, but I&#8217;m reminded&#8230;</p>
<p>In-band signaling seems really novel until the moment you encounter the nightmare situation of a filesystem with files containing the signaling characters.  @@ isn&#8217;t a very common combination, but I&#8217;m sure it must happen somewhere.</p>
<p>To keep the universe in alignment, it feels like there should be a mount option to turn that on or off, and the equivalent functionality available via the out-of-band &#8216;mess of options&#8217; technique (&#8230;or should we just grow a way to pass an &#8220;options&#8221; string straight through from tools and let filesystems eat it or ignore it?&#8230;)&#8230;</p>
<p>I also had this idea about using something like named pipes to access historical data (is that a job for varsyms?), but I&#8217;m not sure how dangerously recursive that could get.  On the one hand, it seems like it should be possible/desirable to back those up or copy them around as references/symlinks, but on the other, if you&#8217;re relying on a persistent pointer to historical data rather than copying or marking that data into the current working set you want to preserve&#8230;.  [The FS could specifically preserve historical data that has open references, I guess, but then it has to keep track of all those, and if you remove and recreate the reference, you could be in for a nasty surprise&#8230;]</p>
<p>I&#8217;ve been meaning to review the mailing lists and raise this there, but I&#8217;ve had negative spare time in the past few months, so y&#8217;all get an incoherent blog comment instead. ^^</p>
]]></content:encoded>
		
			</item>
	</channel>
</rss>
