FEED Validator

for Atom and RSS and KML

Congratulations!

This is a valid Atom 1.0 feed.

Recommendations

This feed is valid, but interoperability with the widest range of feed readers could be improved by implementing the following recommendations.

line 1, column 0: Use of unknown namespace: http://schemas.google.com/blogger/2008 [help]
```
<?xml version='1.0' encoding='UTF-8'?><?xml-stylesheet href="http://www.blog ...
```
line 1, column 0: Unable to validate namespace: http://schemas.google.com/g/2005. See the Google Data specification at https://developers.google.com/gdata/docs/1.0/elements [help]
```
<?xml version='1.0' encoding='UTF-8'?><?xml-stylesheet href="http://www.blog ...
```

line 1, column 1293: Self reference doesn't match document location [help]

... 31701633643336/posts/default?alt=atom'/><link rel='alternate' type='text ...
                                             ^

line 1, column 14346: content should not contain imageanchor attribute [help]

... sted) to iTerm2.&lt;br /&gt;&lt;br /&gt;</content><link rel='replies' ty ...
                                             ^

line 1, column 23277: style attribute contains potentially dangerous content: border-bottom-left-radius (8 occurrences) [help]

... ensure that your names resolve properly.</content><link rel='replies' ty ...
                                             ^

line 1, column 35362: content should not contain trbidi attribute (10 occurrences) [help]

... ted.&lt;br /&gt;&lt;br /&gt;&lt;/div&gt;</content><link rel='replies' ty ...
                                             ^

Source: http://gdamore.blogspot.com/atom.xml

