<p>Firstly a big thanks to this subreddit, it has helped me a lot, I'm looking for some project ideas to improve my skills in Go and want to do something to do with Linux systems but i cant think of any ideas.
some background on my experience in Go:
Ive completed pluralsight course called Go Fundamentals
by Nigel Poulton
I've written Go to use loadbalancer API and an Akamai API but want something more to do with systems so im open to ideas. Thank you in advance </p>
<p>Edit: spelling</p>
<hr/>**评论：**<br/><br/>fazalmajid: <pre><p>Reimplement GNU Parallel in Go to get rid of the Perl dependency.</p></pre>Mattho: <pre><p>Is the whole program one 10k LOC perl file?</p></pre>GodsBoss: <pre><p>It's Perl, so it is a ~340 KB one-liner.</p></pre>dmke: <pre><p><a href="https://git.savannah.gnu.org/cgit/parallel.git/tree/src/parallel">11k</a>.</p></pre>Mattho: <pre><p>Found an old version I guess.</p></pre>fazalmajid: <pre><p>Pretty much, which is why I'd love a Go replacement.</p></pre>Killing_Spark: <pre><p>I just looked at the summary and thought 'Well that doesnt sound too hard'. Then i open the tutorial to see some more features and see 'saving to an sql base'... What the actual fuck</p></pre>fazalmajid: <pre><p>I wasn't aware of this functionality and I can see the use cases, but yes, the UNIX philosophy of simple, self-contained tools (like xargs) does not encourage that.</p></pre>Killing_Spark: <pre><p>Looks like this project got way out of its scope. But you are right a clone of the core functionality in go would be pretty cool :) </p></pre>fazalmajid: <pre><p>It’s complex to use but what I like over GNU xargs is the progress meter and ETA functionality.</p></pre>Mittalmailbox: <pre><p>Are there any other popular tools written in Perl? I would also like to work on porting it to Go.</p></pre>fazalmajid: <pre><p>Quite a few, I'm sure, but I generally avoid them, just like I avoid JVM or Ruby-based packages.</p>
<p>I'd get rid of Perl altogether but a number of packages require it as part of their build system, e.g. texingo, OpenSSL, rsync and I am sure many others.</p></pre>gunnihinn: <pre><p>Is there a reason to do that beyond that it's written in Perl?</p></pre>croninsiglos: <pre><p>Rewrite Chef in Go from the ground up and I'll be your new best friend. </p></pre>lespritd: <pre><p>Go doesn't support AIX[0][1].</p>
<p>Word on the street is that they picked Rust over Go to
use internally.</p>
<p>[0] <a href="https://docs.chef.io/platforms.html">https://docs.chef.io/platforms.html</a></p>
<p>[1] <a href="https://github.com/golang/go/wiki/MinimumRequirements">https://github.com/golang/go/wiki/MinimumRequirements</a></p></pre>TevinJeffrey: <pre><p>OP, add support of AIX to the Go runtime.</p></pre>eikenberry: <pre><blockquote>
<p>Go doesn't support AIX[0][1].</p>
</blockquote>
<p>I believe it does using the GCC backend.</p></pre>croninsiglos: <pre><p>They picked Rust for Chef Habitat because Adam Jacob doesn't like code readability. ha</p></pre>demizer: <pre><p>Why would you want chef rewritten in Go?</p></pre>croninsiglos: <pre><p>Because Ruby is dirt slow. It's nice to look at, don't get me wrong.</p></pre>absdevops: <pre><p>You looked into mgmt? <a href="https://github.com/purpleidea/mgmt" rel="nofollow">https://github.com/purpleidea/mgmt</a></p></pre>croninsiglos: <pre><p>Cool!</p></pre>koffiezet: <pre><p>While the mentioned mgmt is cool, it’s also pretty experimental, and didn’t support many things last time i checked.</p>
<p>And one of the powers of chef is that it actually uses Ruby code as DSL. Implementing that in Go would be pretty absurd :-)</p></pre>croninsiglos: <pre><p>At this point I think even Go parsing the Chef cookbooks implemented in Ruby would be faster than the typical chef client which is also based in Ruby. </p>
<p>It's painfully slow and definitely doesn't take advantage of modern multi-core processors. </p></pre>koffiezet: <pre><p>The problem is that chef cookbooks require the implementation of a full Ruby stack, since there is pretty much no limitation on what anyone can use. I know I did some pretty nifty stuff in those... Sure you could write simple straight-forward parsing and re-implementing the basic resources hard-coded in Go, but the reality is that every single resource out-there is implemented in Ruby, both third party and internal-ones, and there are a lot of them.</p>
<p>I am far from a Ruby fan for multiple reasons, but the more recent runtime versions have seen some respectable performance improvements, which are already written in C++ afaik. There is not a single indication that a re-implementation in Go would be faster than that. Ruby's - and Chef's - slowness is due to it's flexibility and complexity.</p></pre>BraveNewCurrency: <pre><p>Don't do this.</p>
<p>All config management systems have the same fatal flaw: The code in your config system does not uniquely specify a box state. For example, if you say "install apache", then delete that line from Chef, apache will be installed on some boxes (the existing ones), but not on others (any new boxes you boot up). Problems like this can bite you months or years down the road. (I've been bitten by a dozen variants. One time I changed something that (indirectly) removed an nginx config file. Weeks later, we deleted the DNS entry that was in that config file. A few days later, a simple nginx restart failed -- because that stray file was still referencing that DNS name. Arrrg!) Plus not every chef change can be fixed by "rolling back" to the previous Chef commit.</p>
<p>(Don't get me wrong, Chef is better than nothing. But it's going to bite you eventually.)</p>
<p>There is a simple way to fix this: Always start fresh. But if you are going to do that, then Chef is overkill. The old unix tools (adduser, apt-get install, echo 'addme' > config_file) work just fine if you don't need to make them idempotent. You can replace Chef with a Dockerfile, and it will be much more readable, and in less danger of breaking.</p></pre>absdevops: <pre><p>Hey mate, maybe not as low level as you'd like - but I've been playing around with Go Lambdas - they're real easy to get started with. It'd be nice to start a community of Go-Lambda contributions!</p></pre>yungchappo: <pre><p>Thanks mate I’ll definitely have a go at this, sounds very interesting to me</p></pre>: <pre><p>[deleted]</p></pre>driusan: <pre><p>That's more complicated than it sounds, but if you want to learn the basics of writing a window manager in Go my <a href="https://github.com/driusan/dewm/" rel="nofollow">dewm</a> wm is written using a literate programming style with Go as the underlying coding language and is intended to be educational. (You can also start with wingo or taowm if you prefer to just read source code. Either way, BurntSushi's x protocol bindings written in Go are invaluable.)</p></pre>trusch42: <pre><p>Write an OCI storage layer for rkt!</p></pre>metamatic: <pre><p>I'd like a FLAC metadata library, with a command line client.</p></pre>Mattho: <pre><p>Equivalent to <code>python -m SimpleHTTPServer</code>.</p>
<p>edit: or something else I guess <a href="https://github.com/itang/gohttp" rel="nofollow">https://github.com/itang/gohttp</a></p></pre>jerf: <pre><p>There's probably at least 50 of those on github already, if you want one. I've even got one myself, though at least I present it as "a non-trivial sample project" rather than something you'd necessarily use.</p></pre>Pika-Storm: <pre><p>Do you think a "simpleHTTPSserver" is similarly unimpressive? I've been using something like that but hadn't really thought about putting it on GitHub.</p></pre>jerf: <pre><p>Well, "unimpressive" isn't necessarily the right work per se, but "very well occupied space" is true. You are welcome to put it up on GitHub, because you can do as you please, just don't expect it to start racking up dozens of stars and fawning blog posts. But there's plenty of repos on GitHub up there just for the user's convenience.</p></pre>