<?xml version='1.0' encoding='UTF-8'?><?xml-stylesheet href="http://www.blogger.com/styles/atom.css" type="text/css"?><feed xmlns='http://www.w3.org/2005/Atom' xmlns:openSearch='http://a9.com/-/spec/opensearchrss/1.0/' xmlns:blogger='http://schemas.google.com/blogger/2008' xmlns:georss='http://www.georss.org/georss' xmlns:gd="http://schemas.google.com/g/2005" xmlns:thr='http://purl.org/syndication/thread/1.0'><id>tag:blogger.com,1999:blog-7528831701633643336</id><updated>2015-05-02T20:58:12.250-07:00</updated><category term="-"/><category term="--"/><category term="afe GLDv3"/><category term="atom"/><category term="blogger"/><category term="feedburner"/><category term="illumos arcmsr"/><category term="illumos gsoc"/><category term="joyent illumos zfs"/><category term="mxfe GLDv3"/><category term="oracle opensolaris"/><category term="rss"/><category term="sdcard"/><category term="zfs nexenta fma"/><title type='text'>/dev/dump</title><subtitle type='html'>illumos and storage. Rockets and whitewater. Go figure.</subtitle><link rel='http://schemas.google.com/g/2005#feed' type='application/atom+xml' href='http://garrett.damore.org/feeds/posts/default'/><link rel='self' type='application/atom+xml' href='http://www.blogger.com/feeds/7528831701633643336/posts/default?alt=atom'/><link rel='alternate' type='text/html' href='http://garrett.damore.org/'/><link rel='hub' href='http://pubsubhubbub.appspot.com/'/><link rel='next' type='application/atom+xml' href='http://www.blogger.com/feeds/7528831701633643336/posts/default?alt=atom&start-index=26&max-results=25'/><author><name>Garrett D'Amore</name><email>noreply@blogger.com</email><gd:image rel='http://schemas.google.com/g/2005#thumbnail' width='32' height='32' src='//lh3.googleusercontent.com/-3UzpztUh9YI/AAAAAAAAAAI/AAAAAAAADRI/7gIavrAWW5k/s512-c/photo.jpg'/></author><generator version='7.00' uri='http://www.blogger.com'>Blogger</generator><openSearch:totalResults>327</openSearch:totalResults><openSearch:startIndex>1</openSearch:startIndex><openSearch:itemsPerPage>25</openSearch:itemsPerPage><entry><id>tag:blogger.com,1999:blog-7528831701633643336.post-5822226322037061865</id><published>2015-05-02T17:35:00.001-07:00</published><updated>2015-05-02T17:35:09.966-07:00</updated><title type='text'>MacOS X 10.10.3 Update is *TOXIC*</title><content type='html'>As a PSA (public service announcement), I'm reporting here that updating your Yosemite system to 10.10.3 is incredibly toxic if you use WiFi.<br /><br />I've seen other reports of this, and I've experienced it myself. &nbsp;What happened is that the update for 10.10.3 seems to have done something tragically bad to the WiFi drivers, such that it completely hammers the network to the point of making it unusable for everyone else on the network.<br /><br />I have late 2013 iMac 27", and after I updated, I found that other systems started badly badly misbehaving. &nbsp;I blamed my ISP, and the router, because I was seeing ping times of tens of <i>seconds</i>!<br />(No, not milliseconds, <i>seconds!!!</i>&nbsp; In one case I saw responses over 64 seconds.) &nbsp;This was on other systems that were not upgraded. &nbsp;Needless to say, that basically left the network unusable.<br /><br />(The behavior was cyclical -- I'd get a few tens of seconds where pings to 8.8.8.8 would be in the 20 msec range, and then it would start to jump up very quickly until maxing up around a minute or so. &nbsp;It would stay there for a minute or two, then rest or drop back to sane times. &nbsp; But only very briefly.)<br /><br />This was most severe when using a 5GHz network. &nbsp;Switching down to 2.4GHz reduced some of the symptoms -- although still over 10 seconds to get traffic through and thoroughly unusable for a wide variety of applications.<br /><br />There are reports that disabling Bluetooth may alleviate this, and also some people reported some success with clearing certain settings files. &nbsp;I've not tried either of these yet. &nbsp;Google around for the answer if you want to. &nbsp;For now, my iMac 27" is powered off, until I can take the chance to disrupt the network again to try these "fixes".<br /><br />Apple, I'm seriously seriously disappointed here. &nbsp;I'm not sure at all how this testing got past you, but you need to fix this. &nbsp;Its absolutely criminal that applying a recommended update with security critical fixes in it should turn my computer into a DoS device for my local network. &nbsp;I'm shocked that several days later I've not seen a release update from Apple to fix this critical problem.<br /><br />Anyway, my advice is, if possible, hold off for the update to 10.10.3. &nbsp;Its tragically, horribly toxic not just to the upgraded device, but probably to the entire network it sits on. &nbsp;I'm a little astounded that a bug in the code could hose an entire WiFi network as badly as this does -- I would have previously thought this impossible (and this was part of the reason why it took a while to diagnose this down to the computer -- I thought the ridiculous ping responses had to be a problem with my upstream provider!)<br /><br />I'll post an update here if one becomes available.</content><link rel='replies' type='application/atom+xml' href='http://garrett.damore.org/feeds/5822226322037061865/comments/default' title='Post Comments'/><link rel='replies' type='text/html' href='http://www.blogger.com/comment.g?blogID=7528831701633643336&postID=5822226322037061865' title='1 Comments'/><link rel='edit' type='application/atom+xml' href='http://www.blogger.com/feeds/7528831701633643336/posts/default/5822226322037061865'/><link rel='self' type='application/atom+xml' href='http://www.blogger.com/feeds/7528831701633643336/posts/default/5822226322037061865'/><link rel='alternate' type='text/html' href='http://garrett.damore.org/2015/05/macos-x-10103-update-is-toxic.html' title='MacOS X 10.10.3 Update is *TOXIC*'/><author><name>Garrett D'Amore</name><uri>https://plus.google.com/101751336283999515602</uri><email>noreply@blogger.com</email><gd:image rel='http://schemas.google.com/g/2005#thumbnail' width='32' height='32' src='//lh3.googleusercontent.com/-iK1shT81XTE/AAAAAAAAAAI/AAAAAAAAAJA/MSN7V7X_7mM/s512-c/photo.jpg'/></author><thr:total>1</thr:total></entry><entry><id>tag:blogger.com,1999:blog-7528831701633643336.post-8778211508689408995</id><published>2015-04-14T11:13:00.002-07:00</published><updated>2015-04-14T11:13:18.947-07:00</updated><title type='text'>vtprint - blast from the past</title><content type='html'>I recently decided to have a look back at some <i>old</i>&nbsp;stuff I wrote. &nbsp;Blast from the past stuff. &nbsp;One of the things I decided to look at was the very first open source program I wrote -- something called <b><i><a href="https://github.com/gdamore/vtprint">vtprint</a></i></b>.<br /><br /><i><b>vtprint</b></i> is a tool that borrowed ideas stolen from the pine mail program. &nbsp;This comes from the days of serial dialups, and legacy (<a href="http://www.columbia.edu/kermit/mskermit.html">Kermit</a>&nbsp;or <a href="http://www.procomm-guide.com/">ProComm</a> for those who remember such things) serial connectivity over 14.4K modems. &nbsp;Printing a file on a remote server was hard back then; you could transfer the file using <a href="http://en.wikipedia.org/wiki/XMODEM">xmodem</a> using rx(1), or its "newer" variants, rb(1) or rz(1), but this was awkward. &nbsp;It turns out that most physical terminals had support for an escape sequence that would start hardcopy to a locally attached printer, and another that would stop it. &nbsp;And indeed, many terminal emulators have the same support. &nbsp;(I added support for this myself to the <a href="http://rxvt.sourceforge.net/">rxvt</a>(1) terminal emulator back in the mid 90's, so any emulators derived from rxvt inherit this support as well.)<br /><br />So vtprint, which in retrospect could have been written in a few lines of shell code, is a C program. &nbsp;It supports configuration via a custom file called "vtprintcap", that can provide information about different $TERM values and the escape sequences they use. &nbsp;So for example, TVI925 terminals use a different escape sequence than VT100 or VT220 terminals.<br /><br />The first version of it, 1.0, is lost in time, and was written back in 1991 or 1992 while I was working as a "Computer Consultant" (fancy name for <a href="http://bofh.ntk.net/BOFH/">BOFH</a>, though I also did a lot of programming for the school's Windows 3.1 network and Novell NetWare 3.12 server) at the <a href="http://www.haas.berkeley.edu/">Haas School of Business at UC Berkeley</a>. &nbsp;(I was a Chemical Engineering student there, and I flunked out in thermodynamics -- I still blame <a href="http://en.wikipedia.org/wiki/Gibbs_free_energy">Gibbs Free Energy</a>&nbsp;ΔG as a concept I never truly could get my mind around. &nbsp;It took a couple of years before I finally gave up fighting "hard engineering" and accepted my true calling as a software engineer.)<br /><br />Anyway, I transferred to <a href="http://www.sdsu.edu/">SDSU</a> into the Computer Science department. &nbsp;While there, back in 1993, I updated vtprint significantly, and that is the release that lives on at SourceForge.<br /><br />Today I imported that project to <a href="https://github.com/gdamore/vtprint">github</a>. &nbsp;(And let me tell you, it took some hoops to do this. &nbsp;Apparently all the old CVS projects that were going to have converted to CVS are supposed to already have done so, because at this point even the conversion tools are mostly crufty and broken. &nbsp;Maybe I'll post what I did there.) &nbsp;Most of the files indicate an age of 11 years ago. &nbsp;That's because 11 years ago I imported the source into CVS for the benefit of <a href="http://vtprint.sourceforge.net/">SourceForge</a>. &nbsp;The actual files date back to 1994, and you can even see my old email address -- which hasn't worked for a couple of decades, in the files.<br /><br />So, I gave vtprint a whirl today for the first time in years:<br /><br /><blockquote class="tr_bq"><span style="font-family: Verdana, sans-serif; font-size: x-small;">garrett@hipster{4}&gt; ./vtprint README</span><span style="font-family: Verdana, sans-serif; font-size: x-small;"><br /></span><span style="font-family: Verdana, sans-serif; font-size: x-small;">*** vtprint (v2.0.2) ***</span><span style="font-family: Verdana, sans-serif; font-size: x-small;"><br /></span><span style="font-family: Verdana, sans-serif; font-size: x-small;">Copyright 1993-1994, Garrett D'Amore</span><span style="font-family: Verdana, sans-serif; font-size: x-small;">Last revised October 25, 1994.</span><span style="font-family: Verdana, sans-serif; font-size: x-small;"><br /></span><span style="font-family: Verdana, sans-serif; font-size: x-small;">NO WARRANTY! &nbsp;Use "vtprint -w" for info.</span><span style="font-family: Verdana, sans-serif; font-size: x-small;">Freely redistributable. &nbsp;Use "vtprint -l" for info.</span><span style="font-family: Verdana, sans-serif; font-size: x-small;"><br /></span><span style="font-family: Verdana, sans-serif; font-size: x-small;">vtprint: Can't open /usr/local/lib/vtprint/vtprintcap, using builtin codes.</span><span style="font-family: Verdana, sans-serif; font-size: x-small;">vtprint: Using &lt;stdout&gt; for output.</span><span style="font-family: Verdana, sans-serif; font-size: x-small;">vtprint: Output flags: formfeed</span><span style="font-family: Verdana, sans-serif; font-size: x-small;">vtprint: Printed README.</span><span style="font-family: Verdana, sans-serif; font-size: x-small;">vtprint: Successfully printed 1 file (1 specified).</span></blockquote><br />Sadly, MacOS X Terminal.app does not appear to emulate the escape sequences properly. &nbsp;But <a href="http://iterm2.com/">iTerm2</a> does so very nicely. &nbsp;It even generates a nice print preview using the standard MacOS X print dialog. &nbsp;Sadly, it does not pass through PostScript unmolested, but for printing ASCII files it works beautifully. <br /><div class="separator" style="clear: both; text-align: center;"><a href="http://3.bp.blogspot.com/-8mJXpUuLDrI/VS1Wn3zM1lI/AAAAAAAAAPk/yxUILtO8-rs/s1600/Screen%2BShot%2B2015-04-14%2Bat%2B10.59.52%2BAM.png" imageanchor="1" style="margin-left: 1em; margin-right: 1em;"><img border="0" src="http://3.bp.blogspot.com/-8mJXpUuLDrI/VS1Wn3zM1lI/AAAAAAAAAPk/yxUILtO8-rs/s1600/Screen%2BShot%2B2015-04-14%2Bat%2B10.59.52%2BAM.png" height="320" width="278" /></a></div><br />I think that I'm going to start using vtprint again, when I need to print a file located on a virtual machine, or over a connection that only offers SSH (such as a secured access machine). &nbsp;With firewalled networks, I suspect that this program has new usefulness. &nbsp;I'm also switching from Terminal.app (as many people have suggested) to iTerm2.<br /><br /></content><link rel='replies' type='application/atom+xml' href='http://garrett.damore.org/feeds/8778211508689408995/comments/default' title='Post Comments'/><link rel='replies' type='text/html' href='http://www.blogger.com/comment.g?blogID=7528831701633643336&postID=8778211508689408995' title='0 Comments'/><link rel='edit' type='application/atom+xml' href='http://www.blogger.com/feeds/7528831701633643336/posts/default/8778211508689408995'/><link rel='self' type='application/atom+xml' href='http://www.blogger.com/feeds/7528831701633643336/posts/default/8778211508689408995'/><link rel='alternate' type='text/html' href='http://garrett.damore.org/2015/04/vtprint-blast-from-past.html' title='vtprint - blast from the past'/><author><name>Garrett D'Amore</name><uri>https://plus.google.com/101751336283999515602</uri><email>noreply@blogger.com</email><gd:image rel='http://schemas.google.com/g/2005#thumbnail' width='32' height='32' src='//lh3.googleusercontent.com/-iK1shT81XTE/AAAAAAAAAAI/AAAAAAAAAJA/MSN7V7X_7mM/s512-c/photo.jpg'/></author><media:thumbnail xmlns:media="http://search.yahoo.com/mrss/" url="http://3.bp.blogspot.com/-8mJXpUuLDrI/VS1Wn3zM1lI/AAAAAAAAAPk/yxUILtO8-rs/s72-c/Screen%2BShot%2B2015-04-14%2Bat%2B10.59.52%2BAM.png" height="72" width="72"/><thr:total>0</thr:total></entry><entry><id>tag:blogger.com,1999:blog-7528831701633643336.post-3253875900774655656</id><published>2015-02-22T11:48:00.000-08:00</published><updated>2015-02-22T13:07:37.116-08:00</updated><title type='text'>IPv6 and IPv4 name resolution with Go</title><content type='html'>As part of a work-related project, I'm writing code that needs to resolve DNS names using <a href="http://golang.org/">Go</a>, on <a href="http://www.illumos.org/">illumos</a>.<br /><br />While doing this work, I noticed a very surprising thing. &nbsp;When a host has both IPv6 and IPv4 addresses associated with a name (such as <i>localhost</i>), Go prefers to resolve to the IPv4 version of the name, unless one has asked specifically for v6 names.<br /><br />This flies in the fact of existing practice on illumos &amp; Solaris systems, where resolving a name tends to give an IPv6 result, assuming that any IPv6 address is plumbed on the system. &nbsp;(And on modern installations, that is the default -- at least the loopback interface of ::1 is always plumbed by default. &nbsp;And not only that, but services listening on that address will automatically serve up both v6 and v4 clients that connect on either ::1 or 127.0.0.1.)<br /><br />The rationale for this logic is buried in the Go <a href="https://golang.org/src/net/ipsock.go"><span style="font-family: inherit;">net/ipsock.go</span></a> file, in comments for the function <span style="font-family: inherit;"><a href="https://golang.org/src/net/ipsock.go#L67">firstFavoriteAddr</a>&nbsp;()</span>:<br /><pre style="background-color: #e9e9e9; border-bottom-left-radius: 5px; border-bottom-right-radius: 5px; border-top-left-radius: 5px; border-top-right-radius: 5px; color: #222222; line-height: 18px; margin: 20px; padding: 10px;"><span style="font-family: Verdana, sans-serif;"><span class="ln" id="L76" style="color: #999999;"><span style="font-size: 14px;"> </span><span style="font-size: x-small;"> 76</span></span><span style="font-size: x-small;"> <span class="comment" style="color: #006600;">// We'll take any IP address, but since the dialing</span><br /><span class="ln" id="L77" style="color: #999999;"> 77</span> <span class="comment" style="color: #006600;">// code does not yet try multiple addresses</span><br /><span class="ln" id="L78" style="color: #999999;"> 78</span> <span class="comment" style="color: #006600;">// effectively, prefer to use an IPv4 address if</span><br /><span class="ln" id="L79" style="color: #999999;"> 79</span> <span class="comment" style="color: #006600;">// possible. This is especially relevant if localhost</span><br /><span class="ln" id="L80" style="color: #999999;"> 80</span> <span class="comment" style="color: #006600;">// resolves to [ipv6-localhost, ipv4-localhost]. Too</span><br /><span class="ln" id="L81" style="color: #999999;"> 81</span> <span class="comment" style="color: #006600;">// much code assumes localhost == ipv4-localhost.</span></span></span></pre>This is a really surprising result. &nbsp;If you want to get IPv6 names by default, with Go, you could use the <span style="font-family: inherit;"><a href="http://golang.org/pkg/net/#ResolveIPAddr">net.ResolveIPAddr</a>() (or <a href="http://golang.org/pkg/net/#ResolveTCPAddr">ResolveTCPAddr</a>() or <a href="http://golang.org/pkg/net/#ResolveUDPAddr">ResolveUDPAddr</a>())</span> functions with the network type of "ip6", "tcp6", or "udp6" first. &nbsp;Then if that resolution fails, you can try the standard versions, or the v4 specific versions (doing the latter is probably slightly more efficient.) &nbsp;Here's what that code looks like:<br /><pre style="background-color: #e9e9e9; border-bottom-left-radius: 5px; border-bottom-right-radius: 5px; border-top-left-radius: 5px; border-top-right-radius: 5px; line-height: 18px; margin: 20px; padding: 10px;"><span style="font-family: Verdana, sans-serif;"><span style="font-size: x-small;"><span style="color: #222222;"> name := "</span><span style="color: #6fa8dc;">localhost</span><span style="color: #222222;">"<br /><br /> </span><span style="color: #38761d;"><span class="comment">// First we try IPv6. &nbsp;Note that we *hope* this fails if the host</span><br /> <span class="comment">// stack does not actually support IPv6.</span><br /></span><span style="color: #222222;"> err, ip := net.ResolveIP("</span><span style="color: #6fa8dc;">ip6</span><span style="color: #222222;">", name)<br /> if err != nil {<br /> </span><span class="comment" style="color: #38761d;">// IPv6 not found, maybe IPv4?</span><span style="color: #222222;"><br /> err, ip = net.ResolveIP("</span><span style="color: #6fa8dc;">ip4</span></span><span style="color: #222222;"><span style="font-size: x-small;">", name)<br /> }</span><span style="font-size: xx-small;"><br /></span></span></span></pre>However, this choice turns out to also be <i>evil</i>, because while ::1 often works locally as an IPv6 address and is functional, other addresses, for example www.google.com, will resolve to IPv6 addresses which will <i>not</i>&nbsp;work unless you have a clean IPv6 path all the way through. &nbsp;For example, the above gives me this for www.google.com:&nbsp;2607:f8b0:4007:804::1010, but if I try to telnet to it, it won't work -- no route to host (of course, because I don't have an IPv6 path to the Internet, both my home gateway and my ISP are IPv4 only.)<br /><br /><br />Its kind of a sad that the Go people felt that they had to make this choice -- at some level it robs the choice from the administrator, and encourages the existing broken code to remain so. &nbsp;I'm not sure what the other systems use, but at least on illumos, we have a stack that understands the situation, and resolves <i>optimally</i>&nbsp;for the given the situation of the user. &nbsp;Sadly, Go shoves that intelligence aside, and uses its own overrides.<br /><br />One moral of the story here is -- always use either explicit v4 or v6 addresses if you care, or ensure that your names resolve properly.</content><link rel='replies' type='application/atom+xml' href='http://garrett.damore.org/feeds/3253875900774655656/comments/default' title='Post Comments'/><link rel='replies' type='text/html' href='http://www.blogger.com/comment.g?blogID=7528831701633643336&postID=3253875900774655656' title='1 Comments'/><link rel='edit' type='application/atom+xml' href='http://www.blogger.com/feeds/7528831701633643336/posts/default/3253875900774655656'/><link rel='self' type='application/atom+xml' href='http://www.blogger.com/feeds/7528831701633643336/posts/default/3253875900774655656'/><link rel='alternate' type='text/html' href='http://garrett.damore.org/2015/02/ipv6-and-ipv4-name-resolution-with-go.html' title='IPv6 and IPv4 name resolution with Go'/><author><name>Garrett D'Amore</name><uri>https://plus.google.com/101751336283999515602</uri><email>noreply@blogger.com</email><gd:image rel='http://schemas.google.com/g/2005#thumbnail' width='32' height='32' src='//lh3.googleusercontent.com/-iK1shT81XTE/AAAAAAAAAAI/AAAAAAAAAJA/MSN7V7X_7mM/s512-c/photo.jpg'/></author><thr:total>1</thr:total></entry><entry><id>tag:blogger.com,1999:blog-7528831701633643336.post-1317329752004791569</id><published>2015-02-11T21:35:00.001-08:00</published><updated>2015-02-11T21:35:58.661-08:00</updated><title type='text'>Rise of mangos</title><content type='html'><h2><i>What is mangos?</i></h2><br />Those of you who follow me may have heard about this project I've created called <a href="http://github.com/gdamore/mangos">mangos</a>.<br /><br />Mangos is a lightweight messaging system designed to be wire compatible with <a href="http://www.nanomsg.org/">nanomsg</a>, but is implemented entirely in <a href="http://www.golang.org/">Go</a>.<br /><br />There is a very nice <a href="http://www.bravenewgeek.com/fast-scalable-networking-in-go-with-mangos/">write up</a> of mangos by Tyler Treat, which might help explain some things.<br /><br /><h3><i>Recent Activity</i></h3><div><i><br /></i></div>As a consequence of a few things, the last two weeks has seen a substantial rise of use of mangos. <br /><br />First off, there was Tyler's excellent article. &nbsp;(By the way, he's done a series comparing and contrasting other messaging systems -- highly recommended reading.)<br /><br />Second, mangos got mentioned on <a href="https://news.ycombinator.com/">Hacker News</a>. &nbsp;That drew a large number visitors to my github repo.<br /><br />Then another open source project, <a href="https://github.com/glycerine/goq">Goq</a>, switched from using libnanomsg to mangos, using the compatibility shim I provided for such use. &nbsp;As a consequence of that work, several bugs were identified, and subsequently squashed.<br /><br />The upshot of all that is that I saw the number unique visitors sky rocket. &nbsp;On Saturday Feb 7, there were over <a href="https://github.com/gdamore/mangos/graphs/traffic">2500 unique visitors</a> to the github page, and 29 unique people took clones. &nbsp;Sunday it tapered sharply to just over 1k visitors, and today there were only 7. &nbsp;Peaks rarely get sharper than that.<br /><br /><h3><i>Improvements</i></h3><br />Over the past week or so I've made a large number of changes and improvements. &nbsp;Recently, mangos has grown support for <a href="https://tools.ietf.org/html/rfc6455">RFC 6455</a> (websocket), including websocket over <a href="http://www.ietf.org/rfc/rfc5246.txt">TLS</a>, and has had numerous internal improvements.<br /><br />Some of these changes have broken API. &nbsp;If you use mangos, I'm sorry about the breakage -- please let me know if you're hurt by this. &nbsp;(I have created tagged releases for v1.0.0 and v1.1.0 in an attempt to mitigate the risk, but tip still has some interesting changes in it.)<br /><br />Unlike libnanomsg, mangos (tip only) can notify you when a connection is added or removed, and you can access interesting information about the connection. &nbsp;This is in the <a href="http://godoc.org/github.com/gdamore/mangos#Port">Port API</a>.<br /><br /><h3><i>Futures</i></h3><br />We are using mangos internally at Lucera, and I know now of several cases of production use. &nbsp;This is kind of scary at one level, since I wrote this originally as a hobby project about a year ago (to learn Go.) &nbsp;But it has become useful -- frankly extending mangos is far far more pleasurable than working in the C libnanomsg implementation -- a lot of this is thanks to Go which is utterly pleasurable to work in (no matter how bad the guts may be reputed to be). &nbsp;Being able to write a new TLS transport, or even websocket, in the course of an afternoon or two (actually for TLS it was more like an hour), is really nice.<br /><br />I'm hoping that more people will find it useful, and that folks who want to experiment with the underlying messaging patterns may find it easier to work with than the C code. &nbsp;Ideally, there will be more collaborators here, as we start exploring new directions for this stuff.<br /><br />In the meantime, I'm going to continue to work to improve and extend mangos, because its become one of the tools at my day job. &nbsp;Its nice when work and pleasure come together!</content><link rel='replies' type='application/atom+xml' href='http://garrett.damore.org/feeds/1317329752004791569/comments/default' title='Post Comments'/><link rel='replies' type='text/html' href='http://www.blogger.com/comment.g?blogID=7528831701633643336&postID=1317329752004791569' title='0 Comments'/><link rel='edit' type='application/atom+xml' href='http://www.blogger.com/feeds/7528831701633643336/posts/default/1317329752004791569'/><link rel='self' type='application/atom+xml' href='http://www.blogger.com/feeds/7528831701633643336/posts/default/1317329752004791569'/><link rel='alternate' type='text/html' href='http://garrett.damore.org/2015/02/rise-of-mangos.html' title='Rise of mangos'/><author><name>Garrett D'Amore</name><uri>https://plus.google.com/101751336283999515602</uri><email>noreply@blogger.com</email><gd:image rel='http://schemas.google.com/g/2005#thumbnail' width='32' height='32' src='//lh3.googleusercontent.com/-iK1shT81XTE/AAAAAAAAAAI/AAAAAAAAAJA/MSN7V7X_7mM/s512-c/photo.jpg'/></author><thr:total>0</thr:total></entry><entry><id>tag:blogger.com,1999:blog-7528831701633643336.post-845552299681278252</id><published>2014-11-13T09:33:00.000-08:00</published><updated>2014-11-13T09:33:21.082-08:00</updated><title type='text'>A better illumos...</title><content type='html'><div dir="ltr" style="text-align: left;" trbidi="on">If you follow <a href="http://www.illumos.org/">illumos</a> very closely, you may already know some of this.<br /><br /><h3 style="text-align: left;">A New Fork</h3><br />Several months ago, I forked <a href="https://github.com/illumos/illumos-gate">illumos-gate</a> (the primary source code repository for the kernel and system components of illumos) into <a href="https://github.com/gdamore/illumos-core">illumos-core</a>.<br /><br />I had started upstreaming my work from illumos-core into illumos-gate. &nbsp;I've since ceased that effort, largely because I simply have no time for the various arguments that my work often generates. &nbsp;I think this is largely because my <a href="https://github.com/gdamore/illumos-core/wiki/illumos-core-vision">vision</a> for illumos is somewhat different from that of other folks, and sadly illumos proper lacks anything resembling a guiding vision now, which means that only entirely non-contentious changes can get integrated into illumos. <br /><br />However, I still want to proceed apace with illumos-core, because I believe that work has real value, and I firmly believe that my vision for illumos is the one that will lead to greater adoption by users, and by distributors as well, since much of what I'm trying to achieve in illumos-gate is aimed at reducing barriers to adoption and to developers both of illumos itself and of systems that want to build on top of or integrate illumos. &nbsp;(An example of reducing barriers to adoption -- I recently <a href="https://github.com/gdamore/illumos-core/commit/c79874d0f161eb999ce69cc8921a0b9a4294a710">implemented a BSD compatible flock() within libc</a>, which is sometimes used by applications developed for BSD or Linux.)<br /><br /><h3 style="text-align: left;">Relationship to Upstream</h3><br />I do also invite other parties to cherry-pick from illumos-core into illumos-gate. &nbsp;I suspect that a large number of the enhancements I've made, such as the support for the <a href="https://github.com/gdamore/illumos-core/issues/88">fexecve</a>() function <a href="http://pubs.opengroup.org/onlinepubs/9699919799/functions/exec.html">specified</a> by POSIX 2008, are likely to be more widely useful. &nbsp;Within illumos-core, I want to retain a high standard of quality, and facilitate the effort of upstreaming for those who want to make the effort to do so.<br /><br />I do want to reiterate that unlike other projects that have forked from illumos, it is not my intent to divorce myself from the community -- rather I see this illumos-core as an experimental branch aimed at exploring new directions that I ultimately hope will be embraced by the wider illumos community some day; by doing this in a separate repository/branch/fork, illumos-core can drive towards these goals without getting mired in questions that would prevent progress on these goals within illumos-gate proper.<br /><br />The focus here is on delivery, rather than on discussion. &nbsp;(In fact, one of my taglines on social media has for many years been "<a href="https://www.openhub.net/accounts/gdamore">Code first, questions later</a>." &nbsp;The illumos-core effort represents a return to that core value.)<br /><br /><h3 style="text-align: left;">Call for Participation</h3><br />I'm also interested in having co-collaborators on this project. &nbsp;The goals are large, and while I hope to achieve them someday even if I have to do it all myself, I'm certain that the project will move quite a lot faster with help. &nbsp;Also, because of our lack of bureaucracy, I hope that illumos-core can be an easier path to integration than illumos-gate. &nbsp;I just use a simple <a href="http://www.github.com/">github</a> pull-request for integration at present.<br /><br />There is an opportunity for folks at all different technical levels to participate. &nbsp;We need work that involves systems programming, but also there is work around documentation, research, shell scripting, test development and release engineering to be performed. &nbsp;I'm happy to mentor folks who want to help out, based on their skill level.<br /><br />And, of course, for folks who want to focus primarily on improving illumos-gate upstream, there is effort that could be spent to figure out what to cherry-pick and to do the various illumos-gate process wrangling steps to get those bits integrated.<br /><br /></div></content><link rel='replies' type='application/atom+xml' href='http://garrett.damore.org/feeds/845552299681278252/comments/default' title='Post Comments'/><link rel='replies' type='text/html' href='http://www.blogger.com/comment.g?blogID=7528831701633643336&postID=845552299681278252' title='0 Comments'/><link rel='edit' type='application/atom+xml' href='http://www.blogger.com/feeds/7528831701633643336/posts/default/845552299681278252'/><link rel='self' type='application/atom+xml' href='http://www.blogger.com/feeds/7528831701633643336/posts/default/845552299681278252'/><link rel='alternate' type='text/html' href='http://garrett.damore.org/2014/11/a-better-illumos.html' title='A better illumos...'/><author><name>Garrett D'Amore</name><uri>https://plus.google.com/114484106466928611830</uri><email>noreply@blogger.com</email><gd:image rel='http://schemas.google.com/g/2005#thumbnail' width='32' height='32' src='//lh3.googleusercontent.com/-3UzpztUh9YI/AAAAAAAAAAI/AAAAAAAADRI/7gIavrAWW5k/s512-c/photo.jpg'/></author><thr:total>0</thr:total></entry><entry><id>tag:blogger.com,1999:blog-7528831701633643336.post-8778482429302443995</id><published>2014-10-17T23:20:00.002-07:00</published><updated>2014-10-17T23:20:57.527-07:00</updated><title type='text'>Your language sucks...</title><content type='html'><div dir="ltr" style="text-align: left;" trbidi="on">As a result of work I've been doing for <a href="http://www.illumos.org/">illumos</a>, I've recently gotten re-engaged with internationalization, and the support for this in libc and localedef (I am the original author for our localedef.)<br /><br />I've decided that human languages suck. &nbsp;Some suck worse than others though, so I thought I'd write up a guide. &nbsp;You can take this as "your language sucks if...", or perhaps a better view might be "your program sucks if you make assumptions this breaks..."<br /><br />(Full disclosure, I'm spoiled. &nbsp;I am a native speaker of English. &nbsp;English is pretty awesome for data-processing, at least at the written level. &nbsp;I'm not going to concern myself with questions about deeper issues like grammar, natural language recognition, speech synthesis, or recognition, automatic translation, etc. &nbsp;Instead this is focused strictly on the most basic display and simple operations like collation (sorting), case conversion, and character classification.)<br /><h2 style="text-align: left;">1. Too many code points.&nbsp;</h2>Some languages (from Eastern Asia) have way way too many code points. &nbsp;There are so many that these languages can't actually fit into 16-bits all by themselves. &nbsp;Yes, I'm saying that there are languages with over 65,000 characters in them! &nbsp;This explosion means that generating data for languages results in intermediate lookup tables that are megabytes in size. &nbsp;For Unicode, this impacts all languages. &nbsp;The intermediate sources for the Unicode supported in illumos blow up to over 2GB when support for the additional code planes is included.<br /><h2 style="text-align: left;">2. Your language requires me to write custom code for symbol names.&nbsp;</h2>Hangul Jamo, I'm looking at you. &nbsp;Of all the languages in Unicode, only this one is so bizarre that it requires multiple lookup tables to determine the names of the characters, because the characters are made up of smaller bits of phonetic portions (vowels and consonants.) &nbsp;It even has its own section in the basic conformance document for Unicode (section 3.12). &nbsp;I don't speak Korean, but I had to learn about Jamo.<br /><h2 style="text-align: left;">3. Your language's character set is continuing to evolve.&nbsp;</h2>Yes, that's Asia again (mostly China I think). &nbsp; The rate at which new Asian characters are added rivals that of updates to the timezone database. &nbsp;The approach your language uses is wrong!<br /><h2 style="text-align: left;">4. Characters in your language are of multiple different cell widths.&nbsp;</h2>Again, this is mostly, but not exclusively, Asian languages. &nbsp;Asian languages require 2 cells to display many of their characters. &nbsp;But, to make matters far far worse, some times the number f code points used to represent a character is more than one, which means that the width of a character when displayed may be 0, 1, or 2 cells. &nbsp; Worse, some languages have both half- and full-width forms for many common symbols. &nbsp;Argh.<br /><h2 style="text-align: left;">5. The width of the character depends on the context.&nbsp;</h2>Some widths depend on the encoding because of historical practice (Asia again!), but then you have composite characters as well. &nbsp;For example, a Jamo vowel sound could in theory be displayed on its own. &nbsp;But if it follows a leading consonant, then it changes the consonant character and they become a new character (at least to the human viewer).<br /><h2 style="text-align: left;">6. Your language has unstable case conversions.</h2>There are some evil ones here, and thankfully they are rare. &nbsp;But some languages have case conversions which are not reversible! &nbsp;Case itself is kind of silly, but this is just insane! &nbsp;Armenian has a letter with this property, I believe.<br /><h2 style="text-align: left;">7. Your language's collation order is context-dependent.&nbsp;</h2>(French, I'm looking at you!) &nbsp;Some languages have sorting orders that depend not just on the character itself, but on the characters that precede or follow it. &nbsp;Some of the rules are really hard. &nbsp;The collation code required to deal with this generally is really really scary looking.<br /><h2 style="text-align: left;">8. Your language has equivalent alternates (ligatures).&nbsp;</h2>German, your ß character, which stands in for "ss", is a poster child here. &nbsp;This is a single code point, but for sorting it is equivalent to "ss". &nbsp;This is just historical decoration, because it's "fancy". &nbsp;Stop making my programming life hard.<br /><h2 style="text-align: left;">9. Your language can't decide on a script.&nbsp;</h2>Some languages can be written in more than one script. &nbsp;For example, Mongolian can be written using Mongolian script or Cyrillic. &nbsp;But the winner (loser?) here is Serbian, which in some places uses both Latin and Cyrillic characters <i>interchangeably</i>! Pick a script already! I think the people who live like this are just schizophrenic. &nbsp;(Given all the political nonsense surrounding language in these places, that's no real surprise.)<br /><h2 style="text-align: left;">10. Your language has Titlecase.&nbsp;</h2>POSIX doesn't do Titlecase. &nbsp;This happens because your language also uses ligatures instead of just allocating a separate cell and code point for each character. &nbsp;Most people talk about titlecase used in a phrase or string of words. &nbsp;But yes, titlecase can apply to a <i>SINGLE CHARACTER</i>. &nbsp;For example, ǅ is just such a character.<br /><h2 style="text-align: left;">11. Your language doesn't use the same display / ordering we expect.</h2>So some languages use right to left, which is backwards, but whatever. &nbsp; Others, crazy ones (but maybe crazy smart, if you think about it) use back and forth bidirectional. &nbsp;And still others use vertical ordering. &nbsp;But the worst of them are those languages (Asia again, dammit!) where the orientation of text can change. &nbsp;Worse, some cases even rotate individual characters, depending upon context (e.g. titles are rotated 90 degrees and placed on the right edge). &nbsp;How did you ever figure out how to use a computer with this crazy stuff?<br /><h2 style="text-align: left;">12. Your encoding collides control codes.</h2>We use the first 32 or so character codes to mean special things for terminal control, etc. &nbsp;If we can't use these, your language is going to suck over certain kinds of communication lines.<br /><h2 style="text-align: left;">13. Your encoding uses conflicting values at ASCII code points.</h2>ASCII is universal. &nbsp;Why did you fight it? &nbsp;But that's probably just me being mostly Anglo-centric / bigoted.<br /><h2 style="text-align: left;">14. Your language encoding uses shift characters.&nbsp;</h2>(Code page, etc.) &nbsp;Some East Asian languages used this hack in the old days. &nbsp;Stateful encodings are JUST HORRIBLY BROKEN. &nbsp; A given sequence of characters should not depend on some state value that was sent a long time earlier.<br /><h2 style="text-align: left;">15. Your language encoding uses zero values in the middle of valid characters.&nbsp;</h2>Thankfully this doesn't happen with modern encodings in common use anymore. &nbsp;(Or maybe I just have decided that I won't support any encoding system this busted. &nbsp;Such an encoding is so broken that I just flat out refuse to work with it.)<br /><br /><h2 style="text-align: left;">Non-Broken Languages</h2><br />So, there are some good examples of languages that are famously not broken.<br /><br />a. <b>English</b>. &nbsp;Written English has simple sorting rules, and a very simple character set. &nbsp;Dipthongs are never ligatures. &nbsp;This is so useful for data processing that I think it has had a great deal to do with why English is the common language for computer scientists around the world. &nbsp;US-ASCII -- and English character set, is the "base" character set for Unicode, and pretty much all other encodings use ASCII encodings in the lower 7 bits.<br /><br />b. <b>Russian</b>. &nbsp;(And likely others that use Cyrillic, but not all of them!) &nbsp;Russian has a very simple alphabet, strictly phonetic. &nbsp;The number of characters is small, there are no composite characters, and no special sorting rules. &nbsp;Hmm... I seem to recall that Russia (Soviet era) had a pretty robust computing industry. &nbsp;And these days Russians mostly own the Internet, right? &nbsp;Coincidence? &nbsp;Or maybe they just don't have to waste a lot of time fighting with the language just to get stuff done?<br /><br />I think there are probably others. &nbsp;(At a glance, Geoergian looks pretty straight-forward. &nbsp; I suspect that there are languages using both Cyrillic and Latin character sets that are sane. &nbsp;Ethiopic actually looks pretty simple and sane too. &nbsp;(Again, just from a text processing standpoint.)<br /><br />But sadly, the vast majority of natural languages have written forms &amp; rules that completely and utterly suck for text processing.</div></content><link rel='replies' type='application/atom+xml' href='http://garrett.damore.org/feeds/8778482429302443995/comments/default' title='Post Comments'/><link rel='replies' type='text/html' href='http://www.blogger.com/comment.g?blogID=7528831701633643336&postID=8778482429302443995' title='20 Comments'/><link rel='edit' type='application/atom+xml' href='http://www.blogger.com/feeds/7528831701633643336/posts/default/8778482429302443995'/><link rel='self' type='application/atom+xml' href='http://www.blogger.com/feeds/7528831701633643336/posts/default/8778482429302443995'/><link rel='alternate' type='text/html' href='http://garrett.damore.org/2014/10/your-language-sucks.html' title='Your language sucks...'/><author><name>Garrett D'Amore</name><uri>https://plus.google.com/114484106466928611830</uri><email>noreply@blogger.com</email><gd:image rel='http://schemas.google.com/g/2005#thumbnail' width='32' height='32' src='//lh3.googleusercontent.com/-3UzpztUh9YI/AAAAAAAAAAI/AAAAAAAADRI/7gIavrAWW5k/s512-c/photo.jpg'/></author><thr:total>20</thr:total></entry><entry><id>tag:blogger.com,1999:blog-7528831701633643336.post-6417258591013467960</id><published>2014-10-12T14:00:00.001-07:00</published><updated>2014-10-13T16:03:12.827-07:00</updated><title type='text'>My Problem with Feminism</title><content type='html'><div dir="ltr" style="text-align: left;" trbidi="on">I'm going to say some things here that may be controversial. &nbsp;Certainly that headline is. &nbsp;But please, bear with me, and read this before you judge too harshly.<br /><br />As another writer said, 2014 has been a terrible year for women in tech. &nbsp;(Whether in the industry, or in gaming.) &nbsp;Arguably, this is not a <i>new</i>&nbsp;thing, but rather events are reaching a head. &nbsp;Women (some at any rate) are being more vocal, and awareness of women's issues is up. &nbsp;On the face of it, this should be a good thing.<br /><br />And yet, we have incredible conflict between women and men. &nbsp;And this is at the heart of my problem with "Feminism".<br /><div style="text-align: left;"><br /></div><h3 style="text-align: left;">The F-Word</h3><br />Don't get me wrong. &nbsp;I strongly believe that women should be treated fairly and with respect; in the professional place they should receive the same level of professional respect -- and compensation! -- as their male counterparts can expect. &nbsp;I believe this passionately -- as a nerd, I prefer to judge people on the merits of their work, rather than on their race, creed, gender, or sexual preference. &nbsp;A similar principle applies to gaming -- after all, how do you really know the gender of the player on the other side of the MMO? &nbsp;Does it even matter? &nbsp;When did gaming become a venue for channeling hate instead of fun?<br /><br />The problem with "feminism" is that instead of repairing inequality and trying to bring men and women closer together, so much of it seems to be divisive. &nbsp;The very word itself basically suggests a gender based conflict, and I think this, as well as much of the recent approach, is counterproductive.<br /><br />Instead of calling attention to inequalities and improper behaviors (lets face it, nobody wants to deal with sexual harassment, discrimination, or some of the very much worse behavior that a few terribly bad actors are guilty of), we've become focused on gender bias and "fixing" gender bias as a goal in and of itself, rather than instead focusing on fair and equal treatment for all.<br /><br />Every day I'm inundated with tweets and Facebook postings extolling the terrible plight of women at the expense of men. &nbsp;Many of these posts seem intended to make me either angry at men, or ashamed of being one. &nbsp;This basically drives a wedge between people, even unconsciously, to the point that it has become impossible to avoid being a soldier on one side or the other of this war. &nbsp;And don't get me wrong, it has indeed degenerated to a total war.<br /><br />I don't think this is what most feminists or their advocates really want. &nbsp;(Though, I think it is what some of them want. &nbsp;The side of feminism has its bad actors who thrive on conflict just as much as the other side has. &nbsp;Extremism is gender and color and religion blind, as we've ample evidence of.)<br /><br />I think one thing that advocates for women in tech can do, is to pick a different term, and a different way of stating their goals, and perhaps a different approach. &nbsp;I think we've reached the critical mass necessary for awareness, so the constant tweets about how terrible it is to be a woman are no longer helpful.<br /><br />I'm not sure what "term" should replace feminism -- in the workplace I'd suggest "professionalism". &nbsp;After all everyone wants to be treated professionally, not just women. &nbsp;(Btw, I'd say that in the gaming community, the value should be "sportsmanship". &nbsp;Sadly some will see that word is gender biased, but I don't ascribe to the notion that we have to completely change our language in order to be more politically correct. &nbsp;You know what I mean.)<br /><br />Likewise, instead of dog piling on the one person (as I'm sure will happen in response to this post) on someone who doesn't immediately appear to support the feminist agenda, perhaps a little more tolerance, and education should be used in the approach. &nbsp;Focus should, IMO, be on public praise for the parties who are working to make conditions better.<br /><br />Educate instead of punish. &nbsp;Make allies instead of enemies.<br /><br /><h3 style="text-align: left;">Salary Gap</h3><br /><div style="text-align: left;">The salary gap issue that was raised recently by Microsoft is another case in point.<br /><br />I don't agree with <a href="http://valleywag.gawker.com/microsoft-ceo-tells-women-not-to-ask-for-a-raise-at-wom-1644473757?rev=1412886308615">Satya Nadella's comments</a> saying that women should not ask for raises, but I think many women are nearly as likely to get a raise upon requesting one as a man of similar accomplishments. &nbsp;(Yes, it would be better if this statement could have been said without "nearly".) &nbsp; Far too few women feel comfortable asking for a merit based raise in the first place -- that is something that should change. But using race or gender as a bias to demand pay increases is a recipe for further division. &nbsp;Indeed, men may begin to wonder if women are being compensated unfairly because they are women, but in the reverse direction.&nbsp;</div><div style="text-align: left;"><br /></div>Likewise, bringing up discrimination in a salary discussion puts the other party on the defensive. &nbsp;It presumes to imply prior wrong-doing. &nbsp;This may be the case, but it may well not be. &nbsp;After all, I've known many men that were under compensated simply because they sold themselves short, or were not comfortable asking for more money. &nbsp; Why look for a fight when there isn't one? &nbsp;(I suspect this is what Satya was really trying to get at.)<br /><br />None of this helps the cause of "professionalism", and probably not the cause of "feminism".<br /><br />Average tech salary figures are easily obtainable. &nbsp;If a worker, man or woman, feels under compensated -- for any reason -- then they should take it to his employer and ask for a correction. &nbsp;But to presume that the reason is gender, starts the conversation from a point of conflict.<br /><br />Far far better is to demand far pay based on work performance and merit, relative to industry norms as appropriate. &nbsp; If an employer won't compensate fairly, just leave. &nbsp;There is no shortage of tech jobs in the industry. &nbsp;If you're a woman, maybe look for jobs at companies that employ (and successfully retain) women. &nbsp;Ask the people who work at a prospective employer about conditions, etc. &nbsp;That's true for minorities too! &nbsp;Ultimately, an employer who discriminates will find itself at a severe competitive advantage, as both the discriminated-against parties, and their allies refuse to do business with them.<br /><br />An employer is not obligated to pay you "more" because of your gender. &nbsp;But they must also not pay you less because of gender. &nbsp;And yet every company will generally try to pay as little as they think they can get away with. &nbsp;So don't let them -- but keep discrimination out of the conversation unless there is really compelling proof of wrong doing. &nbsp;(And if there is such evidence, I'd recommend looking elsewhere, and possibly explore stronger legal measures.)<br /><br />And yes, I strongly strongly believe that most men feel as I do. &nbsp;They support the notion that everyone should be treated equally and professionally, and would like to stamp out sexism in the workplace, but many of us are starting to show symptoms of battle fatigue, and even more of us just don't want to be involved in a conflict at all. &nbsp; Frankly, I think a lot of us are annoyed at feminist attempts to draw us into the conflict, even though we do support many of the stated goals of equal pay, fair treatment, etc. etc.<br /><h3 style="text-align: left;">Closing Thoughts</h3>As for me, I support the plight of women who find themselves discriminated against based on their gender, and I would like to see more women in my industry. &nbsp;And I've put my money where my mouth is.&nbsp;<br /><br />But at the same time, you won't find me supporting "feminism". &nbsp;I want to heal the rift, and work with awesome people -- and I happen to believe at least half of the awesome people in the world are of a different gender than I am. &nbsp;Why would I want to alienate them?<br /></br />I happen to believe that many well meaning people of many causes damage their cause by basically forcing people to deal with their "diversity" first, instead of of being able to deal with people as people on their own merit. &nbsp;Its so much harder to appreciate a person on her own merits, when at least half of what she is saying is that she's unfairly treated because of gender, race, sexual preference, etc. &nbsp;This true for everyone. &nbsp;Show me how you're excellent, and I promise to appreciate you for your awesomeness, and to treat you fairly and with the same respect I would for anyone of my own gender/race/sexual preference.<br /><br />You are awesome because of your accomplishments/innovations/contributions, not because of your gender or race or sexual preference.<br /><br />But, if you won't let me look past your race/gender/etc. identity, then please don't be offended if I don't see anything else. &nbsp;If you want to be treated like a "person", then let me see the person instead of just some classification in an equal opportunity survey.<br /><div><br /></div></div></content><link rel='replies' type='application/atom+xml' href='http://garrett.damore.org/feeds/6417258591013467960/comments/default' title='Post Comments'/><link rel='replies' type='text/html' href='http://www.blogger.com/comment.g?blogID=7528831701633643336&postID=6417258591013467960' title='0 Comments'/><link rel='edit' type='application/atom+xml' href='http://www.blogger.com/feeds/7528831701633643336/posts/default/6417258591013467960'/><link rel='self' type='application/atom+xml' href='http://www.blogger.com/feeds/7528831701633643336/posts/default/6417258591013467960'/><link rel='alternate' type='text/html' href='http://garrett.damore.org/2014/10/my-problem-with-feminism.html' title='My Problem with Feminism'/><author><name>Garrett D'Amore</name><uri>https://plus.google.com/114484106466928611830</uri><email>noreply@blogger.com</email><gd:image rel='http://schemas.google.com/g/2005#thumbnail' width='32' height='32' src='//lh3.googleusercontent.com/-3UzpztUh9YI/AAAAAAAAAAI/AAAAAAAADRI/7gIavrAWW5k/s512-c/photo.jpg'/></author><thr:total>0</thr:total></entry><entry><id>tag:blogger.com,1999:blog-7528831701633643336.post-2247759060905481071</id><published>2014-10-02T14:24:00.003-07:00</published><updated>2014-10-02T14:24:45.479-07:00</updated><title type='text'>Supporting Women in Open Source</title><content type='html'>Please have a look at <a href="http://ceph.com/community/support-ada-initiative-challenge-open-storage-community/">Sage Weil's blog post</a> on supporting the Ada Initiative, which supports women in open source development.<br /><br />Sage is sponsoring an $8192 matching grant, to support women in open source development of open storage technology.<br /><br />You may have heard my talk recently, where I expressed that there have been no female contributions to illumos (that includes ZFS by the way!) &nbsp;This is kind of a tragedy; intelligence and creativity of at least half the population are simply not represented here, and we are worser for it.<br /><br />If you want to try to do something about it, heres a small thing. &nbsp;There's a week remaining to do so, so I encourage folks to step up. &nbsp;($3392 has already been granted.)<br /><br />I'm making a donation myself, if you think supporting more women in open source is a worthwhile cause, please join me!<br /><div><br /></div></content><link rel='replies' type='application/atom+xml' href='http://garrett.damore.org/feeds/2247759060905481071/comments/default' title='Post Comments'/><link rel='replies' type='text/html' href='http://www.blogger.com/comment.g?blogID=7528831701633643336&postID=2247759060905481071' title='0 Comments'/><link rel='edit' type='application/atom+xml' href='http://www.blogger.com/feeds/7528831701633643336/posts/default/2247759060905481071'/><link rel='self' type='application/atom+xml' href='http://www.blogger.com/feeds/7528831701633643336/posts/default/2247759060905481071'/><link rel='alternate' type='text/html' href='http://garrett.damore.org/2014/10/supporting-women-in-open-source.html' title='Supporting Women in Open Source'/><author><name>Garrett D'Amore</name><uri>https://plus.google.com/101751336283999515602</uri><email>noreply@blogger.com</email><gd:image rel='http://schemas.google.com/g/2005#thumbnail' width='32' height='32' src='//lh3.googleusercontent.com/-iK1shT81XTE/AAAAAAAAAAI/AAAAAAAAAJA/MSN7V7X_7mM/s512-c/photo.jpg'/></author><thr:total>0</thr:total></entry><entry><id>tag:blogger.com,1999:blog-7528831701633643336.post-4888050947994817475</id><published>2014-09-07T09:10:00.000-07:00</published><updated>2014-09-07T18:31:49.286-07:00</updated><title type='text'>Modernizing "less"</title><content type='html'><div dir="ltr" style="text-align: left;" trbidi="on">I have just spent an all-nighter doing something I didn't expect to do. <br /><br />I've "<a href="https://bitbucket.org/gdamore/illumos-gate/commits/db22b5423fe1dd6bd58f0c3abd71ac1bf89155ff">modernized</a>" <b>less</b>(1). &nbsp;(That link is to the changeset.)<br /><br />First off, let me explain the motivation. &nbsp;We need a pager for illumos that can meet the requirements for POSIX IEEE 2003.1-2008 <a href="http://pubs.opengroup.org/onlinepubs/9699919799/utilities/more.html"><b>more</b></a>(1). &nbsp;We have a suitable pager (barely), in closed source form only, delivered into <span style="font-family: Courier New, Courier, monospace;">/usr/xpg4/bin/more</span>. &nbsp;We have an open source <span style="font-family: Courier New, Courier, monospace;"><a href="http://src.illumos.org/source/xref/illumos-gate/usr/src/cmd/more/more.c">/usr/bin/more</a></span>, but it is incredibly limited, hearkening back to the days of printed hard copy I think. &nbsp;(It even has Microsoft copyrights in it!)<br /><br />So closed source is kind of a no go for me. <br /><br /><a href="http://www.greenwoodsoftware.com/less/"><b>less</b></a>(1) looks attractive. &nbsp;It's widely used, and has been used to fill in for more(1) to achieve POSIX compliance on other systems (such as MacOS X.)<br /><br />So I started by unpacking it into our tree, and trying to get it to work with an illumos build system.<br /><br />That's when I discovered the crazy contortions autoconf was doing that basically wound up leaving it with just legacy BSD termcap. &nbsp; Ewww. &nbsp; I wanted it to use <a href="http://pubs.opengroup.org/onlinepubs/7908799/cursesix.html">X/Open Curses</a>.<br /><br />When I started trying to do that, I found that there were severe crasher bugs in less, involving the way it uses scratch buffer space. &nbsp;I started trying to debug just that problem, but pretty soon the effort mushroomed.<br /><br />Legacy less supports all kinds of crufty and ancient systems. &nbsp; Systems like MS-DOS (actually many different versions with different compiler options!) and Ultrix and OS/2 and OS9, and OSK, etc. &nbsp;In fact, it apparently had to support systems where the C preprocessor didn't understand <span style="font-family: Courier New, Courier, monospace;">#elif</span>, so the <span style="font-family: Courier New, Courier, monospace;">#ifdef</span> maze was truly nightmarish. &nbsp;The code is K&amp;R style C even.<br /><br />I decided it was high time to modernize this application for POSIX systems. &nbsp;So I went ahead and did a sweeping update. &nbsp;In the process I ditched thousands of lines of code (the screen handling bits in screen.c are less than half as big as they were).<br /><br />So, now it:<br /><br /><br /><ul style="text-align: left;"><li>Speaks terminfo (X/Open Curses) instead of ancient BSD termcap</li><li>Uses <b>glob</b>(3C) instead of a hack involving the shell and a helper program (<b>lessecho</b>, which I've removed from my tree.)</li><li>Functions properly as /usr/bin/more, both with and without -e (even on broken xterms)</li><li>Is fully ANSI C (or ISO C, if you prefer)</li><li>Passes illumos' cstyle code style checks</li><li>Is <b>lint</b>(1) clean</li></ul><br /><br />There is more work to do in the future if someone wants to. &nbsp;Here are the ideas for the future:<br /><br /><br /><ul style="text-align: left;"><li>Internationalization. &nbsp;This is a pretty easy task involving <b>gettext</b>().</li><li>Make less use getopt() instead of its byzantine option parser (it needed that for PC operating systems. &nbsp;We don't need or want this complexity on POSIX.)</li><li>Fix its character set handling so it can use the <b>mbstring</b> and <b>wcstring</b> routines in the platform instead of relying on it's own implementation of UTF-8. &nbsp;(This would make it support other multibyte locales.)</li><li>Make it support port events instead of sleeping when acting in "tail -f" mode.</li></ul><br /><br />If someone wants to pick up any of this work, let me know. &nbsp;I'm happy to advise. &nbsp;Oh, and this isn't in illumos proper yet. &nbsp;It's unclear when, if ever, it will get into illumos -- I expect a lot of grief from people who think I shouldn't have forked this project, and I'm not interested in having &nbsp;a battle with them. &nbsp;The upstream has to be a crazy maze because of the platforms it has to support. &nbsp;We can do better, and I think this was a worthwhile case. &nbsp;(In any event, I now know quite a lot more about less internals than I did before. &nbsp;Not that this is a good thing.)<br /><br /></div></content><link rel='replies' type='application/atom+xml' href='http://garrett.damore.org/feeds/4888050947994817475/comments/default' title='Post Comments'/><link rel='replies' type='text/html' href='http://www.blogger.com/comment.g?blogID=7528831701633643336&postID=4888050947994817475' title='12 Comments'/><link rel='edit' type='application/atom+xml' href='http://www.blogger.com/feeds/7528831701633643336/posts/default/4888050947994817475'/><link rel='self' type='application/atom+xml' href='http://www.blogger.com/feeds/7528831701633643336/posts/default/4888050947994817475'/><link rel='alternate' type='text/html' href='http://garrett.damore.org/2014/09/modernizing-less.html' title='Modernizing "less"'/><author><name>Garrett D'Amore</name><uri>https://plus.google.com/114484106466928611830</uri><email>noreply@blogger.com</email><gd:image rel='http://schemas.google.com/g/2005#thumbnail' width='32' height='32' src='//lh3.googleusercontent.com/-3UzpztUh9YI/AAAAAAAAAAI/AAAAAAAADRI/7gIavrAWW5k/s512-c/photo.jpg'/></author><thr:total>12</thr:total></entry><entry><id>tag:blogger.com,1999:blog-7528831701633643336.post-3767819768476018717</id><published>2014-08-20T22:15:00.001-07:00</published><updated>2014-08-20T22:15:12.688-07:00</updated><title type='text'>It's time already</title><content type='html'><div>(Sorry for the political/religious slant this post takes... I've been trying to stay focused on technology, but sometimes events are simply too large to ignore...)</div><div><br /></div><div>The <a href="http://www.cbsnews.com/news/james-foleys-parents-he-was-courageous-to-the-end/">execution of John Foley</a> is just the latest. &nbsp;But for me, its the straw that broke the camel's back.&nbsp;</div><div><br /></div>Over the past weeks, I've become extremely frustrated and angry. &nbsp;The "radical Islamists" have become the single biggest threat to world peace since Hitler's Nazi's. &nbsp;And they are worse than the Nazi's. &nbsp;Which takes some doing. &nbsp;(Nazi's "merely" exterminated Jews. &nbsp;The Islamists want to exterminate everyone who does't believe exactly their own particular version of extreme religion.)<div><br /></div><div>I'm not a Muslim. &nbsp;I'm probably not even a Christian when you get down to it. &nbsp;I do believe in God, I suppose. &nbsp;And I do believe that God certainly didn't intend for one group of believes to exterminate another simply because they have different beliefs.</div><div><br /></div><div>Parts of the Muslim world <i>claim</i>&nbsp;that ISIS and those of its ilk are a scourge, primarily, I think, because they are turning the rest of the world against Islam. &nbsp;If that's true, then the entire Muslim world who rejects ISIS and radical fundamentalist Islam (and it's not clear to me that rejecting one is the same as the other) needs to come together and eliminate ISIS, and those who follow its beliefs or even sympathize with it.&nbsp;</div><div><br /></div><div>That hasn't happened. &nbsp;I don't see a huge military invasion of ISIS territory by forces from Arabia, Indonesia, and other Muslim nations. &nbsp;Why not?</div><div><br /></div><div>I don't believe it is possible to be a peace loving person (Muslim or otherwise), and stand idly by (or advocate standing by) why the terrorist forces who want nothing more than to destroy the very fabric of human society work to achieve their evil ends.</div><div><br /></div><div>Just as Nazi Germany and Imperial Japan were an Axis of Evil during our grandparents' generation, so now we have a new Axis of Evil that has taken root in the middle east.</div><div><br /></div><div>It's time now to recognize that there is absolutely <i>no</i>&nbsp;chance for a peaceful coexistence with these people. &nbsp;They are, frankly, subhuman, and their very <i>existence</i>&nbsp;is at odds with that of everyone everywhere else in the world.</div><div><br /></div><div>It's time for those of us in civilized nations to stop with our petty nonsense bickering. &nbsp;The actions taking place in Ukraine, unless you live there (an in many case even if you do live there), are a diversion. &nbsp;Putin and Obama need to stop their petty bickering, and cooperate to eliminate the real threat to civilization, which is radical Islam.</div><div><br /></div><div>To be clear, I believe that the time has now come for the rest of the world to pick up and take action, where the Muslim world has failed. &nbsp;We need to clean house. &nbsp;We can no longer cite "freedom of expression" and "freedom of religion" as reasons to let imam's recruit young men into death cults. &nbsp;We must recognize that these acts of incitement to terrorism are indeed what they are, and the perpetrators have no more right to life and liberty than Charles Manson.&nbsp;</div><div><br /></div><div>These are forces that seek to overthrow from within, by recruitment, by terrorism, or by any means they can. &nbsp;These are forces that place no value on human life. &nbsp;These are forces with which are inimical to the very concept of civilization.</div><div><br /></div><div>There can be no tolerance for them. &nbsp;None, whatsoever.&nbsp;</div><div><br /></div><div>To be clear, I'm advocating that when a member of one of these organizations willing self identifies as such, we should simply kill them. &nbsp;Wherever they are. &nbsp;These are the enemy, and there is no separate battlefield, and they do not recognize "civilians" or "innocents"; therefore, like a cancer, radical Islam must be purged from the very earth, by any means necessary.</div><div><br /></div><div>The militaries of the world should unit, and work together, to eradicate entrenched forces of radical Islam wherever it exists in the world. &nbsp;This includes all those forms that practice Sharia law, where a man and woman can be stoned to death simply for marrying without parental consent, as well as those groups that seek to eliminate the state of Israel, that seek to kill those who don't believe exactly as they do, that would issue a <i>fatwa</i>&nbsp;demanding the death of a cartoonist simply for depicting their prophet, &nbsp;and those who seek to reduce women to the status of mere cattle.</div><div><br /></div><div>To be clear, we have to do the hard work, all nations of the world, to eliminate this scourge, and eliminate it at its source. &nbsp;Mosques where radicalism are preached must no longer be sanctuaries. &nbsp;Schools where "teachers" train their students in the killing of Christians and Jews, and that their God demands the death of "unbelievers" and rewards suicide bombers with paradise, need to be recognized as the training camps they are. &nbsp;Even if the students are women and children.</div><div><br /></div><div>Your right to free speech and to religion does not trump my right to live. &nbsp;Nor, by the way, does it trump my own rights to free speech and religion.</div><div><br /></div><div>I suppose this means that we have to be willing to accept some losses of combat, in the fight against radicalism. &nbsp;We also have to accept that "collateral damage" is inevitable. &nbsp;As with rooting out a cancer, some healthy cells are going to be destroyed. &nbsp;But these losses have to be endured if the entire organism that is civilization is to survive.&nbsp;</div><div><br /></div><div>If this sounds like I'm a hawk, perhaps that's true. &nbsp;I think, rather, I'm merely someone who wants to survive, and wants the world to be a place where my own children and grandchildren can live without having to endure a constant fear of nut jobs who want to kill them simply because they exist and think differently.</div><div><br /></div><div>Btw, if Islam as a religion is to survive in the long run, it <i>must</i>&nbsp;see these forces purged. &nbsp;Because otherwise the only end result becomes an all out war of survival between Muslims and the rest of the world. &nbsp;And guess which side has the biggest armies and weapons? And who will be the biggest losers in a conflict between Muslims and everyone else?</div><div><br /></div><div>So, it's time to choose a side. &nbsp;There is no middle ground. &nbsp;Radical Islam tolerates no neutrality. &nbsp;So, what's it going to be?</div><div><br /></div><div>As for me, I choose civilization and survival. &nbsp;That means a world without radical Islam. &nbsp;Period.</div><div><br /></div></content><link rel='replies' type='application/atom+xml' href='http://garrett.damore.org/feeds/3767819768476018717/comments/default' title='Post Comments'/><link rel='replies' type='text/html' href='http://www.blogger.com/comment.g?blogID=7528831701633643336&postID=3767819768476018717' title='0 Comments'/><link rel='edit' type='application/atom+xml' href='http://www.blogger.com/feeds/7528831701633643336/posts/default/3767819768476018717'/><link rel='self' type='application/atom+xml' href='http://www.blogger.com/feeds/7528831701633643336/posts/default/3767819768476018717'/><link rel='alternate' type='text/html' href='http://garrett.damore.org/2014/08/its-time-already.html' title='It's time already'/><author><name>Garrett D'Amore</name><uri>https://plus.google.com/101751336283999515602</uri><email>noreply@blogger.com</email><gd:image rel='http://schemas.google.com/g/2005#thumbnail' width='32' height='32' src='//lh3.googleusercontent.com/-iK1shT81XTE/AAAAAAAAAAI/AAAAAAAAAJA/MSN7V7X_7mM/s512-c/photo.jpg'/></author><thr:total>0</thr:total></entry><entry><id>tag:blogger.com,1999:blog-7528831701633643336.post-7476308653358552214</id><published>2014-07-11T20:54:00.000-07:00</published><updated>2014-07-11T20:54:25.769-07:00</updated><title type='text'>POSIX 2008 locale support integrated (illumos)</title><content type='html'>A year in the making... and finally the code is pushed. &nbsp;Hooray!<br /><br />I've just pushed <a href="https://www.illumos.org/issues/2964">2964</a>&nbsp;into <a href="http://illumos.org/">illumos</a>, which adds support for a bunch of new libc calls for thread safe and thread-specific locales, as well as explicit locale_t objects. &nbsp; Some of the interfaces added fall under the BSD/MacOS X "<a href="https://developer.apple.com/library/mac/documentation/Darwin/Reference/ManPages/man3/xlocale.3.html">xlocale</a>" class of functions.<br /><br />Note that not all of the xlocale functions supplied by BSD/MacOS are present. &nbsp;However, all of the routines that were added by <a href="http://pubs.opengroup.org/onlinepubs/9699919799/functions/contents.html">POSIX 2008</a> for this class are present, and should conform to the POSIX 2008 / XPG Issue 7 standards. &nbsp;(Note that we are not yet compliant with POSIX 2008, this is just a first step -- albeit a rather major one.)<br /><br />The <a href="http://cr.illumos.org/~webrev/gdamore/posix2008/">webrev</a> is also available for folks who want to look at the code.<br /><br />The new APIs are documented in newlocale(3c), uselocale(3c), etc. &nbsp; (Sadly, man pages are not indexed yet so I can't put links here.)<br /><br />Also, documentation for some APIs that was missing (e.g. strfmon(3c)) are now added.<br /><br />This project has taken over a year to integrate, but I'm glad it is now done.<br /><br />I want to say a big -- huge -- thank you to Robert Mustacchi who not only code reviewed a huge amount of change (and provided numerous useful and constructive feedback), but also contributed a rather large swath of man page content in support of this effort, working on is own spare time. &nbsp;Thanks Robert!<br /><br />Also, thanks to both Gordon Ross and Dan McDonald who also contributed useful review feedback and facilitated the integration of this project. &nbsp;Thanks guys!<br /><br />Any errors in this effort are mine, of course. &nbsp;I would be extremely interested in hearing constructive feedback. &nbsp;I expect there will be some minor level of performance impact (unavoidable due to the way the standards were written to require a thread-specific check on all locale sensitive routines), but I hope it will be minor.<br /><br />I'm also extremely interested in feedback from folks who are making use of these new routines. &nbsp;I'm told the Apache Standard C++ library depends on these interfaces -- I hope someone will try it out and let me know how it goes. &nbsp; Also, if someone wants/needs xlocale interfaces that I didn't include in this effort, please drop me a note and I'll try to get to it.<br /><br />As this is a big change, it is not entirely without risk. &nbsp;I've done what I could to minimize that risk, and test as much as I could. &nbsp;If I missed something, please let me know, and I'll attempt to fix in a timely fashion.<br /><br />Thanks!<br /><div><br /></div></content><link rel='replies' type='application/atom+xml' href='http://garrett.damore.org/feeds/7476308653358552214/comments/default' title='Post Comments'/><link rel='replies' type='text/html' href='http://www.blogger.com/comment.g?blogID=7528831701633643336&postID=7476308653358552214' title='0 Comments'/><link rel='edit' type='application/atom+xml' href='http://www.blogger.com/feeds/7528831701633643336/posts/default/7476308653358552214'/><link rel='self' type='application/atom+xml' href='http://www.blogger.com/feeds/7528831701633643336/posts/default/7476308653358552214'/><link rel='alternate' type='text/html' href='http://garrett.damore.org/2014/07/posix-2008-locale-support-integrated.html' title='POSIX 2008 locale support integrated (illumos)'/><author><name>Garrett D'Amore</name><uri>https://plus.google.com/101751336283999515602</uri><email>noreply@blogger.com</email><gd:image rel='http://schemas.google.com/g/2005#thumbnail' width='32' height='32' src='//lh3.googleusercontent.com/-iK1shT81XTE/AAAAAAAAAAI/AAAAAAAAAJA/MSN7V7X_7mM/s512-c/photo.jpg'/></author><thr:total>0</thr:total></entry><entry><id>tag:blogger.com,1999:blog-7528831701633643336.post-8248767765081061272</id><published>2014-05-27T10:30:00.000-07:00</published><updated>2014-05-27T10:30:07.661-07:00</updated><title type='text'>illumos, identification, and versions</title><content type='html'>Recently, there has been a bit of a <a href="http://www.listbox.com/member/archive/182179/2014/05/search/dW5hbWU/sort/time_rev/page/2/entry/11:39/20140512232339:F8462336-DA4D-11E3-A66B-CA7946192C8A/">debate</a> on the <a href="http://www.illumos.org/">illumos</a> mailing lists, beginning I suppose with an initial <a href="http://wiki.illumos.org/display/illumos/Modernizing+Uname">proposal</a> I made concerning the output from the <b><a href="http://www.illumos.org/man/1/uname">uname</a></b>(1) command on illumos, which today, when presented with "-s -r" as options, emits "SunOS 5.11".<br /><br />A lot of the debate centers on various ways that software can or cannot identify the platform it is running on, and use that information to make programmatic decisions about how to operate. Most often these are decisions made at compile time, by tools such as <b>autoconf</b> and <b>automake</b>.<br /><br />Clearly, it would be better for software not to rely on uname for programmatic uses, and detractors of my original proposal are correct that even in the Linux community, the value from uname cannot be relied upon for such use. &nbsp;There are indeed better mechanisms to use, such as <b><a href="http://www.illumos.org/man/3c/sysconf">sysconf</a></b>(3c), or the ZFS feature flags, to determine individual capabilities. &nbsp;Indeed, the GNU autotools contains many individual tests for such things, and arguably discourages the use of uname except as a last resort.<br /><br />Yet there can be no question that there are a number of packages that do make such use. &nbsp;And changes to the output from uname become risky to such packages.<br /><br />But perversely, <i>not changing</i>&nbsp;the output from uname also creates risk for such packages, as the various incarnations of SunOS 5.11 become ever less like one another. &nbsp;Indeed, illumos != SunOS, and uname has become something of a lie over the past 4 years or so.<br /><br />Clearly, the focus for programmatic platform determination -- particularly for enabling features or behaviors, should be to move away from uname. &nbsp;(Actually, changing uname may actually help package maintainers in identifying this questionable behavior as questionable, although there is no doubt that such a change would be disruptive to them.)<br /><br />But all this debate completely misses the other major purpose of uname's output, which is to identify the <i>platform</i>&nbsp;to humans. &nbsp;Be they administrators, or developers, or distributors. &nbsp;There is no question in mind that illumos' failure to self identify, and to have a regular "release" schedule (for whatever a release really means in this regard) is harmful.<br /><br />The distributors, such as <a href="http://www.joyent.com/">Joyent</a> (<a href="http://www.smartos.org/">SmartOS</a>), would prefer that people only identify their particular distribution, and I believe that much of the current argument from them stems from two primary factors. &nbsp;First, they see additional effort in any change, with no direct benefit to them. &nbsp;Second, in some ways these distributors are disinclined to emphasize illumos itself. &nbsp; Some of the messages sent (either over IRC or in the email thread) clearly portray some resentment towards the rest of the illumos ecosystem, especially some of the niche players), as well as a very heavy handed approach by one commercial concern towards the rest of the ecosystem.<br /><br />Clearly, this flies in the spirit of community cooperation in which illumos was founded. &nbsp;illumos should not be a slave to any single commercial concern, and nobody should be able to exercise a unilateral veto over illumos, or shut down conversations with a single "<a href="http://www.listbox.com/member/archive/182179/2014/05/search/dGhlcm1vbnVjbGVhcg/sort/time_rev/page/1/entry/1:2/20140513133849:6E4BE378-DAC5-11E3-9A47-C75DCFAA59E1/">thermonuclear</a>" post.<br /><br />So, without regard to the merits, or lack thereof, of changing uname's output, I'm quite certain, with sufficient clear evidence of my own gathering, that illumos absolutely needs to have a regularly scheduled "releases" of illumos, with humanly understandable release identifiers. &nbsp;The lack of both the releases, and the identifiers to go with them, hinders meaningful reviews, hurts distributors (particularly smaller ones), and makes support for the platform harder, particularly when the questions of support are considered across distributions. &nbsp;All of these hinder <i>adoption</i>&nbsp;of the illumos platform; clearly an undesirable outcome.<br /><br />Some would argue that we could use <b><a href="http://www.git-scm.com/">git</a></b> tags for the identifiers. &nbsp;From a programmatic standpoint, these would be easy to collect. &nbsp;Although they have problems as well (particularly for distributions which neither use git, or use a private fork that doesn't preserve our git versions), there are worse problems.<br /><br />Specifically, a humans aren't meant to derive meaning from something like "e3de96f25bd2ea4282eea2d1a86c1bebac8950cb". &nbsp; While <a href="http://en.wikipedia.org/wiki/Neo_(The_Matrix)">Neo</a> could understand this, most of use merely mortal individuals simply can't understand such tags. &nbsp;Worse, there is no implied sequencing here. &nbsp;Is "e3de96f25bd2ea4282eea2d1a86c1bebac8950cb" newer than "d1007364f5b14efdd7d6ba27aa458669a6365d48" ? &nbsp;You can't do a meaningful comparison without examining the actual git history.<br /><br />This makes it hard to guess whether a given running release has a bug integrated or not. &nbsp;It makes it hard to have conversations about the platform. &nbsp;It even makes it hard for independent reviewers of the platform &nbsp;to identify anything meaningful about the platform in the context of reviewing a distribution.<br /><br />Furthermore, when we talk about the platform, its useful for version numbers to convey more than just serial meaning. &nbsp;In particular, version numbers help set expectations for developers. &nbsp;Historically Solaris (or rather SunOS, from which illumos is derived), set those expectations in the form of stability guarantees. &nbsp; A given library interface might be declared as Stable, or Evolving, (or Committed or Uncommitted), or Obsolete. &nbsp;This was a way to convey to developers the relative risks of an interface (in terms of interface change), and it set some ground rules for rate of change. &nbsp;Indeed, Solaris (and SunOS) relied upon a form of <a href="http://www.semver.org/">semantic versioning</a>, and many of the debates in Sun's architectural leadership for Solaris (PSARC) revolved around these commitments.<br /><br />Yet today, the illumos distributors seem over willing to throw that bit of our heritage into the waste bin. &nbsp;A trend, I fear, which ultimately leads to chaos, and an increase in the difficulty of adoption by ISVs and developers.<br /><div><br /></div>illumos is one component -- albeit probably the most important by far -- of a distribution. &nbsp;Like all components, it is useful to be able to determine and talk about it. &nbsp;This is not noticeably different than Linux, Xorg, gnome, or pretty much any of the other systems which you are likely to find as part of a complete Ubuntu or RedHat distribution. &nbsp;In fact, our situation is entirely analogous other than we combine our libc and some key utilities and commands with the kernel.<br /><br />Technically, in Solaris parlance, illumos is a <i>consolidation</i>. &nbsp;In fact, this distinction has alway been clear. &nbsp;And historically the way the consolidation is identified is with the contents of the utsname structure, which is what is emitted by uname. &nbsp;<br /><br />Furthermore, when we talk about the platform, its useful for version numbers to convey more than just serial meaning<br /><br />In summary, regardless of whether we feel uname should return illumos or not, there is a critical need, although one not necessarily agreed upon by certain commercial concerns, for the illumos platform to have a release number at a minimum, and this release number must be useful to convey meaningful information to end-users, developers, and distributors alike. &nbsp;It would be useful if this release number were obtainable in the traditional fashion (uname), but its more important that the numbers convey meaning in the same way across distributions (which means packaging metadata cannot be used, at least not exclusively).<br /><br /></content><link rel='replies' type='application/atom+xml' href='http://garrett.damore.org/feeds/8248767765081061272/comments/default' title='Post Comments'/><link rel='replies' type='text/html' href='http://www.blogger.com/comment.g?blogID=7528831701633643336&postID=8248767765081061272' title='2 Comments'/><link rel='edit' type='application/atom+xml' href='http://www.blogger.com/feeds/7528831701633643336/posts/default/8248767765081061272'/><link rel='self' type='application/atom+xml' href='http://www.blogger.com/feeds/7528831701633643336/posts/default/8248767765081061272'/><link rel='alternate' type='text/html' href='http://garrett.damore.org/2014/05/illumos-identification-and-versions.html' title='illumos, identification, and versions'/><author><name>Garrett D'Amore</name><uri>https://plus.google.com/101751336283999515602</uri><email>noreply@blogger.com</email><gd:image rel='http://schemas.google.com/g/2005#thumbnail' width='32' height='32' src='//lh3.googleusercontent.com/-iK1shT81XTE/AAAAAAAAAAI/AAAAAAAAAJA/MSN7V7X_7mM/s512-c/photo.jpg'/></author><thr:total>2</thr:total></entry><entry><id>tag:blogger.com,1999:blog-7528831701633643336.post-4903361205291680757</id><published>2014-04-06T20:31:00.000-07:00</published><updated>2014-04-06T21:20:13.061-07:00</updated><title type='text'>SP protocols improved again!</title><content type='html'><h2>Introduction</h2><div><br /></div>As a result of some investigations performed in response to my <a href="http://garrett.damore.org/2014/03/early-performance-numbers.html">first performance tests</a> for my <a href="https://bitbucket.org/gdamore/sp">SP implementation</a>, I've made a bunch of changes to my code.<br /><div><br /></div><div>First off, I discovered that my code was rather racy. &nbsp;When I started bumping up GOMAXPROCS, and and used the -race flag to go test, I found lots of issues.&nbsp;</div><div><br /></div><div>Second, there were failure scenarios where the performance fell off a cliff, as the code dropped messages, needed to retry, etc.&nbsp;</div><div><br /></div><div>I've made a lot of changes to fix the errors. &nbsp;But, I've also made a major set of changes which enable a vastly better level of performance, particularly for throughput sensitive workloads. Note that to get these numbers, the application should "recycle" the Messages it uses (using a new <a href="https://godoc.org/bitbucket.org/gdamore/sp#Message.Free">Free()</a> API... there is also a <a href="https://godoc.org/bitbucket.org/gdamore/sp#NewMessage">NewMessage() </a>API to allocate from the cache), which will cache and recycle used buffers, greatly reducing the garbage collector workload.<br /><h2></h2><h2>Throughput</h2><div><br /></div>So, here are the new numbers for throughput, compared against my previous runs on the same hardware, including tests against the <a href="http://www.nanomsg.org/">nanomsg</a> reference itself.<br /><br /></div><div><table border="2" style="color: #333333; font-family: Arial, Tahoma, Helvetica, FreeSans, sans-serif; font-size: 15px; line-height: 20.790000915527344px;"><caption>Throughput Comparision<br />(Mb/s)</caption><tbody><tr><th>transport</th><th>nanomsg 0.3beta</th><th>old gdamore/sp</th><th>new<br />(1 thread)</th><th>new<br />(2 threads)</th><th>new<br />(4 threads)</th><th>new<br />(8 threads)</th></tr><tr><th>inproc 4k</th><td align="right">4322</td><td align="right">5551</td><td align="right">6629</td><td align="right">7751</td><td align="right">8654</td><td align="right">8841</td></tr><tr><th>ipc 4k</th><td align="right">9470</td><td align="right">2379</td><td align="right">6176</td><td align="right">6615</td><td align="right">5025</td><td align="right">5040</td></tr><tr><th>tcp 4k</th><td align="right">9744</td><td align="right">2515</td><td align="right">3785</td><td align="right">4279</td><td align="right">4411</td><td align="right">4420</td></tr><tr><th>inproc 64k</th><td align="right">83904</td><td align="right">21615</td><td align="right">45618</td><td align="right">35044<sup>b</sup></td><td align="right">44312</td><td align="right">47077</td></tr><tr><th>ipc 64k</th><td align="right">38929</td><td align="right">7831<sup>a</sup></td><td align="right">48400</td><td align="right">65190</td><td align="right">64471</td><td align="right">63506</td></tr><tr><th>tcp 64k</th><td align="right">30979</td><td align="right">12598</td><td align="right">34994</td><td align="right">49608</td><td align="right">53064</td><td align="right">53432</td></tr></tbody></table></div><br /><div><sup>a</sup> I think this poor result is from retries or resubmits inside the old implementation.<br /><sup>b</sup> I cannot explain this dip; I think maybe unrelated activity or GC activity may be to blame<br /><br />The biggest gains are with large frames (64K), although there are gains for the 4K size as well. &nbsp;nanomsg still out performs for the 4K size, but with 64K my message caching changes pay dividends and my code actually beats nanomsg rather handily for the TCP and IPC cases.<br /><br />I think for 4K, we're hurting due to inefficiencies in the Go TCP handling below my code. &nbsp;My guess is that there is a higher per packet cost here, and that is what is killing us. &nbsp;This may be true for the IPC case as well. &nbsp;Still, these are very respectable numbers, and for some very real and useful workloads my implementation compares and even beats the reference.<br /><br />The new code really shows some nice gains for concurrency, and makes good use of multiple CPU cores.<br /><br />There are a few mysteries though. &nbsp;Notes "a" and "b" point to two of them. &nbsp;The third is that the IPC performance takes a dip when moving from 2 threads to 4. &nbsp;It still significantly outperforms the TCP side though, and is still performing more than twice as fast as my first implementation, so I guess I shouldn't complain too much.<br /><h2></h2><h2>Latency</h2><div><br /></div>The latency has shown some marked improvements as well. &nbsp;Here are new latency numbers.</div><div><br /></div><div><table border="2" style="background-color: white; color: #333333; font-family: Arial, Tahoma, Helvetica, FreeSans, sans-serif; font-size: 15px; line-height: 20.790000915527344px;"><caption>Latency Comparision<br />(usec/op)</caption><tbody><tr><th>transport</th><th>nanomsg 0.3beta</th><th>old gdamore/sp</th><th>new<br />(1 thread)</th><th>new<br />(2 threads)</th><th>new<br />(4 threads)</th><th>new<br />(8 threads)</th></tr><tr><th>inproc</th><td align="right">6.23</td><td align="right">8.47</td><td align="right">6.56</td><td align="right">9.93</td><td align="right">11.0</td><td align="right">11.2</td></tr><tr><th>ipc</th><td align="right">15.7</td><td align="right">22.6</td><td align="right">27.7</td><td align="right">29.1</td><td align="right">31.3</td><td align="right">31.0</td></tr><tr><th>tcp</th><td align="right">24.8</td><td align="right">50.5</td><td align="right">41.0</td><td align="right">42.7</td><td align="right">42.9</td><td align="right">42.9</td></tr></tbody></table></div><div><br />All in all, the round trip times are reasonably respectable. I am especially proud of how close I've come within the best inproc time -- a mere 330 nsec separates the Go implementation from the nanomsg native C version. &nbsp;When you factor in the heavy use of go routines, this is truly impressive. &nbsp; To be honest, I suspect that most of those 330 nsec are actually lost in the extra data copy that my inproc implementation has to perform to simulate the "streaming" nature of real transports (i.e. data and headers are not separate on message ingress.)<br /><br />There's a sad side to story as well. &nbsp;TCP handling seems to be less than ideal in Go. &nbsp;I'm guessing that some effort is done to use larger TCP windows, and Nagle may be at play here as well (I've not checked.) Even so, I've made a 20% improvement in latencies for TCP from my first pass.<br /><br />The other really nice thing is near linear scalability when threads (via bumping GOMAXPROCS) are added. &nbsp;There is very, very little contention in my implementation. &nbsp;(I presume some underlying contention for the channels exists, but this seems to be on the order of only a usec or so.) &nbsp;Programs that utilize multiple goroutines are likely to benefit well from this.<br /><h2></h2><h2>Conclusion</h2><div><br /></div>Simplifying the code to avoid certain indirection (extra passes through additional channels and goroutines), and adding a message pooling layer, have yielded enormous performance gains. &nbsp;Go performs quite respectably in this messaging application, comparing favorably with a native C implementation. &nbsp;It also benefits from additional concurrency.<br /><br />One thing I really found was that it took some extra time to get my layering model correct. &nbsp;I traded complexity in the core for some extra complexity in the Protocol implementations. &nbsp;But this avoided a whole other round of context switches, and enormous complexity. &nbsp;My use of linked lists, and the ugliest bits of mutex and channel synchronization around list-based queues, were removed. &nbsp;While this means more work for protocol implementors, the reduction in overall complexity leads to marked performance and reliability gains.<br /><br />I'm now looking forward to putting this code into production use.</div></content><link rel='replies' type='application/atom+xml' href='http://garrett.damore.org/feeds/4903361205291680757/comments/default' title='Post Comments'/><link rel='replies' type='text/html' href='http://www.blogger.com/comment.g?blogID=7528831701633643336&postID=4903361205291680757' title='0 Comments'/><link rel='edit' type='application/atom+xml' href='http://www.blogger.com/feeds/7528831701633643336/posts/default/4903361205291680757'/><link rel='self' type='application/atom+xml' href='http://www.blogger.com/feeds/7528831701633643336/posts/default/4903361205291680757'/><link rel='alternate' type='text/html' href='http://garrett.damore.org/2014/04/sp-protocols-improved-again.html' title='SP protocols improved again!'/><author><name>Garrett D'Amore</name><uri>https://plus.google.com/101751336283999515602</uri><email>noreply@blogger.com</email><gd:image rel='http://schemas.google.com/g/2005#thumbnail' width='32' height='32' src='//lh3.googleusercontent.com/-iK1shT81XTE/AAAAAAAAAAI/AAAAAAAAAJA/MSN7V7X_7mM/s512-c/photo.jpg'/></author><thr:total>0</thr:total></entry><entry><id>tag:blogger.com,1999:blog-7528831701633643336.post-3285456204920379322</id><published>2014-03-27T09:27:00.000-07:00</published><updated>2014-03-27T09:27:30.733-07:00</updated><title type='text'>Names are Hard</title><content type='html'>So I've been thinking about naming for <a href="http://bitbucket.org/gdamore/sp">my pure Go implementation</a> of <a href="http://nanomsg.org/">nanomsg</a>'s SP protocols.<br /><br />nanomsg is trademarked by the inventor of the protocols. &nbsp;(He does seem to take a fairly loose stance with enforcement though -- since he advocates using names that are derived from nanomsg, as long as its clear that there is only one "nanomsg".)<br /><br />Right now my implementation is known as "bitbucket.org/gdamore/sp". &nbsp;While this works for code, it doesn't exactly roll off the tongue. &nbsp;Its also a problem for folks wanting to write about this. &nbsp;So the name can actually become a barrier to adoption. &nbsp;Not good.<br /><br />I suck at names. &nbsp;After spending a day online with people, we came up with "<a href="http://www.illumos.org/">illumos</a>" for the other open source project I founded. &nbsp;illumos has traction now, but even that name has problems. &nbsp;(People want to spell it "illumOS", and they often mispronounce it as "illuminos" &nbsp;(note there are no "n"'s in illumos). &nbsp;And, worse, it turns out that the leading "i" is indistinguishable from the following "l's" -- like this:&nbsp;<span style="font-family: helvetica;">Illumos</span> -- &nbsp;when used in many common san-serif fonts -- which is why I never capitalize illumos. &nbsp;Its also had a profound impact on how I select fonts. &nbsp;Good-bye Helvetica!)<br /><br />go-nanomsg already exists, btw, but its a simple foreign-function binding, with a number of limitations, so I hope Go programmers will choose my version instead.<br /><br />Anyway, I'm thinking of two options, but I'd like criticisms and better suggestions, because I need to fix this problem soon.<br /><br />1. "gnanomsg" -- the "g" evokes "Go" (or possibly "Garrett" if I want to be narcissistic about it -- but I don't like vanity naming this way). &nbsp;In pronouncing it, one could either use a silent "g" like "gnome" or "gnat", or to distinguish between "nanomsg" one could harden the "g" like in "growl". &nbsp; The problem is that pronunciation can lead to confusion, and I really don't like that "g" can be mistaken to mean this is a GNU program, when it most emphatically is <i>not</i>&nbsp;a GNU. &nbsp;Nor is it GPL'd, nor will it <i>ever</i>&nbsp;be.<br /><br />2. "masago" -- this name distantly evokes "messaging ala go", is a <a href="http://blog.orlandoichiban.com/2010/01/what-is-masago.html">real world word</a>, and I happen to like sushi. &nbsp;But it will be harder for people looking for nanomsg compatible layers to find my library.<br /><br />I'm leaning towards the first. &nbsp;Opinions from the community solicited.<br /><br /><br /><br /></content><link rel='replies' type='application/atom+xml' href='http://garrett.damore.org/feeds/3285456204920379322/comments/default' title='Post Comments'/><link rel='replies' type='text/html' href='http://www.blogger.com/comment.g?blogID=7528831701633643336&postID=3285456204920379322' title='0 Comments'/><link rel='edit' type='application/atom+xml' href='http://www.blogger.com/feeds/7528831701633643336/posts/default/3285456204920379322'/><link rel='self' type='application/atom+xml' href='http://www.blogger.com/feeds/7528831701633643336/posts/default/3285456204920379322'/><link rel='alternate' type='text/html' href='http://garrett.damore.org/2014/03/names-are-hard_27.html' title='Names are Hard'/><author><name>Garrett D'Amore</name><uri>https://plus.google.com/101751336283999515602</uri><email>noreply@blogger.com</email><gd:image rel='http://schemas.google.com/g/2005#thumbnail' width='32' height='32' src='//lh3.googleusercontent.com/-iK1shT81XTE/AAAAAAAAAAI/AAAAAAAAAJA/MSN7V7X_7mM/s512-c/photo.jpg'/></author><thr:total>0</thr:total></entry><entry><id>tag:blogger.com,1999:blog-7528831701633643336.post-5202122699299016631</id><published>2014-03-26T22:30:00.001-07:00</published><updated>2014-03-26T22:30:49.037-07:00</updated><title type='text'>Early performance numbers</title><content type='html'>I've added a benchmark tool to <a href="https://bitbucket.org/gdamore/sp">my Go</a> implementation of <a href="http://www.nanomsg.org/">nanomsg</a>'s SP protocols, along with the inproc transport, and I'll be pushing those changes rather shortly.<br /><div><br /></div><div>In the meantime, here's some interesting results:</div><div><br /></div><table border="2"><caption>Latency Comparision<br />(usec/op)</caption><tbody><tr><th>transport</th><th>nanomsg 0.3beta</th><th>gdamore/sp</th></tr><tr><th>inproc</th><td>6.23</td><td>8.47</td></tr><tr><th>ipc</th><td>15.7</td><td>22.6</td></tr><tr><th>tcp</th><td>24.8</td><td>50.5</td></tr></tbody></table><div><br /><br /><div class="p1">The numbers aren’t all that surprising. &nbsp;Using go, I’m using non-native interfaces, and my use of several goroutines to manage concurrency probably creates a higher number of context switches per exchange. &nbsp;I <i>suspect</i> I might find my stuff does a little better with lots and lots of servers hitting it, where I can make better use of multiple CPUs (though one could write a C program that used threads to achieve the same effect).</div><div class="p1"><br /></div><div class="p1">The story for throughput is a little less heartening though:</div><div class="p1"><br /></div><div class="p1"><br /></div></div><table border="2"><caption>Throughput Comparision<br />(Mb/s)</caption><tbody><tr><th>transport</th><th>message size</th><th>nanomsg 0.3beta</th><th>gdamore/sp</th></tr><tr><th>inproc</th><td>4k</td><td>4322</td><td>5551</td></tr><tr><th>ipc</th><td>4k</td><td>9470</td><td>2379</td></tr><tr><th>tcp</th><td>4k</td><td>9744</td><td>2515</td></tr><tr><th>inproc</th><td>64k</td><td>83904</td><td>21615</td></tr><tr><th>ipc</th><td>64k</td><td>38929</td><td>7831 (?!?)</td></tr><tr><th>tcp</th><td>64k</td><td>30979</td><td>12598</td></tr></tbody></table><br />I didn't try larger sizes yet, this is just a quick sample test, not an exhaustive performance analysis. &nbsp;What is interesting is that the ipc case for my code is consistently low. &nbsp;It uses the same underlying transport to Go as TCP, but I guess maybe we are losing some TCP optimizations. &nbsp;(Note that the TCP tests were performed using loopback, I don't really have 40GbE on my desktop Mac. :-)<br /><br />I think my results may be worse than they would otherwise be, because I use the equivalent of NN_MSG to dynamically allocate each message as it arrives, whereas the nanomsg benchmarks use a preallocated buffer. &nbsp; Right now I'm not exposing an API to use preallocated buffers (but I have considered it! &nbsp;It does feel unnatural though, and more of a "benchmark special".)<br /><br />That said, I'm not <i>unhappy</i>&nbsp;with these numbers. &nbsp;Indeed, it seems that my code performs reasonably well given all the cards stacked against it. &nbsp;(Extra allocations due to the API, extra context switches due to extra concurrency using channels and goroutines in Go, etc.)<br /><br />A litte more details about the tests.<br /><br />All test were performed using nanomsg 0.3beta, and my current Go 1.2 tree, running on my Mac running MacOS X 10.9.2, on 3.2 GHz Core i5. &nbsp;The latency tests used full round trip timing using the REQ/REP topology, and a 111 byte message size. &nbsp;The throughput tests were performed using PAIR. &nbsp;(Good news, I've now validated PAIR works. :-)<br /><br />The IPC was directed at file path in /tmp, and TCP used 127.0.0.1 ports.<br /><br />Note that my inproc tries hard to avoid copying, but does still copy due to a mismatch about header vs. body location. &nbsp;I'll probably fix that in a future update (its an optimization, and also kind of a benchmark special since I don't think inproc gets a lot of performance critical use. &nbsp;In Go, it would be more natural to use channels for that.<br /><div><br /></div></content><link rel='replies' type='application/atom+xml' href='http://garrett.damore.org/feeds/5202122699299016631/comments/default' title='Post Comments'/><link rel='replies' type='text/html' href='http://www.blogger.com/comment.g?blogID=7528831701633643336&postID=5202122699299016631' title='4 Comments'/><link rel='edit' type='application/atom+xml' href='http://www.blogger.com/feeds/7528831701633643336/posts/default/5202122699299016631'/><link rel='self' type='application/atom+xml' href='http://www.blogger.com/feeds/7528831701633643336/posts/default/5202122699299016631'/><link rel='alternate' type='text/html' href='http://garrett.damore.org/2014/03/early-performance-numbers.html' title='Early performance numbers'/><author><name>Garrett D'Amore</name><uri>https://plus.google.com/101751336283999515602</uri><email>noreply@blogger.com</email><gd:image rel='http://schemas.google.com/g/2005#thumbnail' width='32' height='32' src='//lh3.googleusercontent.com/-iK1shT81XTE/AAAAAAAAAAI/AAAAAAAAAJA/MSN7V7X_7mM/s512-c/photo.jpg'/></author><thr:total>4</thr:total></entry><entry><id>tag:blogger.com,1999:blog-7528831701633643336.post-7592756121287745743</id><published>2014-03-24T22:39:00.000-07:00</published><updated>2014-03-24T22:39:57.831-07:00</updated><title type='text'>SP (nanomsg) in Pure Go</title><content type='html'>I'm pleased to announce that this past weekend I <a href="https://bitbucket.org/gdamore/sp">released the first version</a> of my implementation of the SP (scalability protocols, sometimes known by their reference implementation, <a href="http://nanomsg.org/">nanomsg</a>) implemented in pure <a href="http://golang.org/">Go</a>. This allows them to be used even on platforms where cgo is not present. &nbsp;It may be possible to use them in playground (I've not tried yet!)<br /><br />This is released under an <a href="http://www.apache.org/licenses/LICENSE-2.0.html">Apache 2.0 license</a>. &nbsp;(It would be even more liberal BSD or MIT, except I want to offer -- and demand -- patent protection to and from my users.)<br /><br />I've been super excited about Go lately. &nbsp;And having spent some time with ØMQ in a previous project, I was keen to try doing some things in the successor nanomsg project. &nbsp; (nanomsg is a single library message queue and communications library.)<br /><br />Martin (creator of <a href="http://zeromq.org/">ØMQ</a>) has <a href="http://250bpm.com/blog:4">written rather extensively</a> about how he wishes he had written it in C instead of C++. &nbsp;And with nanomsg, that is exactly what he is done.<br /><br />And C is a great choice for implementing something that is intended to be a foundation for other projects. &nbsp;But, its not ideal for some circumstances, and the use of async I/O in his C library tends to get in the way of Go's native support for concurrency.<br /><br />So my pure Go version is available in a form that makes the best use of Go, and tries hard to follow Go idioms. &nbsp;It doesn't support all the capabilities of Martin's reference implementation -- yet -- but it will be easy to add those capabilities.<br /><br />Even better, I found it pretty easy to add a new transport layer (TLS) this evening. &nbsp;Adding the implementation took less than a half hour. &nbsp;The real work was in writing the test program, and fighting with OpenSSL's obtuse PKI support for my test cases.<br /><br />Anyway, I encourage folks to take a look at it. &nbsp;I'm keen for useful &amp; constructive criticism.<br /><br />Oh, and this work is stuff I've done on my own time over a couple of weekends -- and hence isn't affiliated with, or endorsed by, any of my employers, past or present.<br /><br />PS: Yes, it should be possible to "adapt" this work to support native ØMQ protocols (ZTP) as well. &nbsp;If someone wants to do this, please fork this project. &nbsp;I don't think its a good idea to try to support both suites in the same package -- there are just too many subtle differences.</content><link rel='replies' type='application/atom+xml' href='http://garrett.damore.org/feeds/7592756121287745743/comments/default' title='Post Comments'/><link rel='replies' type='text/html' href='http://www.blogger.com/comment.g?blogID=7528831701633643336&postID=7592756121287745743' title='2 Comments'/><link rel='edit' type='application/atom+xml' href='http://www.blogger.com/feeds/7528831701633643336/posts/default/7592756121287745743'/><link rel='self' type='application/atom+xml' href='http://www.blogger.com/feeds/7528831701633643336/posts/default/7592756121287745743'/><link rel='alternate' type='text/html' href='http://garrett.damore.org/2014/03/sp-nanomsg-in-pure-go.html' title='SP (nanomsg) in Pure Go'/><author><name>Garrett D'Amore</name><uri>https://plus.google.com/101751336283999515602</uri><email>noreply@blogger.com</email><gd:image rel='http://schemas.google.com/g/2005#thumbnail' width='32' height='32' src='//lh3.googleusercontent.com/-iK1shT81XTE/AAAAAAAAAAI/AAAAAAAAAJA/MSN7V7X_7mM/s512-c/photo.jpg'/></author><thr:total>2</thr:total></entry><entry><id>tag:blogger.com,1999:blog-7528831701633643336.post-2555468172036091710</id><published>2014-02-06T09:54:00.001-08:00</published><updated>2014-02-06T09:54:44.187-08:00</updated><title type='text'>The Failed Promise</title><content type='html'>My dislike for C++ is well-known by those who know me. &nbsp;As is my lack of fondness for Perl.<div><br /></div><div>I have a new one though. &nbsp;Java. &nbsp;Oracle and Apple have conspired to kill it.</div><div><br /></div><div>(I should say this much -- its been a long time, about a decade, since I developed any Java code. &nbsp;Its entirely possible that I remember the language with more fondness than it truly warrants. &nbsp;C++ was once beautiful too -- before ANSI went and mutated it beyond all hope back in 1990 or thereabouts.)</div><div><br /></div><div>Which is a shame, because Java started with <i>such</i>&nbsp;promise. &nbsp;Write-once, run-anywhere. &nbsp;Strongly typed, and a paradigm for OO that was so far superior to C++. &nbsp;(Multiple inheritance is the bane of semi-competent C++ engineers, who often can't even properly cope with pointers to memory.)</div><div><br /></div><div>For years, I bemoaned the fact that the single biggest weakness of Java was the fact that it was seen as a way to make more dynamic web pages. &nbsp;(I remember HotJava -- what a revolutionary thing it was indeed.) &nbsp;But even stand-alone apps struggled with performance (startup times were hideous for anyone starting a Swing app.)</div><div><br /></div><div>Still, we suffered because of the write once, run-anywhere promise was just too alluring. &nbsp;All those performance problems were going to get solved by optimization, and faster systems. &nbsp;And wasn't it a shame that people associated Java with applets instead of applications? &nbsp;(Java WebStart tried to drive more of the latter, which should have been a good thing.)</div><div><br /></div><div>But all the promise that Java seemed to offer is well and truly lost now. &nbsp;And I don't think it can ever be regained.&nbsp;</div><div><br /></div><div>Here's a recent experience I had.</div><div><br /></div><div>I had reason to go run some Java code to access an IPMI console on a SuperMicro system. &nbsp;I don't run Windows. &nbsp; The IPMI console app seems to be a mishmash of Java and native libraries produced by ATEN for SuperMicro. &nbsp;Supposedly it supported MacOS X and Linux.</div><div><br /></div><div>I lost several&nbsp;<i>hours</i>&nbsp;(<b>several</b>, as in more than two) trying to get a working IPMI console on my Mac. &nbsp;I tried Java 7 from Oracle, Java 6 from Apple, I even tried to get a Linux version working in Ubuntu (and after a number of false starts I did actually succeed in the last attempt.) &nbsp;All just to get access to a simple IPMI console. &nbsp;Seriously?!?</div><div><br /></div><div>What are the problems here?</div><div><ul><li>Apple doesn't "support" Java officially anymore.</li><li>Apple disables Java by default on Safari even when it is installed.</li><li>Apple disables Java webstart almost entirely. &nbsp;(The only way to open an unsigned Java webstart file -- has anyone ever even <i>seen</i>&nbsp;a signed .jnlp?)&nbsp;is to download it, and open it with a right-click in the finder and explicitly answer "Yes, I know its not from an approved vendor, but open the darn thing anyway. &nbsp;Even though <i>Java</i>&nbsp;also asks me the same question. &nbsp;Several times.)</li><li>Oracle ships Java 7 without 32-bit support on Macs, so only Safari can use it (not Chrome)</li><li>Oracle Java 7 Update 51 has a new security manager that prevents most unsigned apps from running at all. &nbsp;(The only way to get them to run at all is to track down the Java preferences pane and reduce the security setting.)</li><li>Developers like ATEN produce native libraries which means that their "Java" apps are totally unportable.</li></ul></div><div>All of this is because people are terrified of the numerous bugs in Java. &nbsp;Which is appropriate, since there <i>have</i>&nbsp;been bugs in various JVMs. &nbsp;Running unverified code without some warning to the end-user is dangerous -- really these should be treated with the same caution due a native application.</div><div><br /></div><div>But, I should also not have to be a digital contortionist to access an application. &nbsp;I am using a native IPMI console from an IP address that I entered by hand on a secured network. &nbsp;I'd expect to have to answer the "Are you sure you want to run this unsigned app?" question (perhaps with an option to remember the setting) once. &nbsp;But the barriers to actually executing the app are far too high. &nbsp;(So high, that I <i>still</i>&nbsp;have not had success in getting the SuperMicro IPMI console running on my Mac -- although I did eventually get it to work in a VM running Ubuntu.)</div><div><br /></div><div>So, shame on Apple and Oracle for doing everything in their power to kill Java. &nbsp;Shame on ATEN / SuperMicro for requiring Java in the first place, and for polluting it with native code libraries. &nbsp;And for not getting their code signed.</div><div><br /></div><div>And shame on the Java ecosystem for allowing this state of affairs to come about.</div><div><br /></div><div>I'll most likely never write another line of Java, in spite of the fact that I happen to think the language is actually quite elegant for solving OO programming problems. &nbsp;The challenges in deploying such applications are just far too high. &nbsp;In the past the problem was that the cost of the sandbox meant that application startups are slow. &nbsp;Now, even though we have fast CPUs, we have traded 30 second application startup times for situations where it takes <i>hours</i>&nbsp;for even technical people to get an app running.</div><div><br /></div><div>I guess its probably better on Windows.</div><div><br /></div><div>But if you want to use that as an excuse, then just write a NATIVE APPLICATION, and stop screwing around with this false promise of "run-anywhere".&nbsp;</div><div><br /></div><div>If a Javascript app won't work for you, then just bite the bullet and write a native app. &nbsp;Heck, with the porting solutions available, it isn't that much work to make native apps portable to a variety of platforms. &nbsp;(Though such solutions necessarily leave niche systems out in the cold. &nbsp;Let's face it, the market for native desktop apps on SPARC systems running NetBSD is pretty tiny.) &nbsp;But covering the 5 mainstream client platforms (Windows, Mac, iOS, Android, Linux) is pretty easy. &nbsp;(Yes, illumos isn't in that list. &nbsp;And maybe Linux shouldn't be either, although I think the number of folks running a desktop with Linux is probably several orders of magnitude larger than all other UNIXish platforms -- besides MacOS -- combined.)</div><div><br /></div><div>And, RIP "write once, run-anywhere". &nbsp;Congratulations Oracle, Apple. &nbsp;You killed it.</div></content><link rel='replies' type='application/atom+xml' href='http://garrett.damore.org/feeds/2555468172036091710/comments/default' title='Post Comments'/><link rel='replies' type='text/html' href='http://www.blogger.com/comment.g?blogID=7528831701633643336&postID=2555468172036091710' title='3 Comments'/><link rel='edit' type='application/atom+xml' href='http://www.blogger.com/feeds/7528831701633643336/posts/default/2555468172036091710'/><link rel='self' type='application/atom+xml' href='http://www.blogger.com/feeds/7528831701633643336/posts/default/2555468172036091710'/><link rel='alternate' type='text/html' href='http://garrett.damore.org/2014/02/the-failed-promise.html' title='The Failed Promise'/><author><name>Garrett D'Amore</name><uri>https://plus.google.com/101751336283999515602</uri><email>noreply@blogger.com</email><gd:image rel='http://schemas.google.com/g/2005#thumbnail' width='32' height='32' src='//lh3.googleusercontent.com/-iK1shT81XTE/AAAAAAAAAAI/AAAAAAAAAJA/MSN7V7X_7mM/s512-c/photo.jpg'/></author><thr:total>3</thr:total></entry><entry><id>tag:blogger.com,1999:blog-7528831701633643336.post-2416913314770612199</id><published>2014-01-29T15:42:00.003-08:00</published><updated>2014-01-29T15:42:44.786-08:00</updated><title type='text'>Sorry for the interruption....</title><content type='html'>Some of you may have noticed that my email, or my blog, or website, was down.<br /><br />I discontinued my hosting service with BlueHost, and when I did, I mistakenly thought that by keeping my domain registration with them, that I'd still have DNS services. &nbsp;It was both a foolish mistake, and yet an easy one to make. &nbsp;(I should have known better...)<br /><br />Anyway, things are back to normal now, once the interweb's negative caches have timed out...<br /><br />It does seem unfortunate that BlueHost:<br /><br /><br /><ul><li>Does not include DNS with domain registration, nor do they have a service for it unless you actually host content with them.</li><li>Did not backup my DNS zone data. &nbsp;(So even if I paid them to reactivate hosting, I was going to have to re-enter my zone records by hand.) &nbsp;This is just stupid.</li></ul><br />So, I've moved my DNS, and when my registration expires, I'll be moving that to another provider as well. &nbsp;(Dyn, in case you wondered.)</content><link rel='replies' type='application/atom+xml' href='http://garrett.damore.org/feeds/2416913314770612199/comments/default' title='Post Comments'/><link rel='replies' type='text/html' href='http://www.blogger.com/comment.g?blogID=7528831701633643336&postID=2416913314770612199' title='0 Comments'/><link rel='edit' type='application/atom+xml' href='http://www.blogger.com/feeds/7528831701633643336/posts/default/2416913314770612199'/><link rel='self' type='application/atom+xml' href='http://www.blogger.com/feeds/7528831701633643336/posts/default/2416913314770612199'/><link rel='alternate' type='text/html' href='http://garrett.damore.org/2014/01/sorry-for-interruption.html' title='Sorry for the interruption....'/><author><name>Garrett D'Amore</name><uri>https://plus.google.com/101751336283999515602</uri><email>noreply@blogger.com</email><gd:image rel='http://schemas.google.com/g/2005#thumbnail' width='32' height='32' src='//lh3.googleusercontent.com/-iK1shT81XTE/AAAAAAAAAAI/AAAAAAAAAJA/MSN7V7X_7mM/s512-c/photo.jpg'/></author><thr:total>0</thr:total></entry><entry><id>tag:blogger.com,1999:blog-7528831701633643336.post-8804127152337960786</id><published>2014-01-18T16:40:00.000-08:00</published><updated>2014-01-18T16:40:36.126-08:00</updated><title type='text'>Worst Company ... Ever</title><content type='html'>So I've not blogged in a while, but my recent experience with a major mobile provider was so astonishingly bad that I feel compelled to write about my experiences. &nbsp;(Executive summary: never do business with T-mobile again!)<br /><br />I had some friends out from Russia back in November, and they wanted to purchase an iPhone 5s for their son as a birthday gift. &nbsp;Sadly, we couldn't get unlocked ones from the Apple Store at the time, because they simply lacked inventory.<br /><br />So we went to the local T-mobile store here on San Marcos Blvd (San Marcos, CA.) &nbsp;I knew that they were offering phones for full-price (not subsidized), and it seemed like a possible way for them to get a phone. &nbsp;Tiffany was the customer service agent that "assisted" us. &nbsp;She looked like she was probably barely out of high school, &nbsp;but anyway she seemed pleased to help us make a purchase. &nbsp;I asked her no fewer than three times whether the phone was unlocked, and was assured that, yes, the phone was unlocked and would work fine with Russian GSM operators. &nbsp;I was told that in order for T-mobile to sell us the phone, we had to purchase a 1-month prepaid plan for $50, and a $10 sim card. &nbsp;While I was little annoyed at this, I understood that this was their prerogative, and the cost of wanting to buy the device "right now" and not being able to wait 2 weeks for Apple to ship one. &nbsp;(My friends had less than a week left in California at this time.) &nbsp;We were buying the phone outright, so it seemed like there ought to be no reason for the device to have a carrier lock on it.<br /><br />So, <i>of course</i>, the phone was <b>not</b>&nbsp;unlocked. &nbsp;It didn't work at all when it got to Russia. &nbsp;Clearly Tiffany didn't have a clue about the product she sold us. &nbsp;I guess I shouldn't have been too surprised. But we had put down $760 in cash for a device that now didn't work. &nbsp;Worst of all, I was embarrassed, as was my friend, when his son got what was essentially a lemon for his birthday gift.<br /><br />I was pretty upset, and went back to the store. &nbsp;Tiffany was there, and apologized. &nbsp;She offered to pay up to $25 for me to use a third party service to unlock the phone since "it was her fault". &nbsp;Of course, the third party service stopped offering this for iPhones, and their cost for iPhone 5's was over $100 when they <i>were</i>&nbsp;offering it.<br /><br />I tried to get T-mobile to unlock the phone. &nbsp;I waited in the store for a manager for about 2 hours, but Tiffany finally got upset and called the police to get me to leave the store after I indicated that I preferred to wait on the premises for a manager. &nbsp; I left the store premises, unhappy, but resolved to deal with this through the corporate office.<br /><br />I went home, and called T-mobile customer service. &nbsp;It turns out that T-mobile store is really a 3rd party company, even though they wear T-mobile shirts, and exclusively offer T-mobile products. &nbsp;(More on that later.)<br /><br />I spent quite a few hours on the phone with T-mobile. &nbsp;Somewhere in the process, the customer service people called Tiffany, whereupon she immediately reversed her story, claiming she <i>had</i>&nbsp;informed me that the phone was locked. &nbsp;This was just the first of a number of false and misleading statements that were made to me by T-mobile or its affiliates. &nbsp; I spent several hours on the phone that day. &nbsp;At the end of the call, I was told that T-mobile would unlock my phone only <i>after</i>&nbsp;at least 40 days had passed from the date of activation. &nbsp; The person at corporate assured me that if I would just wait the 40 days, then I'd be able to get the phone unlocked. &nbsp;Since the phone was already in Russia, I figured it would take at least that long to send it back and send a replacement from another carrier.<br /><br />Oh one other thing. &nbsp;During that first call, I discovered that Tiffany had actually taken the $50 prepaid plan we purchased, and kept it for herself or her friends. &nbsp;We didn't figure that out until T-mobile customer service told me that I didn't have a plan at all. &nbsp;Nice little scam. &nbsp;While dishonest, I would not have begrudged the action had the phone actually worked. &nbsp;Of course it didn't.<br /><br />(During all this, on several different occasions, T-mobile customer service personnel tried to refer me to the same 3rd party unlocking service. &nbsp;Because hey, if T-mobile can't get its own phones unlocked, maybe their customers should pay some shady third party service to get it done for them. &nbsp;But it turns out that whatever backdoor deal that service had previously doesn't work anymore, because they've stopped doing it for Apple phones.)<br /><br />So we waited 40 days.<br /><br />And then we called to have the phone unlocked.<br /><br />And T-mobile refused again. &nbsp;This time I was told that I needed to have $50.01 or more, not just $50 on the plan. &nbsp;After a few more hours on the phone and escalation up through a few levels of their management chain, they credited my account for $0.20, and then resubmitted the unlock request. &nbsp;I was <i>guaranteed</i>&nbsp;that the phone would be unlocked.<br /><br />Two days later, T-mobile denied the unlock request.<br /><br />At this point, I was informed that the phone had to have T-mobile activity on it within 7 days of the unlock request. &nbsp;This was simply not going to happen. &nbsp;The phone was in Russia! &nbsp;I complained, and I spent quite a few more hours on the phone with T-mobile. &nbsp;It seems like the folks who control the unlocking process of their phones have <i>nothing</i>&nbsp;to do with the people who answer their customer service lines, nor those people's bosses, nor <i>those</i>&nbsp;people's bosses. &nbsp;Astonishing!<br /><br />At this point I had spent over a dozen hours trying to get T-mobile to unlock the darned thing. &nbsp;T-mobile had got their money from me already, and had done pretty much everything possible to upset me. &nbsp;The amount of money T-mobile spent dealing on the phone with me, trying to enforce a stupid policy, which wouldn't have been necessary if they had just admitted their mistake <i>and fixed it (which would have cost them nothing&nbsp;whatsoever)</i>&nbsp;is astonishing. &nbsp;Talk about penny-wise and pound foolish.<br /><br />At that time, T-mobile told me that I would be able to return the other phone, provided I got it back from Russia. &nbsp;They agreed to this even though the usual 14 days "buyer's remorse" window had passed.<br /><br />So at this point, I went and purchased a phone from Verizon (and paid a $50 premium because I was at BestBuy instead of the Apple store and the Verizon store wouldn't sell the phone unless it was part of a plan), and I sent it to Russia with my step-son, who was going their for Christmas. &nbsp;That phone <i>did</i>&nbsp;work, and my step-son exchanged the T-mobile phone for it, bringing the T-mobile phone back.<br /><br />The next day, I went to return the phone at the store where I bought it. &nbsp;Sadly, Tiffany was there. &nbsp;So was her manager, Erica.<br /><br />After spending about an hour at the store trying to return it, they agreed to take it back, minus a $50 restocking fee. &nbsp;And as I paid cash, I had to provide my checking account information so they could do a deposit for me, which would take a few days. &nbsp;I got a paper showing that they were sending me a refund, but nothing indicating the account number. &nbsp;(Turns out it took a few calls from Erica -- who claimed to be the store manager and probably was about 10 minutes older than Tiffany -- the next day, since she apparently had no clue what she was doing and needed to get two separate pieces of information that she failed to collect while I was in the story.)<br /><br />I did spend a bunch of time with customer service on the phone -- a few more hours I guess, trying to get that last $50. &nbsp;At this point it was just a matter of principle. &nbsp;I resented the whole thing, and I wanted as much of my money back as possible. &nbsp;The customer service person tried to make it right, but because the store (Hit Mobile is the company apparently) is separate from T-mobile, the store's decision was final. &nbsp;The store manager (Erica) refused to refund the stocking fee, and there was nothing T-mobile could do about it. &nbsp;To their credit, they <i>did</i>&nbsp;offer me a $50 service credit if I was inclined to keep an account with them. &nbsp;Needless to say, I have <i>no</i>&nbsp;interest in ever being a T-mobile customer, so I thanked them and declined... indicating that I'd prefer to have funds back in cash. &nbsp;(Nobody ever mentioned the restocking fee; on the contrary I was told I'd receive the full purchase price less the $60 service plan and SIM card. &nbsp;Again, story and reality don't match at T-mobile.)<br /><br />I did eventually get $650 credited back to my account.<br /><br />So, I was out $110, plus the extra $50, plus the 13+ hours of my time, plus the embarrassment and long turnaround time to get the replacement out to Russia. &nbsp;All because T-mobile wouldn't fix a mistake they made, even though numerous people at that company recognized that it was clearly the Right Thing To Do.<br /><br />Turns out that Verizon iPhones are all unlocked. &nbsp;And I'm already a Verizon customer. &nbsp;I was thinking about T-mobile's plans -- some of them are attractive on paper, and potentially could have saved me money relative the rather premium prices I pay for Verizon. &nbsp;Needless to say, I will <i>not</i>&nbsp;be changing my provider any time soon. &nbsp;In spite of the high prices, I've always been dealt with honestly and fairly, and I've been happy with the service I've gotten at Verizon.<br /><br />If for some reason, you decide to get a T-mobile phone, please, please avoid the store located on San Marcos Blvd. &nbsp;In fact, I urge you to verify that the store is owned by T-mobile corporation. &nbsp;Its my belief that I might have had more satisfactory results had I been dealing with just a single entity. &nbsp;That said, numerous people at T-mobile corporate lied to me and made false promises.<br /><br />I feel so strongly about this, that I'm happy to have spent the hour or so writing up my terrible experiences with them. &nbsp;I hope that I save someone else these painful experiences. &nbsp;I won't be unhappy if it also costs T-mobile many potential customers.<br /><br />For the record, I also think it should be illegal to sell a carrier locked device without clearly indicating this is so as part of the transaction. &nbsp;The practice of carrier locking devices makes sense when the cost of the device is being subsidized by the carrier as part of a service plan. &nbsp;But it should be possible to purchase the device outright and remove any such lock. &nbsp;T-mobile's practices here are a disservice to their customers, and their partners. &nbsp;The handset manufacturers should apply pressure to them to get them to change their policy here.</content><link rel='replies' type='application/atom+xml' href='http://garrett.damore.org/feeds/8804127152337960786/comments/default' title='Post Comments'/><link rel='replies' type='text/html' href='http://www.blogger.com/comment.g?blogID=7528831701633643336&postID=8804127152337960786' title='0 Comments'/><link rel='edit' type='application/atom+xml' href='http://www.blogger.com/feeds/7528831701633643336/posts/default/8804127152337960786'/><link rel='self' type='application/atom+xml' href='http://www.blogger.com/feeds/7528831701633643336/posts/default/8804127152337960786'/><link rel='alternate' type='text/html' href='http://garrett.damore.org/2014/01/worst-company-ever.html' title='Worst Company ... Ever'/><author><name>Garrett D'Amore</name><uri>https://plus.google.com/101751336283999515602</uri><email>noreply@blogger.com</email><gd:image rel='http://schemas.google.com/g/2005#thumbnail' width='32' height='32' src='//lh3.googleusercontent.com/-iK1shT81XTE/AAAAAAAAAAI/AAAAAAAAAJA/MSN7V7X_7mM/s512-c/photo.jpg'/></author><thr:total>0</thr:total></entry><entry><id>tag:blogger.com,1999:blog-7528831701633643336.post-8030092895269029694</id><published>2013-10-17T22:17:00.002-07:00</published><updated>2013-10-17T22:17:21.672-07:00</updated><title type='text'>illumos corporate entity... non-starter?</title><content type='html'><div dir="ltr" style="text-align: left;" trbidi="on">I want to give folks a status update on the <a href="http://www.illumos.org/">illumos</a> corporate entity.<div><br /></div><div>In a nutshell, the corporate entity seems to be failing to have traction. &nbsp;In particular, the various corporate contributors &nbsp;and downstreams for illumos have declined to step up to ensure that an illumos corporate entity has sufficient backing to make it successful.</div><div><br /></div><div>While at first blush, this seems somewhat unfortunate, I think this is not nearly quite as bad a thing as it might first seem. &nbsp;In particular, the failure of a corporate entity does not correlate to the health of the ecosystem -- indeed many successful open source projects operate without an umbrella organization or entity.&nbsp;</div><div><br /></div><div>Instead, we see corporate contributors and downstream distributions focusing on developing the communities behind their distributions such as <a href="http://www.smartos.org/">SmartOS</a> and <a href="http://omnios.omniti.com/">OmniOS</a>. &nbsp;Those downstreams play an active role in improving illumos for the benefit of all, and its my sincere hope and belief that they will continue to evangelize illumos, and contribute to the common core.</div><div><br /></div><div>Furthermore, incorporation in the state of California requires paying about $800 of taxes per year. &nbsp;This is true even for organizations without any revenue. &nbsp;This is money that would have to be taken from sponsors that would serve only to enrich our state government with no direct benefit to the illumos community. &nbsp;(Non-profit status is a way around that, but its exceedingly difficult to obtain, and a number of <a href="http://programming.oreilly.com/2013/06/irs-wasnt-fond-of-open-source-either.html">open source organizations are finding themselves under very close scrutiny</a> from the state and federal authorities. &nbsp; &nbsp;Indeed, the <a href="http://x.org/">X.org</a> community themselves <a href="http://slashdot.org/story/13/08/27/1244247/xorg-foundation-loses-501c3-non-profit-status">lost</a> their 501(c)3 status not that long ago.)</div><div><br /></div><div>So, without corporate sponsors to justify the tax and administrative load, I've decided that the illumos corporate entity should expire. &nbsp;I do want to thank <a href="http://www.beginningwithi.com/">Deirdré Straughan</a> for the non-trivial amount of effort she put into this, as well as the <a href="http://softwarefreedom.org/">Software Freedom Law Center</a> for the pro-bono work they did for us while we were trying to navigate the waters of becoming a true non-profit open source organization.</div><div><br /></div><div>And, if any corporate sponsors are out there watching this, and interested in resurrecting the illumos organization, then I'm happy to entertain the possibilities. &nbsp;I think there is value in an actual organization with a legal status to receive and distribute funds, and who can hold certain items of intellectual property, including the rights to the illumos trademark itself. &nbsp; But there has to be enough of a sponsorship behind this to make it worthwhile.</div><div><br /></div><div>In the meantime, I will continue to hold the illumos mark as a trademark that I keep in trust for the community. &nbsp;The <i>code</i>&nbsp;is something that is already subject to distributed ownership, and so is completely unimpacted by any of this.</div><div><br /></div><div>Thanks.</div><div><br /></div><div>&nbsp; - Garrett</div><div><br /></div></div></content><link rel='replies' type='application/atom+xml' href='http://garrett.damore.org/feeds/8030092895269029694/comments/default' title='Post Comments'/><link rel='replies' type='text/html' href='http://www.blogger.com/comment.g?blogID=7528831701633643336&postID=8030092895269029694' title='1 Comments'/><link rel='edit' type='application/atom+xml' href='http://www.blogger.com/feeds/7528831701633643336/posts/default/8030092895269029694'/><link rel='self' type='application/atom+xml' href='http://www.blogger.com/feeds/7528831701633643336/posts/default/8030092895269029694'/><link rel='alternate' type='text/html' href='http://garrett.damore.org/2013/10/illumos-corporate-entity-non-starter.html' title='illumos corporate entity... non-starter?'/><author><name>Garrett D'Amore</name><uri>https://plus.google.com/114484106466928611830</uri><email>noreply@blogger.com</email><gd:image rel='http://schemas.google.com/g/2005#thumbnail' width='32' height='32' src='//lh3.googleusercontent.com/-3UzpztUh9YI/AAAAAAAAAAI/AAAAAAAADRI/7gIavrAWW5k/s512-c/photo.jpg'/></author><thr:total>1</thr:total></entry><entry><id>tag:blogger.com,1999:blog-7528831701633643336.post-1240454310538521045</id><published>2013-10-13T21:45:00.002-07:00</published><updated>2013-10-13T21:45:57.918-07:00</updated><title type='text'>Moving on (Adieu to Studio?)</title><content type='html'><div dir="ltr" style="text-align: left;" trbidi="on">I think illumos is at a key juncture, and the issue relates to our toolchain.<div><br /></div><div>We have gcc 4.4.4 working thanks in large part to the efforts of folks like Rich Lowe.</div><div><br /></div><div>We have historically relied on Sun Studio (now Solaris Studio) as our "base" or "default" compiler for C and C++ programs, and also to supply lint coverage.</div><div><br /></div><div>I've been thinking for a long time that its past time we (the illumos community) moved on from this. &nbsp;Not only are the Studio 12 compilers not available in source form, they are now not available in suitable form for building illumos as binaries either. &nbsp;(Apparently it is possible under some terms to get Solaris Studio 12.3, but who knows if those compilers are suitable for building illumos. &nbsp;In the past we have always needed specifically patched compilers for Solaris.)</div><div><br /></div><div>The situation where a general developer cannot obtain the necessary tool chain for working with illumos is untenable.</div><div><br /></div><div>Today we require "lint" as part of an official build. &nbsp;But not just "any" lint, but lint generated by a specific patched older version of Sun Studio 12. &nbsp;A version that is no longer available to the community at large.</div><div><br /></div><div>(And in full disclosure, the problem for me is brought to a head by the fact that the machine I had my local installation of these tools on has been retired, and I find I don't have another backup of them readily at hand to install on my new machine.)</div><div><br /></div><div>So, I'm placing this as a call to the illumos community at large, and especially to our RTI advocates. &nbsp;Its time. &nbsp;Really.&nbsp;</div><div><br /></div><div>Really.</div><div><br /></div><div>Studio has to go.</div><div><br /></div><div>I don't care if we leave the infrastructure in place for people that want to continue to use Studio, but we need to switch to gcc. &nbsp;Rich's 4.4.4 version gets the job done for now. &nbsp;It would be great if we could support newer versions, but I understand that this requires some non-trivial amount of effort (some gcc patches that need to be upstreamed, as I understand it.)</div><div><br /></div><div>We cannot be tied to a closed tool chain; especially a tool chain that doesn't at least include binary redistribution privileges.&nbsp;</div><div><br /></div><div>For the record, I've posted the same content to the illumos developer and advocates lists.</div></div></content><link rel='replies' type='application/atom+xml' href='http://garrett.damore.org/feeds/1240454310538521045/comments/default' title='Post Comments'/><link rel='replies' type='text/html' href='http://www.blogger.com/comment.g?blogID=7528831701633643336&postID=1240454310538521045' title='2 Comments'/><link rel='edit' type='application/atom+xml' href='http://www.blogger.com/feeds/7528831701633643336/posts/default/1240454310538521045'/><link rel='self' type='application/atom+xml' href='http://www.blogger.com/feeds/7528831701633643336/posts/default/1240454310538521045'/><link rel='alternate' type='text/html' href='http://garrett.damore.org/2013/10/moving-on-adieu-to-studio.html' title='Moving on (Adieu to Studio?)'/><author><name>Garrett D'Amore</name><uri>https://plus.google.com/114484106466928611830</uri><email>noreply@blogger.com</email><gd:image rel='http://schemas.google.com/g/2005#thumbnail' width='32' height='32' src='//lh3.googleusercontent.com/-3UzpztUh9YI/AAAAAAAAAAI/AAAAAAAADRI/7gIavrAWW5k/s512-c/photo.jpg'/></author><thr:total>2</thr:total></entry><entry><id>tag:blogger.com,1999:blog-7528831701633643336.post-5179295673144657187</id><published>2013-08-29T15:07:00.000-07:00</published><updated>2013-08-29T15:07:12.561-07:00</updated><title type='text'>Responding to Trolls</title><content type='html'><div dir="ltr" style="text-align: left;" trbidi="on">We have an... ahem... toxic personality in our midst in <a href="http://www.illumos.org/">illumos</a>. &nbsp;I'm going to respond here to his most recent <a href="http://www.listbox.com/member/archive/182179/2013/08/sort/time_rev/page/1/entry/1:547/20130829164020:36CA17F2-10EB-11E3-AC85-974F16BEB7CA/">post</a>, to avoid wasting the time on the illumos developers mailing list. &nbsp;If you don't care about non-sense like this (although it may have entertainment value), please just ignore this post and move on.<br /><br />The only reason I'm replying even here, is to set the record straight, and establish firmly the history -- at least my side of it -- for posterity.<br /><br />In the early days of illumos, I invited those I could think of from the Solaris and OpenSolaris communities to participate. &nbsp;I even reached out to some parties, like Jörg Schilling, who had a bad reputation as difficult people to work with.<br /><br />I had hoped to repair those broken relationships since there was no longer a corporate controlling entity for illumos. &nbsp;(<a href="http://www.nexenta.com/">Nexenta</a> sponsored my efforts, and paid some of the early operating costs for illumos, but it has always been the case that illumos operates by and for the community -- and not at the behest of any corporate master. &nbsp;As I've since left Nexenta to start my <a href="http://www.dey-sys.com/">own company</a>, and illumos has carried on, I think there is fairly ample evidence in support of this fact.)<br /><br />I reached out, and tried to help Jörg with some integrations; but those integrations did not go well. &nbsp;Jörg did not like our policy requiring a build or test of changes on the primary distribution (<a href="http://www.openindiana.org/">OpenIndiana</a> at the time) used for the vast majority of developers and users, and so several of his changes did not get integrated. &nbsp;(It turns out this was a good thing, because at least one of those changes, a "fix" for a keyboard problem, was mis-designed and would have broken international keyboards for the majority of illumos' user community.)<br /><br />We also required code review, as we do now.<br /><br />Jörg has long had a desire to have "<a href="http://en.wikipedia.org/wiki/Tar_(file_format)#Key_implementations">star</a>" integrated as the main replacement for all archivers. &nbsp;That didn't take place, because he couldn't find reviewers. &nbsp;And after several negative interactions with him, I withdrew my offer to sponsor his work personally, as I found the process of trying to do so unbelievably painful. &nbsp;(There was an extremely long telephone call with Joerg that sticks in my memory.) &nbsp;I suggested he find someone else willing to code review and sponsor his work for integration into illumos. &nbsp;To date, that has not happened.<br /><br />Somewhere during that time, Jörg indicated that he would not offer any other code up for integration until star was integrated. &nbsp;Basically, he took his toys and went home. &nbsp;Except he just took his toys, but forgot to go home, as he's still trying to create noise on our developer mailing lists.<br /><br />There was another negative experience we had, mirroring today's thread, where Joerg's response to a tool I wrote (an open replacement for "od") was non-constructive criticism. &nbsp;(In fact, his response was "it's broken, why don't you use this thing I haven't finished writing yet". &nbsp;(He modified his "hexdump" utility to behave like od, apparently in <i>response</i>&nbsp;to my effort instead of simply offering helpful review feedback.)<br /><br />This is typical of Jörg -- the only "right" answer as far as he is concerned is to accept his code, even if it isn't written yet or is buggy!<br /><br />Jörg is what is known as a <a href="http://google%20i/O%202008%20-%20Open%20Source%20Projects%20and%20Poisonous%20People%20...">poisonous personality</a>. &nbsp;At least in every context that I've seen him operate. Which is why usually I try to just ignore him, and hope he'll go away; yet like certain garden pests he just keeps coming back. &nbsp;He's even been <a href="http://slashdot.org/story/06/09/04/1335226/debian-kicks-jrg-schilling">kicked out</a> of another prominent open source community.<br /><br />He's also said made some incorrect and defamatory statements about both Nexenta and illumos at a prominent academic conference in Germany. &nbsp;(I can't find the link right now, I'll update if I find it.)<br /><br />So, where in his post today he asks Gordon if he's willing to change the rules for integration, I have this in reply:<br /><br /><blockquote class="tr_bq"><i>Are you willing to change this?&nbsp;</i></blockquote><blockquote class="tr_bq">Gordon isn't empowered to. &nbsp;Neither, for that matter, am I. &nbsp;The rules that have been established for collaboration here are by common consent of the major contributors, and no single individual can change them. &nbsp;Notably, those were the rules in force in Summer 2010, and you were the one that wanted special treatment. &nbsp; Those rules have served this community well for the past several years, and there has been no movement to change them.<br /><br /><i>I am interested in setting up a phalanx of OpenSolaris activities because this<br />is the only way we have a chance to continue with OpenSolaris development but<br />this is hard as long as Illumos is not willing to play nicely.</i></blockquote><br /><blockquote class="tr_bq">OpenSolaris is dead. &nbsp;The entire illumos community has moved on. &nbsp;You have not, but then I have long since stopped considering you a part of the illumos community.<br />Especially given your repeated attacks against both illumos and numerous of its contributors -- even fairly early on you made a number of defamatory and incorrect statements about the nature of both illumos and its contributors in technical presentation before the German academic community. &nbsp;This was not the behavior of someone who is a constructive contributor.<br />To be completely honest, I think I'm not alone in wishing that you'd come to the same conclusion: that is that you are not part of this community.<br /><br /><i>I recently tried to build a bridge by propising that Illumos should implement<br />the proposals from Summer 2010 to regain credibility. Unfortuntely there was no<br />reaction.</i>&nbsp;</blockquote><blockquote class="tr_bq">That should speak volumes all by itself.&nbsp;</blockquote><div class="p3">As someone else in another open source community said,&nbsp;<a href="https://www.google.com/url?sa=t&amp;rct=j&amp;q=&amp;esrc=s&amp;source=web&amp;cd=11&amp;ved=0CGAQFjAK&amp;url=http%3A%2F%2Flists.debian.org%2Fdebian-devel%2F2004%2F10%2Fmsg00487.html&amp;ei=usIfUtyGNuKZjAKr04G4DA&amp;usg=AFQjCNHOEtZf4_iBmGJyhvP2WzRe7OgMnQ&amp;bvm=bv.51495398,d.cGE">Jorg Schilling is damage; the community should route around him.</a></div></div></content><link rel='replies' type='application/atom+xml' href='http://garrett.damore.org/feeds/5179295673144657187/comments/default' title='Post Comments'/><link rel='replies' type='text/html' href='http://www.blogger.com/comment.g?blogID=7528831701633643336&postID=5179295673144657187' title='1 Comments'/><link rel='edit' type='application/atom+xml' href='http://www.blogger.com/feeds/7528831701633643336/posts/default/5179295673144657187'/><link rel='self' type='application/atom+xml' href='http://www.blogger.com/feeds/7528831701633643336/posts/default/5179295673144657187'/><link rel='alternate' type='text/html' href='http://garrett.damore.org/2013/08/responding-to-trolls.html' title='Responding to Trolls'/><author><name>Garrett D'Amore</name><uri>https://plus.google.com/114484106466928611830</uri><email>noreply@blogger.com</email><gd:image rel='http://schemas.google.com/g/2005#thumbnail' width='32' height='32' src='//lh3.googleusercontent.com/-3UzpztUh9YI/AAAAAAAAAAI/AAAAAAAADRI/7gIavrAWW5k/s512-c/photo.jpg'/></author><thr:total>1</thr:total></entry><entry><id>tag:blogger.com,1999:blog-7528831701633643336.post-5325877764177684187</id><published>2013-08-27T09:33:00.001-07:00</published><updated>2013-08-27T09:33:36.916-07:00</updated><title type='text'>An important milestone</title><content type='html'><div dir="ltr" style="text-align: left;" trbidi="on">Yesterday, with very little fanfare, <a href="http://www.illumos.org/">illumos</a> passed an important milestone.<br /><br />This milestone was the integration of&nbsp;<a href="https://www.illumos.org/issues/195">195 Need replacement for nfs/lockd+klm</a><br /><br />This is work that I originally tasked Gordon Ross and Dan Kruchinin to work while we were colleagues at&nbsp;<a href="http://www.nexenta.com/">Nexenta</a>. &nbsp;Gordon started the work, picking up bits from <a href="http://www.freebsd.org/">FreeBSD</a> as a starting point and gluing it to the illumos entry points. &nbsp;Dan continued with it, and fleshed out a lot of the skeleton that Gordon had started. &nbsp;It was subsequently picked up by the engineers at <a href="http://www.delphix.com/">Delphix</a>, and -- after some important bug fixing work was completed -- was integrated into their product quite some time ago -- reportedly its been stable since December in their product.<br /><br />The reason this is such an important milestone, is two fold:<br /><br />First, this represents a substantial collaborative effort, involving contributions from parties across several organizational boundaries. &nbsp;The level of collaboration achieved here is a win for the greater good of the community.<br /><br />Second, this effort represents the replacement of the last of the truly closed source code in our kernel proper. &nbsp;There are still some closed source drivers (although I will point that we're now seeing more traction with vendors to supply open drivers, with recent open source code contributions coming from places like <a href="http://www.solarflare.com/">SolarFlare</a>, <a href="http://www.lsi.com/">LSI</a>, and <a href="http://www.hp.com/">HP</a>. &nbsp;(HP's contribution -- through illumos partner&nbsp;<a href="http://www.joyent.com/">Joyent</a> -- means that at least one important closed source driver will soon be open -- cpqary3.)<br /><br />I want to personally thank everyone who contributed to make the integration of the new open source NFS lock manager possible. You've done a big service to the community, and we are grateful!</div></content><link rel='replies' type='application/atom+xml' href='http://garrett.damore.org/feeds/5325877764177684187/comments/default' title='Post Comments'/><link rel='replies' type='text/html' href='http://www.blogger.com/comment.g?blogID=7528831701633643336&postID=5325877764177684187' title='0 Comments'/><link rel='edit' type='application/atom+xml' href='http://www.blogger.com/feeds/7528831701633643336/posts/default/5325877764177684187'/><link rel='self' type='application/atom+xml' href='http://www.blogger.com/feeds/7528831701633643336/posts/default/5325877764177684187'/><link rel='alternate' type='text/html' href='http://garrett.damore.org/2013/08/an-important-milestone.html' title='An important milestone'/><author><name>Garrett D'Amore</name><uri>https://plus.google.com/114484106466928611830</uri><email>noreply@blogger.com</email><gd:image rel='http://schemas.google.com/g/2005#thumbnail' width='32' height='32' src='//lh3.googleusercontent.com/-3UzpztUh9YI/AAAAAAAAAAI/AAAAAAAADRI/7gIavrAWW5k/s512-c/photo.jpg'/></author><thr:total>0</thr:total></entry><entry><id>tag:blogger.com,1999:blog-7528831701633643336.post-6365849139750216065</id><published>2013-01-17T20:13:00.002-08:00</published><updated>2013-01-17T20:13:38.630-08:00</updated><title type='text'>ZFS Compression Enhancements in illumos</title><content type='html'><div dir="ltr" style="text-align: left;" trbidi="on">The ZFS code in <a href="http://www.illumos.org/">illumos</a> has gained another differentiator thanks to the hard work of Saso, who integrated <a href="http://wiki.illumos.org/display/illumos/LZ4+Compression+In+ZFS">LZ4 improved compression</a> into our code base.<br /><br />This is a nice achievement, and enhanced compression should be quite useful for most applications of ZFS. &nbsp;If LZJB was always recommended to be turned on (it was by our team at least!), then LZ4 is even more recommended, unless all of your data is totally incompressible. &nbsp;(Most data is highly compressible.)<br /><br />You should check out his wiki post above, which contains a lot more details about the work, including some benchmark data.</div></content><link rel='replies' type='application/atom+xml' href='http://garrett.damore.org/feeds/6365849139750216065/comments/default' title='Post Comments'/><link rel='replies' type='text/html' href='http://www.blogger.com/comment.g?blogID=7528831701633643336&postID=6365849139750216065' title='1 Comments'/><link rel='edit' type='application/atom+xml' href='http://www.blogger.com/feeds/7528831701633643336/posts/default/6365849139750216065'/><link rel='self' type='application/atom+xml' href='http://www.blogger.com/feeds/7528831701633643336/posts/default/6365849139750216065'/><link rel='alternate' type='text/html' href='http://garrett.damore.org/2013/01/zfs-compression-enhancements-in-illumos.html' title='ZFS Compression Enhancements in illumos'/><author><name>Garrett D'Amore</name><uri>https://plus.google.com/114484106466928611830</uri><email>noreply@blogger.com</email><gd:image rel='http://schemas.google.com/g/2005#thumbnail' width='32' height='32' src='//lh3.googleusercontent.com/-3UzpztUh9YI/AAAAAAAAAAI/AAAAAAAADRI/7gIavrAWW5k/s512-c/photo.jpg'/></author><thr:total>1</thr:total></entry><entry><id>tag:blogger.com,1999:blog-7528831701633643336.post-805143750392114476</id><published>2012-10-27T19:18:00.000-07:00</published><updated>2012-10-27T23:25:54.170-07:00</updated><title type='text'>hackathon project: pfiles - postmortem analysis</title><content type='html'><div dir="ltr" style="text-align: left;" trbidi="on">During the first days of October 2012, we had an <a href="http://www.zfsday.org/">illumos day</a>, and a one day illumos hackathon that was very well attended by some of the best and brightest in our community (and I daresay, in <i>any</i>&nbsp;open source community.)<br /><br />The purpose of the hackathon, besides just doing some cool projects, is to give folks a chance to interact with other domain experts, and code, particularly in areas <i>outside</i>&nbsp;their particular area of expertise.<br /><br />This year a number of interesting projects were worked on, and I think some of these are at the point of starting to bear fruit. &nbsp;The project I undertook was the addition of post-mortem analysis support for <b>pfiles</b>(1). &nbsp;That is, making it possible to use pfiles against a <b>core</b>(4) file. &nbsp;Adam Leventhal suggested the project, and provided the initial suggestion on the method to use for doing the work.<br /><br />This is a particularly interesting project, because the information that pfiles reports is located in kernel state (in the uarea) and has not traditionally been available in a core file.<br /><br />To complete this project, I had to work in a few areas that were unfamiliar to me. &nbsp;Especially I had never looked at the innards of ELF files, nor at the process by which a core file is generated. &nbsp;To add the necessary information, I had to create a new type of ELF note, and then add code to generate it to libproc (used by gcore) and elfexec (for kernel driven core dumps). &nbsp;I also had to add support to parse this to libproc (for pfiles), and elfdump. &nbsp;The project turned out to be bigger than anticipated, consisting of almost a thousand lines of code. &nbsp;So it took me a little more than a day to complete it.<br /><br />A <a href="http://cr.illumos.org/~gdamore/pfiles">webrev with the associated changes</a> is presented for your enjoyment. &nbsp;I'd appreciate any review feedback, and especially any further testing.<br /><br />Here's a sample run:<br /><br /><pre></pre><br /><br /><b>garrett@openindiana{250}&gt; cat &lt; /dev/zero &amp;</b><br />[2] 144241<br /><b>garrett@openindiana{251}&gt; pfiles 144241</b><br />144241:<span class="Apple-tab-span" style="white-space: pre;"> </span>cat<br />&nbsp; Current rlimit: 256 file descriptors<br />&nbsp; &nbsp;0: S_IFCHR mode:0666 dev:526,0 ino:35127324 uid:0 gid:3 rdev:67,12<br />&nbsp; &nbsp; &nbsp; O_RDONLY|O_LARGEFILE<br />&nbsp; &nbsp; &nbsp; /devices/pseudo/mm@0:zero<br />&nbsp; &nbsp; &nbsp; offset:72712192<br />&nbsp; &nbsp;1: S_IFCHR mode:0620 dev:527,0 ino:893072809 uid:101 gid:7 rdev:27,2<br />&nbsp; &nbsp; &nbsp; O_RDWR|O_NOCTTY|O_LARGEFILE<br />&nbsp; &nbsp; &nbsp; /dev/pts/2<br />&nbsp; &nbsp; &nbsp; offset:72704245<br />&nbsp; &nbsp;2: S_IFCHR mode:0620 dev:527,0 ino:893072809 uid:101 gid:7 rdev:27,2<br />&nbsp; &nbsp; &nbsp; O_RDWR|O_NOCTTY|O_LARGEFILE<br />&nbsp; &nbsp; &nbsp; /dev/pts/2<br />&nbsp; &nbsp; &nbsp; offset:72704245<br /><b>garrett@openindiana{252}&gt; gcore 144241</b><br />gcore: core.144241 dumped<br /><b>garrett@openindiana{253}&gt; pfiles core.144241&nbsp;</b><br />core 'core.144241' of 144241:<span class="Apple-tab-span" style="white-space: pre;"> </span>cat<br />&nbsp; &nbsp;0: S_IFCHR mode:0666 dev:526,0 ino:35127324 uid:0 gid:3 rdev:67,12<br />&nbsp; &nbsp; &nbsp; O_RDONLY|O_LARGEFILE<br />&nbsp; &nbsp; &nbsp; /devices/pseudo/mm@0:zero<br />&nbsp; &nbsp; &nbsp; offset:195125248<br />&nbsp; &nbsp;1: S_IFCHR mode:0620 dev:527,0 ino:893072809 uid:101 gid:7 rdev:27,2<br />&nbsp; &nbsp; &nbsp; O_RDWR|O_NOCTTY|O_LARGEFILE<br />&nbsp; &nbsp; &nbsp; /dev/pts/2<br />&nbsp; &nbsp; &nbsp; offset:161882375<br />&nbsp; &nbsp;2: S_IFCHR mode:0620 dev:527,0 ino:893072809 uid:101 gid:7 rdev:27,2<br />&nbsp; &nbsp; &nbsp; O_RDWR|O_NOCTTY|O_LARGEFILE<br />&nbsp; &nbsp; &nbsp; /dev/pts/2<br />&nbsp; &nbsp; &nbsp; offset:161882375<br /><b>garrett@openindiana{254}&gt; kill -11 144241</b><br /><b>garrett@openindiana{255}&gt; pfiles core</b><br />core 'core' of 144241:<span class="Apple-tab-span" style="white-space: pre;"> </span>cat<br />&nbsp; &nbsp;0: S_IFCHR mode:0666 dev:526,0 ino:35127324 uid:0 gid:3 rdev:67,12<br />&nbsp; &nbsp; &nbsp; O_RDONLY|O_LARGEFILE<br />&nbsp; &nbsp; &nbsp; /devices/pseudo/mm@0:zero<br />&nbsp; &nbsp; &nbsp; offset:419414016<br />&nbsp; &nbsp;1: S_IFCHR mode:0620 dev:527,0 ino:893072809 uid:101 gid:7 rdev:27,2<br />&nbsp; &nbsp; &nbsp; O_RDWR|O_NOCTTY|O_LARGEFILE<br />&nbsp; &nbsp; &nbsp; /dev/pts/2<br />&nbsp; &nbsp; &nbsp; offset:296960430<br />&nbsp; &nbsp;2: S_IFCHR mode:0620 dev:527,0 ino:893072809 uid:101 gid:7 rdev:27,2<br />&nbsp; &nbsp; &nbsp; O_RDWR|O_NOCTTY|O_LARGEFILE<br />&nbsp; &nbsp; &nbsp; /dev/pts/2<br />&nbsp; &nbsp; &nbsp; offset:296960430<br />[2] &nbsp;- Segmentation fault &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp;cat &lt; /dev/zero (core dumped)<br /><br /><b>garrett@openindiana{256}&gt; elfdump core</b><br /><div>...</div><br /><br />&nbsp; entry [10]<br />&nbsp; &nbsp; namesz: 0x5<br />&nbsp; &nbsp; descsz: 0x440<br />&nbsp; &nbsp; type: &nbsp; [ NT_FDINFO ]<br />&nbsp; &nbsp; name:<br />&nbsp; &nbsp; &nbsp; &nbsp; CORE\0<br />&nbsp; &nbsp; desc: (prfdinfo_t)<br />&nbsp; &nbsp; &nbsp; &nbsp; pr_fd: &nbsp; &nbsp; &nbsp; &nbsp;0<br />&nbsp; &nbsp; &nbsp; &nbsp; pr_mode: &nbsp; &nbsp; &nbsp;[ S_IFCHR S_IRUSR S_IWUSR S_IRGRP S_IWGRP S_IROTH S_IWOTH ]<br />&nbsp; &nbsp; &nbsp; &nbsp; pr_uid: &nbsp; &nbsp; &nbsp; 0 &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp;pr_gid: &nbsp; &nbsp; &nbsp;3<br />&nbsp; &nbsp; &nbsp; &nbsp; pr_major: &nbsp; &nbsp; 526 &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp;pr_minor: &nbsp; &nbsp;0<br />&nbsp; &nbsp; &nbsp; &nbsp; pr_rmajor: &nbsp; &nbsp;67 &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; pr_rminor: &nbsp; 12<br />&nbsp; &nbsp; &nbsp; &nbsp; pr_ino: &nbsp; &nbsp; &nbsp; 35127324<br />&nbsp; &nbsp; &nbsp; &nbsp; pr_size: &nbsp; &nbsp; &nbsp;0 &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp;pr_offset: &nbsp; 419414016<br />&nbsp; &nbsp; &nbsp; &nbsp; pr_fileflags: [ O_RDONLY O_LARGEFILE ]<br />&nbsp; &nbsp; &nbsp; &nbsp; pr_fdflags: &nbsp; 0<br />&nbsp; &nbsp; &nbsp; &nbsp; pr_path: &nbsp; &nbsp; &nbsp;/devices/pseudo/mm@0:zero<br /><br />&nbsp; entry [11]<br />&nbsp; &nbsp; namesz: 0x5<br />&nbsp; &nbsp; descsz: 0x440<br />&nbsp; &nbsp; type: &nbsp; [ NT_FDINFO ]<br />&nbsp; &nbsp; name:<br />&nbsp; &nbsp; &nbsp; &nbsp; CORE\0<br />&nbsp; &nbsp; desc: (prfdinfo_t)<br />&nbsp; &nbsp; &nbsp; &nbsp; pr_fd: &nbsp; &nbsp; &nbsp; &nbsp;1<br />&nbsp; &nbsp; &nbsp; &nbsp; pr_mode: &nbsp; &nbsp; &nbsp;[ S_IFCHR S_IRUSR S_IWUSR S_IWGRP ]<br />&nbsp; &nbsp; &nbsp; &nbsp; pr_uid: &nbsp; &nbsp; &nbsp; 101 &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp;pr_gid: &nbsp; &nbsp; &nbsp;7<br />&nbsp; &nbsp; &nbsp; &nbsp; pr_major: &nbsp; &nbsp; 527 &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp;pr_minor: &nbsp; &nbsp;0<br />&nbsp; &nbsp; &nbsp; &nbsp; pr_rmajor: &nbsp; &nbsp;27 &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; pr_rminor: &nbsp; 2<br />&nbsp; &nbsp; &nbsp; &nbsp; pr_ino: &nbsp; &nbsp; &nbsp; 893072809<br />&nbsp; &nbsp; &nbsp; &nbsp; pr_size: &nbsp; &nbsp; &nbsp;0 &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp;pr_offset: &nbsp; 296960430<br />&nbsp; &nbsp; &nbsp; &nbsp; pr_fileflags: [ O_RDONLY O_NOCTTY O_LARGEFILE ]<br />&nbsp; &nbsp; &nbsp; &nbsp; pr_fdflags: &nbsp; 0<br />&nbsp; &nbsp; &nbsp; &nbsp; pr_path: &nbsp; &nbsp; &nbsp;/dev/pts/2<br /><br />&nbsp; entry [12]<br />&nbsp; &nbsp; namesz: 0x5<br />&nbsp; &nbsp; descsz: 0x440<br />&nbsp; &nbsp; type: &nbsp; [ NT_FDINFO ]<br />&nbsp; &nbsp; name:<br />&nbsp; &nbsp; &nbsp; &nbsp; CORE\0<br />&nbsp; &nbsp; desc: (prfdinfo_t)<br />&nbsp; &nbsp; &nbsp; &nbsp; pr_fd: &nbsp; &nbsp; &nbsp; &nbsp;2<br />&nbsp; &nbsp; &nbsp; &nbsp; pr_mode: &nbsp; &nbsp; &nbsp;[ S_IFCHR S_IRUSR S_IWUSR S_IWGRP ]<br />&nbsp; &nbsp; &nbsp; &nbsp; pr_uid: &nbsp; &nbsp; &nbsp; 101 &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp;pr_gid: &nbsp; &nbsp; &nbsp;7<br />&nbsp; &nbsp; &nbsp; &nbsp; pr_major: &nbsp; &nbsp; 527 &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp;pr_minor: &nbsp; &nbsp;0<br />&nbsp; &nbsp; &nbsp; &nbsp; pr_rmajor: &nbsp; &nbsp;27 &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; pr_rminor: &nbsp; 2<br />&nbsp; &nbsp; &nbsp; &nbsp; pr_ino: &nbsp; &nbsp; &nbsp; 893072809<br />&nbsp; &nbsp; &nbsp; &nbsp; pr_size: &nbsp; &nbsp; &nbsp;0 &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp;pr_offset: &nbsp; 296960430<br />&nbsp; &nbsp; &nbsp; &nbsp; pr_fileflags: [ O_RDONLY O_NOCTTY O_LARGEFILE ]<br />&nbsp; &nbsp; &nbsp; &nbsp; pr_fdflags: &nbsp; 0<br />&nbsp; &nbsp; &nbsp; &nbsp; pr_path: &nbsp; &nbsp; &nbsp;/dev/pts/2<br />...<br /><br /><br /></div></content><link rel='replies' type='application/atom+xml' href='http://garrett.damore.org/feeds/805143750392114476/comments/default' title='Post Comments'/><link rel='replies' type='text/html' href='http://www.blogger.com/comment.g?blogID=7528831701633643336&postID=805143750392114476' title='0 Comments'/><link rel='edit' type='application/atom+xml' href='http://www.blogger.com/feeds/7528831701633643336/posts/default/805143750392114476'/><link rel='self' type='application/atom+xml' href='http://www.blogger.com/feeds/7528831701633643336/posts/default/805143750392114476'/><link rel='alternate' type='text/html' href='http://garrett.damore.org/2012/10/hackathon-project-pfiles-postmortem.html' title='hackathon project: pfiles - postmortem analysis'/><author><name>Garrett D'Amore</name><uri>https://plus.google.com/114484106466928611830</uri><email>noreply@blogger.com</email><gd:image rel='http://schemas.google.com/g/2005#thumbnail' width='32' height='32' src='//lh3.googleusercontent.com/-3UzpztUh9YI/AAAAAAAAAAI/AAAAAAAADRI/7gIavrAWW5k/s512-c/photo.jpg'/></author><thr:total>0</thr:total></entry></feed>

If you would like to create a banner that links to this page (i.e. this validation result), do the following:

Download the "valid Atom 1.0" banner.
Upload the image to your own server. (This step is important. Please do not link directly to the image on this server.)
Add this HTML to your page (change the image src attribute if necessary):

<a href="http://feedvalidator.org/check.cgi?url=http%3A//gdamore.blogspot.com/atom.xml"><img src="valid-atom.png" alt="[Valid Atom 1.0]" title="Validate my Atom 1.0 feed" /></a>

If you would like to create a text link instead, here is the URL you can use:

http://feedvalidator.org/check.cgi?url=http%3A//gdamore.blogspot.com/atom.xml

Home · About · News · Docs · Terms