tag:blogger.com,1999:blog-35754211688168147862024-03-12T16:18:08.349-07:00Coder's LogViews and journeys of a hopeless programmer, named Zeeshan Ali.zeenixhttp://www.blogger.com/profile/04142631863736897222noreply@blogger.comBlogger210125tag:blogger.com,1999:blog-3575421168816814786.post-45485332682016623512021-02-14T04:40:00.003-08:002021-02-21T09:38:36.310-08:00zbus and Implementing Async Rust API<link href="https://cdnjs.cloudflare.com/ajax/libs/highlight.js/10.5.0/styles/solarized-dark.min.css" rel="stylesheet"></link>
<script src="https://cdnjs.cloudflare.com/ajax/libs/highlight.js/10.5.0/highlight.min.js"></script>
<script src="https://cdnjs.cloudflare.com/ajax/libs/highlight.js/10.5.0/languages/rust.min.js"></script>
<script type="text/javascript">
hljs.initHighlightingOnLoad();
</script>
<h1 id="zbus">zbus</h1>
<p>As many of the readers already know, for the past (almost) 2 years, I've been developing a
Rust-crate for D-Bus, called <a href="https://gitlab.freedesktop.org/dbus/zbus">zbus</a>. With this being my
first big Rust project to start from scratch done almost entirely in my spare time, the progress was
rather slow for many months. My perfectionism didn't help much with the progress either but also the
fact that implementing a <a href="https://serde.rs/">Serde</a>
<a href="https://docs.rs/zvariant/latest/zvariant/index.html">API</a> for the D-Bus format was quite
challenging. Then along came my old friend and ex-colleague, Marc-André Lureau who sped up the
progress 10 times and soon after we had the 1.0 release of zbus.</p>
<p>While my original plan (perfectionism again) was for the API to be primarily async, with the
synchronous API mostly just a wrapper around it, it was Marc-Andre who ended up doing most of the
work and coming up with nice high-level API and his use case was primarily synchronous so we
decided to go with synchronous API first. I still believe that was the right thing to do, since
neither of us were familiar with async programming in Rust and going with the original plan would
have meant the first release getting delayed by at least another half an year.</p>
<p>This may sound very disappointing to readers who come from glib programming background but a purely
synchronous blocking API in a Rust app is not at all as bad it would be in a glib+C (or even Vala)
app. There is a reason why Rust is famous for its fearless concurrency.</p>
<h1 id="asynchronousapi">Asynchronous API</h1>
<p>However, a first class asynchronous API is still a must if we're serious about our goal of making
D-Bus super easy. This is especially important for UI apps, that should have an easy way to
communicate over D-Bus w/o blocking the UI and having to spawn threads and setting up communication
channels between these threads etc.</p>
<p>So for the past many weeks, I've been working on adding async versions of our synchronous types,
starting from the low-level
<a href="https://docs.rs/zbus/2.0.0-beta/zbus/azync/connection/struct.Connection.html">Connection</a>, followed
by the <a href="https://gitlab.freedesktop.org/dbus/zbus/-/merge_requests/241">client-side proxy</a> and
hopefully soon the service-side as well. It's been a very interesting challenge to say the least.
Coming from Vala background, Rust's async/await syntax felt very familiar to me.</p>
<p>One of the great thing is that I was able to achieve one of my original goals and turned our
existing types into thin blocking wrappers around their new async siblings, hence avoiding code
duplication. Moreover, thanks to the <a href="https://docs.rs/futures">futures</a> and
<a href="https://github.com/smol-rs/">smol-rs</a> crates, so far I've also been able to keep zbus agnostic of
<a href="https://rust-lang.github.io/async-book/08_ecosystem/00_chapter.html#popular-async-runtimes">specific async runtimes</a>
as well.</p>
<table align="center" cellpadding="0" cellspacing="0" class="tr-caption-container" style="margin-left: auto; margin-right: auto;"><tbody><tr><td style="text-align: center;"><a href="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEjcEh2GMwyZcLFG4iboR4D-0o_hdvy_QOOreMHSFJtmhbrYZdCYJ89mTAWLzv0GqcLoNDNqrGMYeXVXlux456KXzDf9WemgWYlTvU1W94_0JeOEFTGErOBM4DsIMf8I83-T50_GqpBSi-W0/s4032/20210201_133942.jpg" style="margin-left: auto; margin-right: auto;"><img border="0" data-original-height="1960" data-original-width="4032" height="195" src="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEjcEh2GMwyZcLFG4iboR4D-0o_hdvy_QOOreMHSFJtmhbrYZdCYJ89mTAWLzv0GqcLoNDNqrGMYeXVXlux456KXzDf9WemgWYlTvU1W94_0JeOEFTGErOBM4DsIMf8I83-T50_GqpBSi-W0/w400-h195/20210201_133942.jpg" width="400" /></a></td></tr><tr><td class="tr-caption" style="text-align: center;">Esther loves async Rust code</td><td class="tr-caption" style="text-align: center;"><br /></td></tr></tbody></table><br />
<h1 id="painpoints">Pain Points</h1>
<p>Having said that, while Rust's async/await is a lot of joy from a user's POV, implementing useful
async API on top isn't a walk in the park. Here are some of the hurdles I bumped into:</p>
<h2 id="pinning">Pinning</h2>
<p>If you're going to be doing any async programming in Rust, you'll sooner or later have to learn
<a href="https://doc.rust-lang.org/std/pin/index.html" target="_blank">what this is</a>. It's not at all a hard concept but what I found especially challenging is the
difference between the <code>Unpin</code> and <code>!Unpin</code> types. i-e which one is which? I also kept forgetting
why I need to pin a future before awaiting on it.</p>
<h2 id="implementingfuturesbasedonasyncapi">Implementing Futures based on async API</h2>
<p>This is something I found very surprising. I would have thought that would be easy but turns out
it's not. The reason is the argument you receive in the <code>Future</code>'s required <code>poll</code> method:</p>
<pre><code class="hljs rust language-rust"><span class="hljs-function"><span class="hljs-keyword">fn</span> <span class="hljs-title">poll</span></span>(<span class="hljs-keyword">self</span>: Pin<&<span class="hljs-keyword">mut</span> <span class="hljs-keyword">Self</span>>, cx: &<span class="hljs-keyword">mut</span> Context<<span class="hljs-symbol">'_</span>>) -> Poll<Self::Output>;
</code></pre>
<p>Notice, how the first argument here is <code>Pin<&mut Self></code> and not the usual <code>self</code>, <code>&self</code> or <code>&mut
self</code>. This is very much justified since we can't have things moving around while a future is not
complete (for which the poll method will potentially be called many times). However, what an async
function or block gives you is an abstract type that implements <code>Future</code> so you can't just do
something like:</p>
<pre><code class="hljs rust language-rust"><span class="hljs-class"><span class="hljs-keyword">struct</span> <span class="hljs-title">MyFuture</span></span>;
<span class="hljs-keyword">impl</span> Future <span class="hljs-keyword">for</span> MyFuture {
<span class="hljs-class"><span class="hljs-keyword">type</span> <span class="hljs-title">Output</span></span> = <span class="hljs-built_in">String</span>;
<span class="hljs-function"><span class="hljs-keyword">fn</span> <span class="hljs-title">poll</span></span>(<span class="hljs-keyword">self</span>: Pin<&<span class="hljs-keyword">mut</span> <span class="hljs-keyword">Self</span>>, cx: &<span class="hljs-keyword">mut</span> Context<<span class="hljs-symbol">'_</span>>) -> Poll<Self::Output> {
<span class="hljs-keyword">match</span> some_async_method_returning_string().poll(cx) {
Poll::Ready(s) => Poll::Ready(<span class="hljs-built_in">format!</span>(<span class="hljs-string">"string: {}"</span>, s)),
Poll::Pending => Poll::Pending,
}
}
}
</code></pre>
<p>You'll get:</p>
<pre><code class="hljs">error[E0599]: no <span class="hljs-function"><span class="hljs-keyword">method</span> <span class="hljs-title">named</span> `<span class="hljs-title">poll</span>` <span class="hljs-title">found</span> <span class="hljs-title">for</span> <span class="hljs-title">opaque</span> <span class="hljs-title">type</span> `<span class="hljs-title">impl</span> <span class="hljs-title">Future</span>` <span class="hljs-title">in</span> <span class="hljs-title">the</span> <span class="hljs-title">current</span> <span class="hljs-title">scope</span>
--> <span class="hljs-title">src</span>/<span class="hljs-title">lib</span>.<span class="hljs-title">rs</span>:</span><span class="hljs-number">13</span>:<span class="hljs-number">52</span>
|
<span class="hljs-number">13</span> | match some_async_method_returning_string().poll(cx) <span class="hljs-comment">{
| ^^^^ method not found in `impl Future`
</span></code></pre>
<p>While I still don't know how to turn an async call into a <code>Pin<&mut T></code>, I was informed about how
<code>futures</code> crate provides enough API for me not having to do that, e.g
<a href="https://docs.rs/futures/0.3.12/futures/future/trait.FutureExt.html#method.map"><code>FutureExt::map</code></a>.
There is also API to convert futures into streams and vice versa. But I had to ask around to figure
that out and it wasn't very obvious to me.</p>
<h2 id="asyncclosures">Async closures</h2>
<p>Firstly, there are no async closures in Rust yet and from what I hear it'll be a long time before
they'll be available in stable Rust. In the meantime, a common workaround is for closures to return
a <code>Future</code>:</p>
<pre><code class="hljs rust language-rust"><span class="hljs-keyword">async</span> <span class="hljs-function"><span class="hljs-keyword">fn</span> <span class="hljs-title">call_async_cb</span></span><F, Fut>(func: F) -> <span class="hljs-built_in">String</span>
<span class="hljs-keyword">where</span>
F: <span class="hljs-built_in">Fn</span>() -> Fut,
Fut: Future<Output = <span class="hljs-built_in">String</span>>,
{
func().<span class="hljs-keyword">await</span>
}
<span class="hljs-keyword">async</span> <span class="hljs-function"><span class="hljs-keyword">fn</span> <span class="hljs-title">pass_async_cb</span></span>() {
<span class="hljs-keyword">let</span> s = call_async_cb(||
<span class="hljs-keyword">async</span> {
some_async_method_returning_string().<span class="hljs-keyword">await</span>
}
).<span class="hljs-keyword">await</span>;
<span class="hljs-built_in">println!</span>(<span class="hljs-string">"{}"</span>, s);
}
</code></pre>
<p>As you can see, for simple cases like in the sample code above, the code isn't very different from
how it would look like if async closure were a thing. But let's take a <b>slightly</b> more complicated
example, in the sense that the callback takes a reference as an argument:</p>
<pre><code class="hljs rust language-rust"><span class="hljs-keyword">async</span> <span class="hljs-function"><span class="hljs-keyword">fn</span> <span class="hljs-title">call_async_cb</span></span><F, Fut>(func: F) -> <span class="hljs-built_in">String</span>
<span class="hljs-keyword">where</span>
F: <span class="hljs-built_in">Fn</span>(&<span class="hljs-built_in">str</span>) -> Fut,
Fut: Future<Output = <span class="hljs-built_in">String</span>>,
{
<span class="hljs-keyword">let</span> w = <span class="hljs-string">"world"</span>.to_string();
func(&w).<span class="hljs-keyword">await</span>
}
<span class="hljs-keyword">async</span> <span class="hljs-function"><span class="hljs-keyword">fn</span> <span class="hljs-title">pass_async_cb</span></span>() {
<span class="hljs-keyword">let</span> s = call_async_cb(|w|
<span class="hljs-comment">// Also notice the `move` here. W/o it we get another error from the compiler.</span>
<span class="hljs-keyword">async</span> <span class="hljs-keyword">move</span> {
<span class="hljs-keyword">let</span> s = some_async_method_returning_string().<span class="hljs-keyword">await</span>;
<span class="hljs-built_in">format!</span>(<span class="hljs-string">"{} {}"</span>, s, w)
}
).<span class="hljs-keyword">await</span>;
<span class="hljs-built_in">println!</span>(<span class="hljs-string">"{}"</span>, s);
}
</code></pre>
<p>which will result in:</p>
<pre><code class="hljs">error: lifetime may not live long enough
--> src/main.rs:19:9
|<span class="hljs-string">
18 </span>|<span class="hljs-string"> let s = call_async_cb(</span>|<span class="hljs-string">w</span>|
|<span class="hljs-string"> -- return type of closure `impl Future` contains a lifetime `'2`
</span>|<span class="hljs-string"> </span>|
|<span class="hljs-string"> has type `&'1 str`
19 </span>|<span class="hljs-string"> / async move {
20 </span>|<span class="hljs-string"> </span>|<span class="hljs-string"> let s = some_async_method_returning_string().await;
21 </span>|<span class="hljs-string"> </span>|
22 |<span class="hljs-string"> </span>|<span class="hljs-string"> format!("{} {}", s, w)
23 </span>|<span class="hljs-string"> </span>|<span class="hljs-string"> }
</span>|<span class="hljs-string"> </span>|<span class="hljs-string">_________^ returning this value requires that `'1` must outlive `'2
</span></code></pre>
<p>The solution that I could find for this problem was to <a href="https://gitlab.freedesktop.org/dbus/zbus/-/blob/5543ad4866aa193a85cb0fe1e7d68e8d8d0290e0/zbus/src/azync/proxy.rs#L306">pass only owned data to such
closures</a>.
This solution isn't ideal at all. A signal handler should really not be getting a <code>Message</code> but only
a reference to it. A simple solution here would be to pass <code>Arc<Message></code> instead but that would
require the entire call chain to be converted to use that type instead. We'll likely be doing
exactly that but it would'd have been nice not having to do that.</p>
<h2 id="errorsfromhell">Errors from hell</h2>
<p>At the time of this writing, the async Proxy API in zbus is slightly broken and I only found out
about it after I tried to use it with tokio::select in our company's internal codebase:</p>
<pre><code class="hljs"><span class="hljs-number">98</span> | Ok(tokio<span class="hljs-number">::</span>spawn(async move {
| ^^^^^^^^^^^^ `dyn FnMut(zbus<span class="hljs-number">::</span>Message) -> Pin<Box<dyn futures<span class="hljs-number">::</span>Future<Output = st<span class="hljs-number">d::</span>result<span class="hljs-number">::</span>Result<(), zbus<span class="hljs-number">::</span>Error>> + st<span class="hljs-number">d::</span>marker<span class="hljs-number">::</span>Send>> + st<span class="hljs-number">d::</span>marker<span class="hljs-number">::</span>Send` cannot be shared between threads safely
|
::: /home/zeenix/.cargo/registry/src/github.com-<span class="hljs-number">1</span>ecc6299db9ec823/tokio-<span class="hljs-number">1</span>.<span class="hljs-number">0</span>.<span class="hljs-number">1</span>/src/task/spawn.rs:<span class="hljs-number">128</span>:<span class="hljs-number">21</span>
|
<span class="hljs-number">128</span> | T: Future + Send + 'static,
| ---- required by this bound in `tokio<span class="hljs-number">::</span>spawn`
|
= help: the trait `Sync` is not implemented for `dyn FnMut(zbus<span class="hljs-number">::</span>Message) -> Pin<Box<dyn futures<span class="hljs-number">::</span>Future<Output = st<span class="hljs-number">d::</span>result<span class="hljs-number">::</span>Result<(), zbus<span class="hljs-number">::</span>Error>> + st<span class="hljs-number">d::</span>marker<span class="hljs-number">::</span>Send>> + st<span class="hljs-number">d::</span>marker<span class="hljs-number">::</span>Send`
= note: required because of the requirements on the impl of `Sync` for `st<span class="hljs-number">d::</span>ptr<span class="hljs-number">::</span>Unique<dyn FnMut(zbus<span class="hljs-number">::</span>Message) -> Pin<Box<dyn futures<span class="hljs-number">::</span>Future<Output = st<span class="hljs-number">d::</span>result<span class="hljs-number">::</span>Result<(), zbus<span class="hljs-number">::</span>Error>> + st<span class="hljs-number">d::</span>marker<span class="hljs-number">::</span>Send>> + st<span class="hljs-number">d::</span>marker<span class="hljs-number">::</span>Send>`
= note: required because it appears within the type `Box<dyn FnMut(zbus<span class="hljs-number">::</span>Message) -> Pin<Box<dyn futures<span class="hljs-number">::</span>Future<Output = st<span class="hljs-number">d::</span>result<span class="hljs-number">::</span>Result<(), zbus<span class="hljs-number">::</span>Error>> + st<span class="hljs-number">d::</span>marker<span class="hljs-number">::</span>Send>> + st<span class="hljs-number">d::</span>marker<span class="hljs-number">::</span>Send>`
= note: required because it appears within the type `(&str, Box<dyn FnMut(zbus<span class="hljs-number">::</span>Message) -> Pin<Box<dyn futures<span class="hljs-number">::</span>Future<Output = st<span class="hljs-number">d::</span>result<span class="hljs-number">::</span>Result<(), zbus<span class="hljs-number">::</span>Error>> + st<span class="hljs-number">d::</span>marker<span class="hljs-number">::</span>Send>> + st<span class="hljs-number">d::</span>marker<span class="hljs-number">::</span>Send>)`
= note: required because of the requirements on the impl of `Sync` for `hashbrown<span class="hljs-number">::</span>raw<span class="hljs-number">::</span>RawTable<(&str, Box<dyn FnMut(zbus<span class="hljs-number">::</span>Message) -> Pin<Box<dyn futures<span class="hljs-number">::</span>Future<Output = st<span class="hljs-number">d::</span>result<span class="hljs-number">::</span>Result<(), zbus<span class="hljs-number">::</span>Error>> + st<span class="hljs-number">d::</span>marker<span class="hljs-number">::</span>Send>> + st<span class="hljs-number">d::</span>marker<span class="hljs-number">::</span>Send>)>`
= note: required because it appears within the type `hashbrown<span class="hljs-number">::</span>map<span class="hljs-number">::</span>HashMap<&str, Box<dyn FnMut(zbus<span class="hljs-number">::</span>Message) -> Pin<Box<dyn futures<span class="hljs-number">::</span>Future<Output = st<span class="hljs-number">d::</span>result<span class="hljs-number">::</span>Result<(), zbus<span class="hljs-number">::</span>Error>> + st<span class="hljs-number">d::</span>marker<span class="hljs-number">::</span>Send>> + st<span class="hljs-number">d::</span>marker<span class="hljs-number">::</span>Send>, RandomState>`
= note: required because it appears within the type `HashMap<&str, Box<dyn FnMut(zbus<span class="hljs-number">::</span>Message) -> Pin<Box<dyn futures<span class="hljs-number">::</span>Future<Output = st<span class="hljs-number">d::</span>result<span class="hljs-number">::</span>Result<(), zbus<span class="hljs-number">::</span>Error>> + st<span class="hljs-number">d::</span>marker<span class="hljs-number">::</span>Send>> + st<span class="hljs-number">d::</span>marker<span class="hljs-number">::</span>Send>>`
= note: required because of the requirements on the impl of `Sync` for `async_lock<span class="hljs-number">::</span>mutex<span class="hljs-number">::</span>MutexGuard<'_, HashMap<&str, Box<dyn FnMut(zbus<span class="hljs-number">::</span>Message) -> Pin<Box<dyn futures<span class="hljs-number">::</span>Future<Output = st<span class="hljs-number">d::</span>result<span class="hljs-number">::</span>Result<(), zbus<span class="hljs-number">::</span>Error>> + st<span class="hljs-number">d::</span>marker<span class="hljs-number">::</span>Send>> + st<span class="hljs-number">d::</span>marker<span class="hljs-number">::</span>Send>>>`
= note: required because of the requirements on the impl of `st<span class="hljs-number">d::</span>marker<span class="hljs-number">::</span>Send` for `&async_lock<span class="hljs-number">::</span>mutex<span class="hljs-number">::</span>MutexGuard<'_, HashMap<&str, Box<dyn FnMut(zbus<span class="hljs-number">::</span>Message) -> Pin<Box<dyn futures<span class="hljs-number">::</span>Future<Output = st<span class="hljs-number">d::</span>result<span class="hljs-number">::</span>Result<(), zbus<span class="hljs-number">::</span>Error>> + st<span class="hljs-number">d::</span>marker<span class="hljs-number">::</span>Send>> + st<span class="hljs-number">d::</span>marker<span class="hljs-number">::</span>Send>>>`
***MORE SCARY INFO HERE***
= note: required because it appears within the type `impl futures<span class="hljs-number">::</span>Future`
</code></pre>
<p>It's not even immediately obvious if the issue is lack of <code>Send</code> or <code>Sync</code>. After some hints from
Sebastian Dröge (who btw, has been very helpful during this whole endeavour), it turns out the
culprit is <a href="https://github.com/zeenix/zbus/blob/2.0.0-beta.2-prep/zbus/src/azync/proxy.rs#L370">this
line</a>, where we
gotta store a <code>&HashMap</code> across a .await boundary. Don't worry if you don't get it, I'm not sure I
fully comprehend this either. :)</p>
<p>Most importantly, the fact that the issue is in zbus code but the error is only revealed on trying
to build the using code, makes it very unexpected. It is a bit contrary to the usual experience with
Rust. "If it builds, it works" is not just an empty slogan but in most cases actually (surprisingly)
true.</p>
<h1 id="conclusion">Conclusion</h1>
<p>I still find this experience much more pleasant compared to doing the same in Vala or C (especially
C). You'll not encounter any of these pains in those languages, sure but you'll have a lot more real
problem at runtime to deal with for years that are implications of the problems Rust want you to
confront at build time. But let's not digress.. This is not supposed to be yet another Rust sermon
from yours truly. :)</p>
<p>Can Rust do better here? For sure! That is the hope and the reason for this blog post.</p>zeenixhttp://www.blogger.com/profile/04142631863736897222noreply@blogger.com0tag:blogger.com,1999:blog-3575421168816814786.post-31151110246268505292018-11-22T05:40:00.000-08:002018-11-23T09:30:06.456-08:00GNOME+Rust Hackfest #4<div dir="ltr" style="text-align: left;" trbidi="on">
Last week, I had the pleasure of attending the <a href="https://wiki.gnome.org/Hackfests/Rust2018-2" target="_blank">4th GNOME+Rust hackfest</a> in Thessaloniki, Greece. While other folks were mainly focused on the <a href="https://blog.guillaume-gomez.fr/articles/2018-11-19+GNOME%2BRust+Hackfest+in+Thessaloniki">infrastructure work</a>, with my Rust being extremely rusty as of late, I decided to do something that tests the infra instead. More specifically, I took up on Sebastian's challenge of "Maybe someone should write a gst-inspect replacement in Rust". I am happy to report that by the end of the hackfest, I already have an implementation that covers 30% of the typical usage of gst-inspect. This implementation also comes pre-built with paging by default (which I only recently added to the current gst-inspect) and colored output (<a href="https://gitlab.freedesktop.org/gstreamer/gstreamer/merge_requests/28" target="_blank">MR on existing gst-inspect</a> still pending review).<br />
<br />
I did run into some rather interesting issues though but there was always someone who could help me out. One specific one was on how best to pipe the output in Rust to a pager. This took more than a day and my implementation was mostly very similar to the one I did in C. Then I consulted Alex Crichton, who was able to come up with a much cleaner solution in 5 minutes. Another issue was that I wanted to name the binary 'gst-inspect-1.0' but turned out Cargo currently doesn't allow that. It's not big deal and I went with 'gst-inspect' (which might be a better name anyway to avoid conflict with existing binary) for now but me hitting this issue at the hackfest, resulted in <a href="https://github.com/rust-lang/cargo/issues/1706#issuecomment-439061864" target="_blank">Alex providing instructions</a> on how someone would go about fixing this issue.<br />
<br />
I also found a few things missing in the gstreamer bindings and added those as part of the work.<br />
<br />
I'm still slowly working on adding the feature to show details about plugins and elements but it might take a bit, since I'm pretty swamped with work these days. However, once that feature is in, we've most of gst-inspect usage covered and I can file the merge-request for it.<br />
<br />
If for some reason you want to try it out already, the branch is <a href="https://gitlab.freedesktop.org/zeenix/gstreamer-rs/commits/gst-inspect" target="_blank">here</a>. Oh and here is a screenshot:<br />
<br />
<div class="separator" style="clear: both; text-align: center;">
<a href="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEgOHgrK2gjyDpZnfZi4Per0FxIrUiisigDgQVwYL__DC2v3r94sTqqr2X2b1XaQQTMW7ztcJm3AnzbVYVwQuXN6To4D_nllqdSEmsTQmuTY9jJpk6pIpsFrsLSuKTIZP4wXcu6f3td8ukNr/s1600/Screenshot+from+2018-11-22+14-13-49.png" imageanchor="1" style="margin-left: 1em; margin-right: 1em;"><img border="0" data-original-height="1600" data-original-width="1460" height="320" src="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEgOHgrK2gjyDpZnfZi4Per0FxIrUiisigDgQVwYL__DC2v3r94sTqqr2X2b1XaQQTMW7ztcJm3AnzbVYVwQuXN6To4D_nllqdSEmsTQmuTY9jJpk6pIpsFrsLSuKTIZP4wXcu6f3td8ukNr/s320/Screenshot+from+2018-11-22+14-13-49.png" width="291" /></a></div>
<br />
<br />
Other than that, we had a lot of conversations about Rust, GStreamer and GNOME during the hackfest and such events really motivates folks to do even <a href="https://twitter.com/sdroege_/status/1064484537592414210" target="_blank">more awesome work</a>.<br />
<br />
I would like to thank GNOME foundation for sponsoring my trip and especially the GNOME Travel Committee for helping me out when I had an issue with changing my accommodation. I'd also like to thank Collabora for letting me use my work time for this event.<br />
<br />
<div class="separator" style="clear: both; text-align: center;">
<a href="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEj-pcuR0JXvpmgeQWX6OsE3_ezmfdWZz36_7jUhecVcfio-p-f4tfAFV30gIinxyNjq3B_IR7amBqg8RSKoGTFQyP9HJWm0rDxNfxPN0i1R5jDA0ytYcEJu7xc5bxWwqTkBIx3PjgdeUZwx/s1600/sponsored-badge-shadow.png" imageanchor="1" style="margin-left: 1em; margin-right: 1em;"><img border="0" data-original-height="230" data-original-width="230" src="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEj-pcuR0JXvpmgeQWX6OsE3_ezmfdWZz36_7jUhecVcfio-p-f4tfAFV30gIinxyNjq3B_IR7amBqg8RSKoGTFQyP9HJWm0rDxNfxPN0i1R5jDA0ytYcEJu7xc5bxWwqTkBIx3PjgdeUZwx/s1600/sponsored-badge-shadow.png" /></a></div>
<br /></div>
zeenixhttp://www.blogger.com/profile/04142631863736897222noreply@blogger.com1tag:blogger.com,1999:blog-3575421168816814786.post-69895925455814680412018-10-15T03:59:00.002-07:002018-10-15T04:00:59.093-07:00Geoclue 2.5 & repeating call for help<div dir="ltr" style="text-align: left;" trbidi="on">
Just wanted to announce release <a href="https://gitlab.freedesktop.org/geoclue/geoclue/tags/2.5.0">2.5.0</a> of Geoclue that includes the changes I mentioned in <a href="https://zee-nix.blogspot.com/2018/09/recently-in-geoclue.html">my last blog post</a>.<br />
<br />
Also, while I'm at it, I wanted to highlight the "call for help" at the end of that post by repeating it here again. I apologize of repeating to those who already read it but a friend pointed out that it's likely going to be missed by many folks:<br />
<h4 style="text-align: left;">
The future of Mozilla Location Service</h4>
<div style="text-align: left;">
When Mozilla announced their
location service in late 2013, Geoclue became one of its first users as
it was our only hope for a reliable WiFi-geolocation source. We
couldn't use Google's service as their ToC don't allow it to be used in
an open source project (I recall some clause that it can only be used
with Google Maps and not any other Map software). <a href="https://wiki.mozilla.org/CloudServices/Location">Mozilla Location Service</a> (MLS) was a huge success
in terms of people contributing WiFi data to it. I've been to quite a
few places around Europe and North America in the last few years and I
haven't been to any location, that is not already covered by MLS.</div>
<div style="text-align: left;">
<br /></div>
<div style="text-align: left;">
Mozilla's own interest in this
service was tied to their Firefox OS project. Unfortunately Firefox OS
project was abandoned two years ago and Mozilla lost its interest in MLS
as a result. Mozilla folks are the good guys so they have kept the
service running and users can still contribute data but it's no longer
developed or maintained.</div>
<div style="text-align: left;">
<br /></div>
<div style="text-align: left;">
Since this is a very important
service for all users of geoclue, I feel very uneasy about this
uncertain future of MLS. So consider this a call for help. If your
company relies on MLS (directly or through Geoclue) and you'd want to
secure the future of Open Source geolocation, please do get in touch and
we can discuss how we could possibly achieve that.</div>
</div>
zeenixhttp://www.blogger.com/profile/04142631863736897222noreply@blogger.com0tag:blogger.com,1999:blog-3575421168816814786.post-8137359088317733602018-09-23T23:54:00.002-07:002018-09-25T11:37:03.473-07:00Recently in Geoclue<div dir="ltr" style="text-align: left;" trbidi="on"><div>After I started working for <a href="https://collabora.com/" target="_blank">Collabora</a> in April, I've finally been able to put some time on maintenance and development of <a href="https://gitlab.freedesktop.org/geoclue/geoclue/wikis/home" target="_blank">Geoclue</a> again. While I've fixed quite a few issues on the backlog, there has been some significant changes as of late, that I felt deserves some highlighting. Hence this blog post.<br />
<br />
<h4 style="text-align: left;">Leaving security to where it belongs</h4><h4 style="text-align: left;"> </h4><div class="separator" style="clear: both; text-align: center;"></div><div class="separator" style="clear: both; text-align: center;"><a href="https://techcrunch.com/wp-content/uploads/2017/07/gettyimages-155438989.jpg?w=1390&crop=1" imageanchor="1" style="margin-left: 1em; margin-right: 1em;"><img border="0" data-original-height="537" data-original-width="800" height="214" src="https://techcrunch.com/wp-content/uploads/2017/07/gettyimages-155438989.jpg?w=1390&crop=1" width="320" /></a></div><br />
Since people's location is a very sensitive piece of information, security of this information had been the core part of Geoclue2 design. The idea was (and still is) to only allow apps access to user's location with their explicit permission (that they could easily revoke later). When Geoclue2 was designed and then developed, we didn't have <a href="https://flatpak.org/" target="_blank">Flatpak</a>. Surely, people were talking about the need for something like Flatpak but even with those ideas, it wasn't clear how location access will be handled.<br />
<br />
Hence we decided for geoclue to handle this itself, through an external app authorizing agent and implemented such an agent in GNOME Shell. Since there is no reliable way to identify an app on Linux, there were mixed reactions to this approach. While some thought it's good to have something rather than nothing, others thought it's better to wait for the time when we've the infrastructure that allows us to reliably identify apps. <br />
<br />
Fast forward to an year or so ago, when Flatpak portals became a thing, I had a long discussion with Matthias Clasen and Bastien Nocera about how geoclocation should work in Flatpak. We disagreed on our approach and we forgot about the whole thing then.<br />
<br />
Some months ago, we had to make app authorizing agent compulsory to plug some security holes and that made a <a href="https://github.com/jonls/redshift/issues/636" target="_blank">lot of people</a> who don't use GNOME, unhappy. We had to start installing the demo agent for non-GNOME as a workaround. This forced me to rethink the whole approach and after some more long discussions with Matthias and a lot of thinking, the plan is to:<br />
<ul style="text-align: left;"><li>Create a Flatpak geolocation portal. Matthias already has a work-in-progress <a href="https://github.com/matthiasclasen/xdg-desktop-portal/tree/location" target="_blank">implementation</a>. I really wanted the portal API to be as identical to the <a href="https://www.freedesktop.org/software/geoclue/docs/" target="_blank">Geoclue API</a> but <a href="https://gitlab.freedesktop.org/geoclue/geoclue/merge_requests/11#note_25149" target="_blank">I failed to convince Matthias</a> on that. This is not that big an issue though, as at least the apps using <a href="https://www.freedesktop.org/software/geoclue/docs/libgeoclue/GClueSimple.html" target="_blank">GeoclueSimple API</a> will not need to change anything for accessing location from inside the Flatpak sandbox.</li>
<li>Drop all authorization from Geoclue and leave that to the geolocation portal. I've already dropped authorization for non-flatpak (i-e system) apps in git master. Once the portal is in place and GNOME shell and control-center have been modified to talk to it, we can drop all app authorizing code from Geoclue.<b> <br />
<br />
Note</b> that we have been able to reliably identify Flatpak apps and it's only the system apps that can lie about their identity. </li>
</ul></div><div><h4 style="text-align: left;">A modern build system</h4><h4 style="text-align: left;"> </h4><div class="separator" style="clear: both; text-align: center;"><a href="https://www.exxelpacific.com/wp-content/uploads/2017/05/StressFreeBuild_OthelloStation_big.jpg" imageanchor="1" style="margin-left: 1em; margin-right: 1em;"><img border="0" data-original-height="379" data-original-width="800" height="151" src="https://www.exxelpacific.com/wp-content/uploads/2017/05/StressFreeBuild_OthelloStation_big.jpg" width="320" /></a></div><br />
Like many Free Software projects, Geoclue is also now using <a href="https://mesonbuild.com/" target="_blank">Meson</a> for its builds. After it started to work reliably, I also dropped autotools-based build completely. The faster build makes development a much more pleasant experience.<br />
<br />
<h4 style="text-align: left;">And a modern issue tracker to go with it</h4><h4 style="text-align: left;"> </h4><a href="https://bugs.freedesktop.org/" target="_blank">Bugzilla</a> served us well but patches in Bugzilla are no fun, even though git-bz makes it much much better. So when Daniel Stone setup <a href="https://gitlab.freedesktop.org/" target="_blank">gitlab on freedesktop.org</a>, Geoclue was one of the first few projects to move to gitlab. Now it's much easier and simpler to contribute to Geoclue.<br />
<br />
<h4 style="text-align: left;">Minimize GeoIP use</h4><h4 style="text-align: left;"> </h4>While GeoIP is a nice backup if you have neither WiFi hardware nor a cellular modem, Geoclue would also use (only) that if an app only asked for city-level accuracy. Apps like GNOME Weather and GNOME Clocks ask for only that since that's the info they need and don't need to know which street you're currently on. This would be perfect if only the GeoIP database being used would be correct or accurate for at least 90% of the IP addresses but unfortunately the reality is far from that. This meant, a significant number of people getting annoyed with these apps showing them time and weather of a different town than their current one.<br />
<br />
On the other hand, we couldn't just use a more accurate geolocation source (WiFi) since an app should not get more accurate location it asked for and it was authorized for by the user. While currently we don't have the UI in GNOME (or any other platform) that allows users to control the location accuracy, the infrastructure has always been in place to do that.<br />
<br />
Recently one person decided to not only <a href="https://gitlab.freedesktop.org/geoclue/geoclue/issues/64" target="_blank">report</a> this but had a good suggestion that I recently implemented: Use WiFi geolocation for city-level accuracy as well but randomize the location enough to mitigate the privacy concerns. It should be noted that while this solution ensures that apps don't get more accurate location then they should, it still means sending out the current WiFi data to the <a href="https://wiki.mozilla.org/CloudServices/Location" target="_blank">Mozilla Location Service</a> (MLS) and Geoclue getting a very accurate (street-level) location in response. It's all over HTTPS so it's not as bad as it sounds.<br />
<br />
<h4 style="text-align: left;">The future of Mozilla Location Service</h4><h4 style="text-align: left;"><br />
</h4><div style="text-align: left;">When Mozilla announced their location service in late 2013, Geoclue became one of it's first users as it was our only hope for a reliable WiFi-geolocation source. We couldn't use Google's service as their ToC don't allow it to be used in an open source project (I recall some clause that it can only be used with Google Maps and not any other Map software). MLS was a huge success in terms of people contributing WiFi data to it. I've been to quite a few places around Europe and North America in the last few years and I haven't been to any location, that is not already covered by MLS.</div><div style="text-align: left;"><br />
</div><div style="text-align: left;">Mozilla's own interest in this service was tied to their Firefox OS project. Unfortunately Firefox OS project was abandoned two years ago and Mozilla lost its interest in MLS as a result. Mozilla folks are the good guys so they have kept the service running and users can still contribute data but it's no longer developed or maintained.</div><div style="text-align: left;"><br />
</div><div style="text-align: left;">Since this is a very important service for all users of geoclue, I feel very uneasy about this uncertain future of MLS. So consider this a call for help. If your company relies on MLS (directly or through Geoclue) and you'd want to secure the future of Open Source geolocation, please do get in touch and we can discuss how we could possibly achieve that.</div></div><div class="s3gt_translate_tooltip_mini_box" id="s3gt_translate_tooltip_mini" is_bottom="true" is_mini="true" style="background: initial !important; border-collapse: initial !important; border-radius: initial !important; border-spacing: initial !important; border: initial !important; box-sizing: initial !important; color: inherit !important; direction: ltr !important; display: initial !important; flex-direction: initial !important; font-family: X-LocaleSpecific, sans-serif, Tahoma, Helvetica !important; font-size: 13px !important; font-weight: initial !important; height: initial !important; left: 159px; letter-spacing: initial !important; line-height: 13px !important; margin: auto !important; max-height: initial !important; max-width: initial !important; min-height: initial !important; min-width: initial !important; outline: initial !important; overflow-wrap: initial !important; padding: initial !important; position: absolute; table-layout: initial !important; text-align: initial !important; text-shadow: initial !important; top: 378px; vertical-align: top !important; white-space: inherit !important; width: initial !important; word-break: initial !important; word-spacing: initial !important;"><div class="s3gt_translate_tooltip_mini" id="s3gt_translate_tooltip_mini_logo" title="Translate selected text"></div><div class="s3gt_translate_tooltip_mini" id="s3gt_translate_tooltip_mini_sound" title="Play" title_play="Play" title_stop="Stop"></div><div class="s3gt_translate_tooltip_mini" id="s3gt_translate_tooltip_mini_copy" title="Copy text to Clipboard"></div><link href="moz-extension://69bb4812-bcdf-460d-a90c-c7485ee02a06/skin/s3gt_tooltip_mini.css" rel="stylesheet" type="text/css"></link><style media="print" type="text/css">#s3gt_translate_tooltip_mini { display: none !important; }</style></div></div>zeenixhttp://www.blogger.com/profile/04142631863736897222noreply@blogger.com3tag:blogger.com,1999:blog-3575421168816814786.post-2273422704449710562018-05-18T07:59:00.000-07:002018-05-18T07:59:32.759-07:00Collabora and GStreamer spring in Sweden<div dir="ltr" style="text-align: left;" trbidi="on">
Earlier this month, a few of us from Collabora, Olivier Crête, Nicolas Dufresne, George Kiagiadakis and I attended the GStreamer Spring Hackfest in Lund, Sweden. Hosted
by <a href="https://www.axis.com/" target="_blank">Axis Communications</a>
(who uses GStreamer in their surveillance cameras for many years now),
it was a great opportunity for the GStreamer community to touch base and
work on open bugs and pet projects.<br />
<br />
<br />
<div class="separator" style="clear: both; text-align: center;">
<a href="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEia17Q2M4EmFHBkeZbl2UNSk5_2W0PbO0rdiNRRUM7pn4qaMDLLTW5el2NXI6iY52RxUAB-H8Au_rFz2QD0FAjnufN74C1CA0rA8nA2D9vvJkDrqa39BuRiaPIrBptefCSZcDR1D0eMusIO/s1600/Collabora-GStreamerHackfest2018.jpg" imageanchor="1" style="margin-left: 1em; margin-right: 1em;"><img border="0" data-original-height="341" data-original-width="987" height="138" src="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEia17Q2M4EmFHBkeZbl2UNSk5_2W0PbO0rdiNRRUM7pn4qaMDLLTW5el2NXI6iY52RxUAB-H8Au_rFz2QD0FAjnufN74C1CA0rA8nA2D9vvJkDrqa39BuRiaPIrBptefCSZcDR1D0eMusIO/s400/Collabora-GStreamerHackfest2018.jpg" width="400" /></a></div>
<br />
While I've been involved in the GStreamer project in the past, it was
my first GStreamer hackfest. While a lot was achieved during the event,
the most exciting outcomes were no doubt the closing of more than 350
bugs, and the agreement on a transition plan to move to GitLab.<br />
<br />
Overall, the hackfest was very productive, with each member of our
team managing to progress in their list of tasks while all taking part
in bug triaging & cleaning in preparation of moving GStreamer's
issue tracking to GitLab.<br />
<br />
George spent time working on improving the new library API that is
needed to introduce support for the non-interleaved audio layout,
discussed a gst-rtsp-server issue with the Axis team, and merged all
qt-gstreamer patches that were lying around in bugzilla and resolved all
reported bugs, then declared it as unmaintained.<br />
<br />
For his part, Nicolas participated in the planar audio format and
split field interlaced video support work, started looking at adding per
element latency tracing to GStreamer's existing latency tracer, and
also discussed GStreamer CI, which will also move to GitLab to be able
to run on pull requests also.<br />
<br />
Olivier, during the first day, focused on the collective effort of
reviewing all of the open bugs, managing to close a number of them while
confirming and commenting on others. He also merged some outstanding
patches he had (stay tuned for more details on those), and forward
ported gst-validate for Android with the goal of running the CI on
Android. He also merged a series of patches that enable bitcode
embedding on the iOS target with the eventual goal of supporting tvOS as
well.<br />
<br />
As for myself, I mainly worked on (or rather started to work on)
split-field interlacing support in GStreamer, adding relevant formats
and modes in the GStreamer video library. In addition, as a Meson
developer (Nirbheek Chauhan) was present, I took the opportunity to
discuss with him the last bit of porting build system of Geoclue to
Meson, a side project I've been working on. It helped me get it done
faster but also helped Nirbheek find some issues in Meson and fix them!<br />
<br />
All in all, my first GStreamer hackfest was an awesome experience
(even though I was not feeling well). It was also very nice to hangout
and socialize with old and new friends in the GStreamer community after a
long time. Many thanks again to Axis for hosting us in their offices!
See you at the GStreamer Conference this fall!</div>
zeenixhttp://www.blogger.com/profile/04142631863736897222noreply@blogger.com0tag:blogger.com,1999:blog-3575421168816814786.post-24012342389405428132018-04-02T03:35:00.001-07:002018-04-02T03:35:52.286-07:00Joining Collabora<div dir="ltr" style="text-align: left;" trbidi="on">
Last Thursday was my last day at <a href="https://kinvolk.io/" target="_blank">Kinvolk</a>. While Kinvolk is a great company run by very nice and talented folks and I really hoped to work there for a very long time, unfortunately it turned out to be not the best fit for me.<br />
<br />
While I am sad to leave, I am also very excited to join <a href="https://collabora.co.uk/" target="_blank">Collabora</a> in their multimedia team. Today is my first day there. Since Collabora does not exist in Germany, I will be working for them as a consultant and had to register my own one-man company. Yes, I will be staying in Berlin and work from home.<br />
<br />I have known Collabora from its very early days, when it was just a few developers with a vision and passion for Open Source. I also worked very closely with Collabora over the years during the good old Nokia Maemo/Meego times. I always had great appreciation for their work and commitment to Open Source, which is a huge challenge for a consulting company.<br />
<br />
While I do not yet know which specific projects I will be
involved in at Collabora, I'm most likely going to be working on/with
GStreamer again and I'm especially excited about that. Also exciting for
me is the fact that people at Collabora share my appreciation for the
Rust programming language. </div>
zeenixhttp://www.blogger.com/profile/04142631863736897222noreply@blogger.com0tag:blogger.com,1999:blog-3575421168816814786.post-62716042412256053772017-12-27T05:37:00.000-08:002017-12-27T05:37:49.214-08:00My journey to Rust<div dir="ltr" style="text-align: left;" trbidi="on">
<div style="text-align: left;">
<div>
As most folks who know me already
know, I've been in love with Rust language for a few years now and in
the last year I've been actively coding in Rust. I wanted to document my
journey to how I came to love this programming language, in hope that
it will help people to see the value Rust brings to the world of
software but if not, it would be nice to have my reason documented for
my own sake.<br />
<br />
When I started my professional career as a
programmer 16 years ago, I knew some C, C++, Java and a bit of x86
assembly but it didn't take long before I completely forgot most of what
I knew of C++ and Java, and completely focused on C. There were a few
difference reasons that contributed to that:<br />
<ul style="text-align: left;">
<li>Working with very limited embedded systems (I'm talking <a href="https://en.wikipedia.org/wiki/Intel_MCS-51" target="_blank">8051</a>)
at that time, I quickly became obsessed with performance and C was my
best bet if I didn't want to write all my code in assembly. </li>
<li>Shortly
before I graduated, I got involved in GStreamer project and became a
fan of GNOME and Gtk+, all of which at that time was in C. Talking to
developers of these projects (who at that time seemed like gods), I
learnt how C++ is a bad language and why they write everything in C
instead.</li>
<li>An year after graduation, I developed a network traffic
shaping solution and the core of it was a Linux kernel module, which as
you know is almost always done in C. Some years later, I also wrote
some device drivers for Linux.</li>
</ul>
</div>
The more C code I wrote
over the years, the more I developed this love/hate relationship with
it. I just loved the control C gave me but hated the huge responsibility
it came with. With experience, I became good at avoiding common
mistakes in C, but nobody is perfect and if you can make a mistake, you
eventually will. Another reason C didn't seem perfect to me was the lack
of high-level constructs in the language itself. Copy&pasting
boilerplate to write simple <a href="https://developer.gnome.org/gobject/stable/chapter-gobject.html" target="_blank">GObjects</a>
is nothing most people enjoy. You end up avoiding to organise your code
in the best way to spare yourself the trouble of having to write
GObjects.<br />
<br />
So I've been passively and sometimes
actively seeking a better programming language for more than a decade
now. I got excited about a few different ones over the years but there
was always something very essential missing. The first language I got
into was Lisp/Scheme (more specifically Guile) but the lack of type
declarations soon started to annoy me a lot. I felt the same after then
about all scripting languages, e.g Python. Don't get me wrong, python is
a pretty awesome language for specific uses (e.g writing tests, simple
apps, quick prototyping etc) but with lack of type declarations, any
project larger than 1000 LOCs can quickly become hard to maintain (at
least it did for me).<br />
<br />
Because of my love for strong-typing, C#
and Java did attract me too briefly. Not having to care about memory
management in most cases, not only helps developers focus on the actual
problems they are solving, it indirectly allows them to avoid making
very expensive mistakes with memory management. However, if developer is
not managing the memory, it's the machine doing it and in case of these
languages, it does that at run time and not compile time. As a C
developer and a big hater of waste in general, that is very hard to be
convinced of as a good idea.<br />
<br />
There was another big problem
all these high-level languages: you can't nicely glue them with the C
world. Sure you can use libraries written in C from them but the other
way around is not a viable option (even if possible). That's why you'll
find GNOME apps written in all these languages but you will not find any
libraries written in them.<br />
<br />
<h4 style="text-align: left;">
Along came Vala</h4>
<br />
So along came <a href="https://wiki.gnome.org/Projects/Vala" target="_blank">Vala</a>, which offered features that at that time (2007-2008) were the most important to me:<br />
<ul style="text-align: left;">
<li>It is a strongly-typed language.</li>
<li>It manages the memory for you in most cases but without any run time costs.</li>
<li>It's high-level language so you avoid a lot of boilerplate. </li>
<li>GNOME was and still is the main target platform of Vala.</li>
<li>It compiled to C, so you can write libraries in it and use them from C code as if they were written in C. Because of <a href="https://wiki.gnome.org/action/show/Projects/GObjectIntrospection" target="_blank">GObject-introspection</a>, this also means you can use them from other languages too. </li>
</ul>
</div>
<div style="text-align: left;">
Those
who know me, will agree that I was die-hard (I'm writing this on
Christmas day so that reference was mandatory I guess) fan of Vala for a
while. I wrote two projects in Vala and given what I knew then I think
it was the right decision. Some people will be quick to point out
specific technical issues with Vala but I think those could have been
helped. There two other reasons, I ultimately gave up on Vala. The first
one was that the general interest in it started to decline after Nokia
stopped funding projects using Vala and so did its development.</div>
<h4 style="text-align: left;">
</h4>
<h4 style="text-align: left;">
Hello Rust</h4>
<div style="text-align: left;">
<br /></div>
<div style="text-align: left;">
But
the main reason for giving up was that I saw something better finally
becoming a viable option (1.0 release) and gaining adoption in many
communities, including GNOME. While Vala had many good qualities I
mentioned above, Rust offered even more:</div>
<ul style="text-align: left;">
<li>Firstly
the success of Rust is not entirely dependent on one very specific
project or a tiny group of people, even if until now most of the
development has been from one company. Ever month, you hear of more
communities and companies starting to depend on Rust and that ensure
it's success even if Mozilla was to go down (not that I think it's
likely) or stopped working on it. i-e "it's too big to fail". If we
compare to Vala, the community is a lot bigger. There are <a href="http://zurich.rustfest.eu/" target="_blank">conferences</a> and <a href="https://wiki.gnome.org/Hackfests/Rust2017" target="_blank">events </a>happening
around the world that are entirely focused on Rust and there are books
written on Rust. Vala never came anywhere remotely close to that level
of popularity.<br /><br />When I would mention Vala in job interviews,
interviewers would typically have no idea what I'm talking about but
when I mention Rust, the typical response is "Oh yes we are interested
in trying that out in our company".</li>
<li>While Vala is
already a safer language than C & C++, you still have null-pointer
dereferencing and some other unsafe possibilities. Safety being one of
the main focus of the language design, Rust will not allow you to build
unsafe code, unless you mark it as such and even then, your
possibilities of messing up are limited. Marking unsafe code as such,
makes it much easier to find the source of any issues you might have.
More over, you usually only write unsafe code to interface with the
unsafe C world.<br /><br />This is a very important point in my opinion. I really do not want to live in a world where <a href="https://raygun.com/blog/10-costly-software-errors-history/" target="_blank">simple human errors are allowed cause disasters</a>.</li>
</ul>
<div style="text-align: left;">
Admittedly, there are some benefits of Vala over Rust:</div>
<ul style="text-align: left;">
<li>Ability to easily write GObjects.</li>
<li>Creating shared libraries.</li>
</ul>
However, some people have been <a href="https://github.com/nikomatsakis/gnome-class" target="_blank">working on the former</a> and latter is already possible with <a href="https://people.gnome.org/~federico/blog/librsvg-posts.html" target="_blank">some compromise and tricks</a>.<br />
<h4 style="text-align: left;">
</h4>
<h4 style="text-align: left;">
Should we stop writing C/C++ code?</h4>
<div style="text-align: left;">
<br /></div>
<div style="text-align: left;">
Ideally?
Yes! Most definitely, yes. Practically speaking, that is not an option
for most existing C/C++ projects out there. I can only imagine the huge
amount of resources needed for porting large projects, let alone
training existing developers on Rust. Having said that, I'd urge every
developer to at least seriously consider writing all new code in Rust
rather than C/C++.</div>
<div style="text-align: left;">
<br /></div>
<div style="text-align: left;">
Especially
if you are writing safety-critical software (people implementing
self-driving cars, militaries and space agencies, I'm looking at you!),
laziness and mental-inertia are not valid reasons to continue writing
potentially unsafe code, no matter how smart and good at C/C++ you think
you are. You <b>will</b> eventually make mistake and when you do, lives will be at stake. Think about that please.</div>
<h4 style="text-align: left;">
</h4>
<h4 style="text-align: left;">
Conclusion</h4>
<br />
I
am excited about Rust and I'm hopeful the future is much safer thanks
to people behind it. Happy holidays and have a fun and safe 2018!</div>
zeenixhttp://www.blogger.com/profile/04142631863736897222noreply@blogger.com11tag:blogger.com,1999:blog-3575421168816814786.post-25217368522842212672017-12-08T05:39:00.000-08:002017-12-08T05:39:23.328-08:00Moving to Berlin<div dir="ltr" style="text-align: left;" trbidi="on">
I have been meaning to document my experience of moving to Berlin, mainly to help people who are considering to move or are about to move. However I'm lazy and unless I'm paid to do so, I just won't get around to doing that so instead of ending up posting nothing, I'll just quickly list all the advice I have here:<br />
<br />
<ul style="text-align: left;">
<li>Don't actually order any services through check24 website. Only use them to compare prices etc.</li>
<li>Avoid Vodafone for broadband connection. Follow <a href="https://twitter.com/zeenix/status/938697211822649344" target="_blank">this thread</a> for why.</li>
<li>Consider using an online bank, like N26.</li>
<li>For your Anmeldung,</li>
<ul>
<li>go to Bürgeramt in Neukölln or Kreuzberg (unless you speak German).</li>
<li>book appointment around noon or be prepared to wait a month. </li>
</ul>
<li>Make sure you have local friends who speak German and are willing to help you out. Many locals will tell you that you don't need German in Berlin but that is simply not true.</li>
<li>Either consider hiring an estate agent or make sure your temporary residence allows you to register on their address.</li>
<li>Related to above, you don't have to pay deposit upfront if you use <a href="https://www.eurokaution.de/" target="_blank">EuroKaution servic</a>e. </li>
<li>Consider the after 10am monthly travel pass if you don't commute to work before that time. </li>
</ul>
</div>
zeenixhttp://www.blogger.com/profile/04142631863736897222noreply@blogger.com1Berlin, Germany52.520006599999988 13.40495399999997552.21073109999999 12.759506999999974 52.829282099999986 14.050400999999976tag:blogger.com,1999:blog-3575421168816814786.post-31884832222362214892017-08-21T12:56:00.001-07:002017-08-23T03:45:51.969-07:00Ich bin ein Berliner<div dir="ltr" style="text-align: left;" trbidi="on"><div dir="ltr" style="text-align: left;" trbidi="on">Well, no, not really but maybe I'll be able to claim that at some point because I'm moving to Berlin to join Kinvolk. I'm told that I'm changing countries and companies too often but that's not true. I was at Red Hat for 5 years and at Nokia before that for 5 years as well. The decision to move out of Finland was not exactly mine.<br />
<br />
<h2 style="text-align: left;">Regarding Pelagicore</h2><br />
I'm not as much leaving <a href="http://www.pelagicore.com/" target="_blank">Pelagicore</a> as I'm leaving the automotive industry, more specifically the software side of it. While the automotive industry is changing and mostly for the good, I realized that it still is not a place for me. Things typically move very slowly in this industry and I realized that I don't have the required patience for it. Also, C++/Qt are big here and while an year ago I thought it's just another language and Open Source UI framework, I no longer think so. Since you can find a lot of rants from very experienced C++ developers on why C++ is a horrible language, I won't rant about that in here.<br />
<br />
My experience with Qt hasn't been that great either. Most of the documentation I found would simply assume you use Qt Creator and despite my years of experience with D-Bus, it took me weeks to figure out how to make a few D-Bus calls from Qt (I have to admit though that the calls involved complex types). While Nokia made Qt a normal Open Source project by relicensing it under LGPLv2, the Qt company recently realized that it's loosing a lot of money by people using Qt in products without paying them anything so they relicensed it under GPLv3 and commercial (i-e dual-license). I maintained Genivi Development Platform for 6 months and because of this relicensing, we were unable to upgrade Qt 5.6 to Qt 5.7 and overtime it had been becoming a major pain point in that project. To make things even less open-sourcy, they require all contributors to sign a <a href="https://www.qt.io/contributionagreement/" target="_blank">CLA</a>. I believe (and I think many would agree) that CLAs are bad for Open Source. So all those things put together, I don't think of Qt as a typical Open Source project. Feel free to disagree but that's how I feel and hence I'm not keen on working with Qt in future.</div><br />
Having said all that, Pelagicore is a very awesome company and probably the best place to be if you're fine with C++/Qt and want to be part of the next-gen automotive. It might sound like I just contradicted myself but not everyone thinks and sees the world like me. To each, his own and all. Also <a href="http://career.pelagicore.com/">Pelagicore</a> is hiring!<br />
<br />
<h2 style="text-align: left;"><span style="color: #09102b; font-family: "titillium web" , sans-serif;"><span style="background-color: white;"><br />
</span></span></h2><h2 style="text-align: left;"><span style="color: #09102b; font-family: "titillium web" , sans-serif;"><span style="background-color: white;">Why leave Gothenburg?</span></span></h2><br />
Gothenburg is a very lovely city and I'm going to miss it a lot for sure, even though I've been only here for an year. I still love the Swedish language, which I have been learning slowly over the year. However, I've not been happy with the cost of living in here, especially Veterinary costs. I have an old cat with multiple conditions so I need to visit the Vet every few months. The Vet charge 700 SEK just to see him and most often they don't even care to read through his records beforehand.<br />
<br />
Gothenburg is also currently the best place to find an accommodation in. To get a first-hand contract, you register yourself in on <a href="https://nya.boplats.se/" target="_blank">Boplats</a> website and keep on applying to new listings but typical wait-time is in years, not months or weeks. In practice, it's usually not a problem. Most people just get a second-hand contract or a room in a shared flat to start with and then look for a more permanent solution. However, add a cat into the picture and things get very difficult again.<br />
<br />
<h2 style="text-align: left;">Kinvolk comes along</h2><br />
Because of the reasons stated above, I've been looking for some exciting opportunities outside automotive world in some nice location. I had been focused on finding jobs that either involve Rust language or at least there were good chances of Rust being involved. Long story short, I ultimately got in touch with <a href="https://kinvolk.io/" target="_blank">Kinvolk</a> folks. I already knew the company's founders: Chris, Alban and Iago. They are very good at what they do and fun folks to hang out with.<br />
<br />
While Rust is not a big part of work at Kinvolk currently, they (especially Chris) seem very interested in it. From what I know, main languages at Kinvolk are C and Go. I don't mind coding in C anyway and I've been missing the times when I did any kernel programming in it. I've no experience of Go but from what I hear, it's a pretty decent language.<br />
<br />
So after interviews etc, when Kinvolk offered me a job, I couldn't resist accepting it. Berlin is an awesome city and it's hard to say "no" to moving there.<br />
<br />
If you're looking for a great place to work at on Linux-related tech with some very competent Open Source developers, do consider applying at <a href="https://kinvolk.io/careers/" target="_blank">Kinvolk</a>.<br />
<br />
<h2 style="text-align: left;">Cellink</h2><br />
Talking of great companies to work at, I recently got in contact with some folks from <a href="https://cellink.com/" target="_blank">Cellink</a>. It's a biotech company based in Gothenburg, whose aim is to end animal testing. They plan to achieve this very noble goal through 3D printers that print human tissues. They already have 2 products that they sell to pharmaceutical companies in 30 countries across the globe. While they already have the bio and hardware side of things covered, they are looking to expand their software side of things now and to do that, they need good software engineers, especially ones with Open Source experience.<br />
<br />
<a href="https://www.youtube.com/watch?v=-JZPUWj6-zI" target="_blank">Here is a video</a> of a very nice intro to their awesome work from their CEO, Erik Gatenholm.<br />
<br />
So if you're an Open Source developer and either live in or willing to relocate to (especially) Gothenburg, Cambridge (USA) or Bay Area, please contact me and I can connect you to the right people. Alternatively, feel free to contact them directly. I only want to help these folks achieve their very noble cause.</div>zeenixhttp://www.blogger.com/profile/04142631863736897222noreply@blogger.com6tag:blogger.com,1999:blog-3575421168816814786.post-70846297481698977942017-06-15T02:04:00.003-07:002017-06-15T02:04:25.744-07:00Help me test gps-shareFor <a href="http://zee-nix.blogspot.com/2017/05/introducing-gps-share.html">gps-share</a> to be useful to people, it needs to be tested against various GPS dongles. If you have a GPS dongle, I'd appreciate it if you could test gps-share. If you don't use the hardware, please consider donating it to me and that way I'll ensure that it keeps working with gps-share.<br />
<br />
Thanks!<br />
zeenixhttp://www.blogger.com/profile/04142631863736897222noreply@blogger.com3tag:blogger.com,1999:blog-3575421168816814786.post-82854483815457883062017-05-30T03:57:00.001-07:002017-06-08T10:06:19.598-07:00Introducing gps-shareSo yesterday, I rolled out the <a href="https://github.com/zeenix/gps-share/releases/tag/0.1.0">first release</a> of gps-share.<br />
<br />
gps-share is a utility to share your GPS device on local network. It has two goals:<br />
<br />
<ul><li> Share your GPS device on the local network so that all machines in your home or office can make use of it.</li>
<li> Enable support for standalone (i-e not part of a cellular modem) GPS devices in Geoclue. Since Geoclue has been able to make use of network NMEA sources since 2015, gps-share works out of the box with Geoclue.</li>
</ul><br />
The latter means that it is a replacement for <a href="https://en.wikipedia.org/wiki/Gpsd">GPSD</a> and <a href="https://gypsy.freedesktop.org/wiki/">Gypsy</a>. While "why not GPSD?" has already been <a href="https://gypsy.freedesktop.org/why-not-gpsd.html">documented</a>, Gypsy has been unmaintained for many years now. I did not feel like reviving a dead project and I really wanted to code in Rust language so I decided to create gps-share.<br />
<br />
<h2>Dependencies</h2><br />
While cargo manages the Rust crates gps-share depend on, you'll also<br />
need the following on your host:<br />
<br />
<ul><li> libdbus</li>
<li> libudev</li>
<li> libcap</li>
<li> xz-libs</li>
</ul><br />
<h2>Supported devices</h2><br />
gps-share currently only supports GPS devices that present themselves as serial port (RS232). Many USB are expected to work out of the box but bluetooth devices need manual intervention to be mounted as serial port devices through rfcomm command. The following command worked on my Fedora 25 machine for a TomTom Wireless GPS MkII.<br />
<br />
<br />
sudo rfcomm connect 0 00:0D:B5:70:54:75<br />
<br />
gps-share can autodetect the device to use if it's already mounted as a serial port but it assumes a baudrate of 38400. You can manually set the device node to use by passing the device node path as argument and set the baudrate using the '-b' commandline option. Pass '--help' for a full list of supported options.<br />
zeenixhttp://www.blogger.com/profile/04142631863736897222noreply@blogger.com8tag:blogger.com,1999:blog-3575421168816814786.post-12526588282892702702017-05-08T00:00:00.000-07:002017-05-08T13:49:43.190-07:00Rust Memory ManagementIn the light of my latest fascination with Rust programming language, I've started to make small presentation about Rust at <a href="http://www.pelagicore.com/">my office</a>, since I'm not the only one at our company who is interested in Rust. My first presentation in Feb was about a very general introduction to the language but at that time I had not yet really used the language for anything real myself so I was a complete novice myself and didn't have a very good idea of how memory management really works. While working on my <a href="https://github.com/zeenix/gps-share">gps-share project</a> in my limited spare time, I came across quite a few issues related to memory management but I overcame all of them with help from kind folks at #rust-beginners IRC channel and the small but awesome Rust-GNOME community.<br />
<br />
Having learnt some essentials of memory management, I thought I share my knowledge/experience with folks at the office. The talk was not well-attended due to conflicts with other meetings at office but the few folks who attended were very interested and asked some interesting and difficult questions (i-e the perfect audience). One of the questions was if I could put this up as a blog post so here I am. :)<br />
<br />
<h2>Basics</h2><br />
Let's start with some basics: In Rust,<br />
<br />
<ol><li>stack allocation is preferred over the heap allocation and that's where everything is allocated by default.</li>
<li>There is strict ownership semantics involved so each value can only and only have one owner at a particular time.</li>
<li>When you pass a value to a function, you move the ownership of that value to the function argument and similarly, when you return a value from a function, you pass the ownership of the return value to the caller.</li>
</ol><br />
Now these rules make Rust very secure but at the same time if you had no way to allocate on the heap or be able to share data between different parts of your code and/or threads, you can't get very far with Rust. So we're provided with mechanisms to (kinda) work around these very strict rules, without compromising on safety these rules provide. Let's start with a simple code that will work fine in many other languages:<br />
<br />
<pre>fn add_first_element(v1: Vec<i32>, v2: Vec<i32>) -> i32 {
return v1[0] + v2[0];
}
fn main() {
let v1 = vec![1, 2, 3];
let v2 = vec![1, 2, 3];
let answer = add_first_element(v1, v2);
// We can use `v1` and `v2` here!
println!("{} + {} = {}", v1[0], v2[0], answer);
}
</pre><br />
This gives us an error from rustc:<br />
<br />
<pre>error[E0382]: use of moved value: `v1`
--> sample1.rs:13:30
|
10 | let answer = add_first_element(v1, v2);
| -- value moved here
...
13 | println!("{} + {} = {}", v1[0], v2[0], answer);
| ^^ value used here after move
|
= note: move occurs because `v1` has type `std::vec::Vec<i32>`, which does not implement the `Copy` trait
error[E0382]: use of moved value: `v2`
--> sample1.rs:13:37
|
10 | let answer = add_first_element(v1, v2);
| -- value moved here
...
13 | println!("{} + {} = {}", v1[0], v2[0], answer);
| ^^ value used here after move
|
= note: move occurs because `v2` has type `std::vec::Vec<i32>`, which does not implement the `Copy` trait
</pre><br />
What's happening is that we passed 'v1' and 'v2' to add_first_element() and hence we passed its ownership to add_first_element() as well and hence we can't use it afterwards. If Vec was a Copy type (like all primitive types), we won't get this error because Rust will copy the value for add_first_element and pass those copies to it. In this particular case the solution is easy:<br />
<br />
<h2>Borrowing</h2><br />
<pre>fn add_first_element(v1: &Vec<i32>, v2: &Vec<i32>) -> i32 {
return v1[0] + v2[0];
}
fn main() {
let v1 = vec![1, 2, 3];
let v2 = vec![1, 2, 3];
let answer = add_first_element(&v1, &v2);
// We can use `v1` and `v2` here!
println!("{} + {} = {}", v1[0], v2[0], answer);
}
</pre><br />
This one compiles and runs as expected. What we did was to convert the arguments into reference types. References are Rust's way of borrowing the ownership. So while add_first_element() is running, it owns 'v1' and 'v2' but not after it returns. Hence this code works.<br />
<br />
While borrowing is very nice and very helpful, in the end it's temporary. The following code won't build:<br />
<br />
<pre>struct Heli {
reg: String
}
impl Heli {
fn new(reg: String) -> Heli {
Heli { reg: reg }
}
fn hover(& self) {
println!("{} is hovering", self.reg);
}
}
fn main() {
let reg = "G-HONI".to_string();
let heli = Heli::new(reg);
println!("Registration {}", reg);
heli.hover();
}
</pre><br />
rustc says:<br />
<br />
<pre>error[E0382]: use of moved value: `reg`
--> sample3.rs:20:33
|
18 | let heli = Heli::new(reg);
| --- value moved here
19 |
20 | println!("Registration {}", reg);
| ^^^ value used here after move
|
= note: move occurs because `reg` has type `std::string::String`, which does not implement the `Copy`
</pre><br />
If String had Copy trait implemented for it, this code would have compiled. But if efficiency is a concern at all for you (it is for Rust), you wouldn't want most values to be copied around all the time. We can't use a reference here as Heli::new() above needs to keep the passed 'reg'. Also note that the issue here is not that 'reg' was passed to Heli:new() and used afterwards by Heli::hover() afterwards but the fact that we tried to use 'reg' after we have given its ownership to Heli instance through Heli::new().<br />
<br />
I realize that the above code doesn't make use of borrowing but if we were to make use of that, we'll have to declare <a href="https://doc.rust-lang.org/book/lifetimes.html">lifetimes</a> for the 'reg' field and the code still won't work because we want to keep the 'reg' in our Heli struct. There is a better solution here:<br />
<br />
<h2>Rc</h2><br />
<pre>use std::rc::Rc;
struct Heli {
reg: Rc<String>
}
impl Heli {
fn new(reg: Rc<String>) -> Heli {
Heli { reg: reg }
}
fn hover(& self) {
println!("{} is hovering", self.reg);
}
}
fn main() {
let reg = Rc::new("G-HONI".to_string());
let heli = Heli::new(reg.clone());
println!("Registration {}", reg);
heli.hover();
}
</pre><br />
This code builds and runs successfully. <a href="https://doc.rust-lang.org/std/rc/">Rc</a> stands for "Reference Counted" so by putting data into this generic container, adds reference counting to the data in question. Note that while you had to explicitly call clone() method of Rc to increment its refcount, you don't need to do anything to decrease the refcount. Each time an Rc reference goes out of scope, the reference is decremented automatically and when it reaches 0, the container Rc and its contained data are freed.<br />
<br />
Cool, Rc is super easy to use so we can just use it in all situations where we need shared ownership? Not quite! You can't use Rc to share data between threads. So this code won't compile:<br />
<br />
<pre>use std::rc::Rc;
use std::thread;
struct Heli {
reg: Rc<String>
}
impl Heli {
fn new(reg: Rc<String>) -> Heli {
Heli { reg: reg }
}
fn hover(& self) {
println!("{} is hovering", self.reg);
}
}
fn main() {
let reg = Rc::new("G-HONI".to_string());
let heli = Heli::new(reg.clone());
let t = thread::spawn(move || {
heli.hover();
});
println!("Registration {}", reg);
t.join().unwrap();
}
</pre><br />
It results in:<br />
<br />
<pre>error[E0277]: the trait bound `std::rc::Rc<std::string::String>: std::marker::Send` is not satisfied in `[closure@sample5.rs:22:27: 24:6 heli:Heli]`
--> sample5.rs:22:13
|
22 | let t = thread::spawn(move || {
| ^^^^^^^^^^^^^ within `[closure@sample5.rs:22:27: 24:6 heli:Heli]`, the trait `std::marker::Send` is not implemented for `std::rc::Rc<std::string::String>`
|
= note: `std::rc::Rc<std::string::String>` cannot be sent between threads safely
= note: required because it appears within the type `Heli`
= note: required because it appears within the type `[closure@sample5.rs:22:27: 24:6 heli:Heli]`
= note: required by `std::thread::spawn`
</pre><br />
The issue here is that to be able to share data between more than one threads, the data must be of a type that implements <a href="https://doc.rust-lang.org/std/marker/trait.Send.html">Send trait</a>. However not only implementing Send for all types would be very impractical solution, there is also performance penalties associated with implementing Send (which is why Rc doesn't implement Send).<br />
<br />
<h2>Introducing Arc</h2><br />
<a href="https://doc.rust-lang.org/std/sync/struct.Arc.html">Arc</a> stands for Atomic Reference Counting and it's the thread-safe sibling of Rc.<br />
<br />
<pre>use std::sync::Arc;
use std::thread;
struct Heli {
reg: Arc<String>
}
impl Heli {
fn new(reg: Arc<String>) -> Heli {
Heli { reg: reg }
}
fn hover(& self) {
println!("{} is hovering", self.reg);
}
}
fn main() {
let reg = Arc::new("G-HONI".to_string());
let heli = Heli::new(reg.clone());
let t = thread::spawn(move || {
heli.hover();
});
println!("Registration {}", reg);
t.join().unwrap();
}
</pre><br />
This one works and the only difference is that we used Arc instead of Rc. Cool, so now we have a very efficient by thread-unsafe way to share data between different parts of the code but also a thread-safe mechanism as well. We're done then? Not quite! This code won't work:<br />
<br />
<pre>use std::sync::Arc;
use std::thread;
struct Heli {
reg: Arc<String>,
status: Arc<String>
}
impl Heli {
fn new(reg: Arc<String>, status: Arc<String>) -> Heli {
Heli { reg: reg,
status: status }
}
fn hover(& self) {
self.status.clear();
self.status.push_str("hovering");
println!("{} is {}", self.reg, self.status);
}
}
fn main() {
let reg = Arc::new("G-HONI".to_string());
let status = Arc::new("".to_string());
let mut heli = Heli::new(reg.clone(), status.clone());
let t = thread::spawn(move || {
heli.hover();
});
println!("main: {} is {}", reg, status);
t.join().unwrap();
}
</pre><br />
This gives us two errors:<br />
<br />
<pre>error: cannot borrow immutable borrowed content as mutable
--> sample7.rs:16:9
|
16 | self.status.clear();
| ^^^^^^^^^^^ cannot borrow as mutable
error: cannot borrow immutable borrowed content as mutable
--> sample7.rs:17:9
|
17 | self.status.push_str("hovering");
| ^^^^^^^^^^^ cannot borrow as mutable
</pre><br />
The issue is that Arc is unable to handle mutation of data from difference threads and hence doesn't give you mutable reference to contained data.<br />
<br />
<h2>Mutex</h2><br />
For sharing mutable data between threads, you need another type in combination with Arc: <a href="https://doc.rust-lang.org/std/sync/struct.Mutex.html">Mutex</a>. Let's make the above code work:<br />
<br />
<pre>use std::sync::Arc;
use std::sync::Mutex;
use std::thread;
struct Heli {
reg: Arc<String>,
status: Arc<Mutex<String>>
}
impl Heli {
fn new(reg: Arc<String>, status: Arc<Mutex<String>>) -> Heli {
Heli { reg: reg,
status: status }
}
fn hover(& self) {
let mut status = self.status.lock().unwrap();
status.clear();
status.push_str("hovering");
println!("thread: {} is {}", self.reg, status.as_str());
}
}
fn main() {
let reg = Arc::new("G-HONI".to_string());
let status = Arc::new(Mutex::new("".to_string()));
let heli = Heli::new(reg.clone(), status.clone());
let t = thread::spawn(move || {
heli.hover();
});
println!("main: {} is {}", reg, status.lock().unwrap().as_str());
t.join().unwrap();
}
</pre><br />
This code will work. Notice how you don't have to explicitly unlock the mutex after using. Rust is all about scopes. When the unlocked value goes out of the scope, mutex is automatically unlocked.<br />
<br />
<h2>Other container types</h2><br />
Mutexes are rather expensive and sometimes you have shared date between threads but not all threads are mutating it (all the time) and that's where <a href="https://doc.rust-lang.org/std/sync/struct.RwLock.html">RwLock</a> becomes useful. I won't go into details here but it's almost identical to Mutex, except that threads can take read-only locks and since it's possible to safely share non-mutable state between threads, it's a lot more efficient than threads locking other threads each time they access the data.<br />
<br />
Another container types I didn't mention above, is Box. The basic use of Box is that it's a very generic and simple way of allocating data on the heap. It's typically used to turn an unsized type into a sized type. The <a href"https://doc.rust-lang.org/std/boxed/">module documentation</a> has a simple example on that.<br />
<br />
<h2>What about lifetimes</h2><br />
One of my colleagues who had had some experience with Rust was surprised that I didn't cover <a href="https://doc.rust-lang.org/book/lifetimes.html">lifetimes</a> in my talk. Firstly, I think it deserves a separate talk of it's own. Secondly, if you make clever use of the container types available to you and described above, most often you don't have to deal with lifetimes. Thirdly, lifetimes is Rust is something that I still struggle with, each time I have to deal with it so I feel a bit unqualified to teach others about how they work.<br />
<br />
<h2>The end</h2><br />
I hope you find some of the information above useful. If you are looking for other resources on learning Rust, <a href="https://doc.rust-lang.org/book/README.html">the Rust book</a> is currently your best bet. I am still a newbie at Rust so if you see some mistakes in this post, please do let me know in the comments section.<br />
<br />
Happy safe hacking!zeenixhttp://www.blogger.com/profile/04142631863736897222noreply@blogger.com6tag:blogger.com,1999:blog-3575421168816814786.post-43517306764286322812017-04-06T04:31:00.000-07:002017-04-06T08:28:44.139-07:00GNOME ❤ Rust Hackfest in Mexico<div dir="ltr" style="text-align: left;" trbidi="on">While I'm known as a Vala fanboy in GNOME, I've tried to stress time and again that I see Vala as more a practical solution than an ideal one. "Safe programming" has always been something that intrigued me, having dealt with numerous crashes and other hard-to-debug runtime issues in the past. So when I first heard of Rust some years back, it got me super excited but it was not exactly stable and there was no integration with GNOME libraries or D-Bus and hence it was not at all a viable option for developing desktop code. Lately (in past 2 years) things have significantly changed. Not only we have Rust 1.0 but we also have crates that provide integration with <a href="http://gtk-rs.org/" target="_blank">GNOME libraries</a> and <a href="https://github.com/diwic/dbus-rs" target="_blank">D-Bus</a>. On top of that, some of us took steps to start converting some C code into Rust and many of us started seriously talking with Rust hackers to make Rust a first class programming language for GNOME.<br />
<div><br />
To make things really go foward, we decided to <a href="https://wiki.gnome.org/Hackfests/Rust2017" target="_blank">arrange a hackfest</a>, which took place last week at the Red Hat offices in Mexico city. The event was a big success in my opinion. The actual work done and started during the hackfest aside, it brought two communities much closer together and we learnt quite a lot from each other in a very short amount of time. The main topics at the hackfest were:<br />
<ul style="text-align: left;"><li>GObject-introspection consumption by Rust.</li>
<li>GObject creation from Rust.</li>
<li>Better out of the box Rust support in GNOME Builder</li>
<li>GMainLoop and Tokio integration</li>
<li>D-Bus bindings</li>
</ul><div>While most folks were focused on the first three and I did participate in discussions on all these topics (except for Builder, of which I don't know anything), I spent most of my time looking into the last one. D-Bus is widely used in automotive industry these days and I serve that industry these days so it made sense, aside from my person interest in D-Bus. We established (some of it before the hackfest) that to make Rust attractive to C and Vala developers, we need to provide:</div><div><div style="text-align: left;"></div><ol style="text-align: left;"><li><b>Syntactic sugar for making D-Bus coding simple</b><br />
<br />
Very similar to <a href="https://chebizarro.gitbooks.io/the-vala-tutorial/content/d-bus-integration.html" target="_blank">what Vala offers</a>. Antoni already had a project, <a href="https://github.com/antoyo/dbus-macros-rs/" target="_blank">dbus-macros</a> that targets this goal through the use of Rust's (powerful) macro system. So I spent a lot of time fixing and improving dbus-macros crate. Having Antoni and other Rust experts in the same room, greatly helped me get around some very hard to decipher compiler issues. I found out (the hard way) that while rustc is very good at spotting errors, it fails miserably to give you the proper context when it comes to macros. I complained enough about this to Mozilla folks that I'm sure they'll be looking into fixing that experience at some point in near future. :)<br />
<br />
We also contacted the author of dbus crate, David Henningsson over e-mail about a few D-Bus related subjects (more below) including this one. (I was surprised to find out that he also lives in Sweden). His opinion was that we probably should be using procedural macros for this. I agree with him, except that procedural macros are not yet in stable Rust. So for now, I decided to continue with current approach of the project.<br />
<br />
During the hackfest, I became the maintainer of the dbus-macros crate since the first thing I did was to reduce the very small amount of code by 70%. Next, I created <a href="https://github.com/antoyo/dbus-macros-rs/issues?utf8=%E2%9C%93&q=is%3Aissue%20author%3Azeenix%20" target="_blank">a backlog</a> for myself and worked my way through it one issue at a time. I'm going to continue with that.</li><br>
<li><b>Asynchronous D-Bus methods</b><br />
<br />
While ability to make D-Bus method calls asynchronously from clients is very important (you don't want to block the UI for your IPC), it would be also very nice for services to be able to asynchronously handle method calls as well. Brian Anderson from Mozilla was working on this during the hackfest. His approach was to hack dbus crate to add async API through the use of <a href="https://github.com/tokio-rs/tokio">tokio crate</a>. I spent most of the second day of hackfest, sitting next to Brian for some peer-programming. The author of tokio, Alex Crichton, sitting next to us helped us a lot in understanding tokio API. In the end, Brian <a href="https://github.com/diwic/dbus-rs/issues/72#issuecomment-290581407" target="_blank">submitted a working proof of concept</a> for client-side async calls, which will hopefully provide a very good bases for David's actual implementation.</li><br>
<li><b>Code generation from D-Bus introspection XML</b><br />
<br />
With both GLib and Qt providing utilities to generate code for handling D-Bus for a decade now, most projects doing D-Bus make use of this. My intention was too look into this during the hackfest but just before, I found out that David had not only already <a href="https://github.com/diwic/dbus-rs/tree/master/codegen/dbus-codegen" target="_blank">started this work</a> in dbus crate but also his approach is exactly what I'd have gone for. So while I decided not to work on this, I did have lengthy (electronic) conversations with David about how to consolidate code generation with dbus-macros.<br />
<br />
Ideally, the API of the generated code should be very similar to one you'd manually create using dbus-macros to make it easy for developers to switch from one approach to another. But since David and I didn't agree with current dbus-macros approach, I kind of gave-up on this goal, at least for now. Once macro procedures stabilize, there is a good chance we will change dbus-macros (though it'll be a completely new version or maybe even a different crate) to make use of them and we can revisit consolidation of code generation and dbus-macros.</li>
</ol>A few weeks prior to the event, I decided to create a new project, <a href="https://github.com/zeenix/gps-share" target="_blank">gps-share</a>. The aim is to provide ability to share your (standalone) GPS device from your laptop/desktop to other devices on the network and at the same time add standalone GPS device support into Geoclue (without any new feature code in Geoclue). I decided to write it in Rust for a few reasons, one of them being my desire to learn enough about the language before the event (I hadn't wrote any serious/complicated code in Rust before) and another one was to have an actual test case for D-Bus adventures (it's supposed to talk to Avahi on D-Bus). I'm glad that I did that since I encountered a few issues with dbus-macros when using them in gps-share and the awesome Mozilla folks were able to help me figure them out very quickly. Otherwise it would have taken me a very long time to figure the issues.</div><br />
<br />
<div class="separator" style="clear: both; text-align: center;"><a href="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEgCJ-CqcpeL80fFTQIOWnaKJiJkTUaAigKBUHoLia8fbDBFypHGMdX96eyjRwiXWUdm2rPFSCfTKRAgDBz1b74xHy2Y2VT0haKsWOGAfp31tm2BUqvisdEOpVXEMp2TVdVf9YDFPTOMjRyo/s1600/20170331_165241.jpg" imageanchor="1" style="margin-left: 1em; margin-right: 1em;"><img border="0" height="240" src="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEgCJ-CqcpeL80fFTQIOWnaKJiJkTUaAigKBUHoLia8fbDBFypHGMdX96eyjRwiXWUdm2rPFSCfTKRAgDBz1b74xHy2Y2VT0haKsWOGAfp31tm2BUqvisdEOpVXEMp2TVdVf9YDFPTOMjRyo/s320/20170331_165241.jpg" width="320" /></a></div><br />
<br />
On the last day of hackfest, after a delicious lunch, we decided to go for a long stroll around Mexico city and hang out in the park, where we had more interesting conversations, about life, universe and everything (including Rust and GNOME).<br />
<br />
After the hackfest, I stayed around for 3 more days. On Saturday, I mostly hung out with Federico, Christian, Antoni and Joaquín. We walked around the city center and watched Federico and Joaquín interviewed by <a href="http://ranchoelectronico.org/" target="_blank">Rancho Electronico</a> folks. I was really excited to see that they use GNOME for their desktop and GStreamer for streaming. The guy handling the streaming was very glad to meet someone with GStreamer experience.<br />
<br />
On Sunday, I rented a car and went to a hike at Tepoztlán with Felipe. Driving in Mexico wasn't easy so having a Mexican with me, helped a lot.<br />
<br />
<div class="separator" style="clear: both; text-align: center;"><a href="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEjRP6XDC7NPSr8ZEEKi1CLp1zyD3joPjJMl8ZpqdQpLpEMlVr2YCIT-8R5ssWTb6N0IxE-AJVu2CAQC1ZSMZV-PQFFEJ8aGCpATXoPoStHHBC1bFdBDZAJlAFv0tPhOFLaRdCUjhsrzwq12/s1600/17523337_10158437611145082_2668094992568542965_n.jpg" imageanchor="1" style="margin-left: 1em; margin-right: 1em;"><img border="0" height="240" src="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEjRP6XDC7NPSr8ZEEKi1CLp1zyD3joPjJMl8ZpqdQpLpEMlVr2YCIT-8R5ssWTb6N0IxE-AJVu2CAQC1ZSMZV-PQFFEJ8aGCpATXoPoStHHBC1bFdBDZAJlAFv0tPhOFLaRdCUjhsrzwq12/s320/17523337_10158437611145082_2668094992568542965_n.jpg" width="320" /></a></div><br />
And on Monday, we drove to the Sun pyramid.<br />
<br />
<div class="separator" style="clear: both; text-align: center;"><a href="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEhysuVuGx9PyhUpJAD5FCIhTbczH5L23jNkGSLF1FwlkQEGXiGk3olwWoy5Os4E53L7HxFKaR0hrxN2ALeWM7gyUUYTMfsxVAuMuVOCX9XA3NV5SIO7LZvCoHArEFwVp99P4DgWAVeT6A98/s1600/542967_10158437603795082_1362408176168821917_n.jpg" imageanchor="1" style="margin-left: 1em; margin-right: 1em;"><img border="0" height="240" src="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEhysuVuGx9PyhUpJAD5FCIhTbczH5L23jNkGSLF1FwlkQEGXiGk3olwWoy5Os4E53L7HxFKaR0hrxN2ALeWM7gyUUYTMfsxVAuMuVOCX9XA3NV5SIO7LZvCoHArEFwVp99P4DgWAVeT6A98/s320/542967_10158437603795082_1362408176168821917_n.jpg" width="320" /></a></div><br />
I would like to thank both GNOME Foundation and my employer, Pelagicore for sponsoring my participation to this event.<br />
<br />
<div class="separator" style="clear: both; text-align: center;"><img border="0" height="200" src="https://wiki.gnome.org/Travel/Policy?action=AttachFile&do=get&target=sponsored-badge-shadow.png" width="200" /><a href="http://www.pelagicore.com/" target="_blank"><img border="0" height="200" src="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEj0Mq10yJqyHpnZdVLY33jkLxGo8Ks28GzpnJlkPQYonTJ5Xa-UTfoOC1Ua9g5jEE0V6r-rIgSXGTOyrlV9igtS_sA7gDJrQNWCLJ-nXZbHFl8NOm_OaImt1U_aGk_HfryhtsbfFT2Wzoiu/s200/PELAGICORE_RGB_Black_vertical.png" width="170" /></a></div><br />
</div></div>zeenixhttp://www.blogger.com/profile/04142631863736897222noreply@blogger.com0tag:blogger.com,1999:blog-3575421168816814786.post-67332769263110449072017-03-07T10:11:00.000-08:002017-03-07T10:11:57.284-08:00GDP meets GSoC<div dir="ltr" style="text-align: left;" trbidi="on">
Are you a student? Passionate about Open Source? Want your code to run on next generation of automobiles? You're in luck! <a href="https://at.projects.genivi.org/wiki/pages/viewpage.action?pageId=11567210" target="_blank">Genivi Development Platform</a> will be participating in <a href="https://developers.google.com/open-source/gsoc/" target="_blank">Google Summer of Code</a> this summer and you are welcome to participate. We have <a href="https://at.projects.genivi.org/wiki/display/GDP/GDP+GSoC+ideas" target="_blank">collected a bunch of ideas</a> for what would be a good 3 month project for a student but you're more than welcome to suggest your own project. The <a href="https://at.projects.genivi.org/wiki/display/GDP/GDP+GSoC+ideas" target="_blank">ideas page</a>, also has instructions on how to get started with GDP.<br />
<br />
We look forward to your participation!</div>
zeenixhttp://www.blogger.com/profile/04142631863736897222noreply@blogger.com0tag:blogger.com,1999:blog-3575421168816814786.post-48249555036060407522016-08-10T06:24:00.000-07:002016-08-10T06:25:42.348-07:00Life is change<div dir="ltr" style="text-align: left;" trbidi="on">
Quite a few major life events happened/happening this summer so I thought I blog about them and some of the experiences I had.<br />
<h3 style="text-align: left;">
New job & new city/country</h3>
Yes, I found it hard to believe too that I'll ever be leaving Red Hat and the best manager I ever had (no offence to others but competing with Matthias is just impossible) but I'll be moving to Gothenburg to join Pelagicore folks as a Software Architect in just 2 weeks. I have always found Swedish language to be a very cute language so looking forward to my attempt of learning Swedish. If only I had learnt Swedish rather than Finnish when I was in Finland.<br />
<br />
BTW, I'm selling all my furniture so if you're in London and need some furniture, get in touch!<br />
<br />
<h3 style="text-align: left;">
Fresh helicopter pilot</h3>
<div>
So after two years of hard work and getting myself sinking in bank loans, I finally did it! Last week, I passed the skills test for Private Pilot License (Helicopters) and currently awaiting anxiously for my license to come through (it usually takes at least two weeks). Once I have that, I can rent Helicopters and take passengers with me. I'll be able to share the costs with passengers but I'm not allowed to make money out of it. The test was very tough and I came very close to failing at one particular point. The good news is that despite me being very tense and very windy conditions on test day, the biggest negative point from my examiner was that I was being over-cautious and hence very slow. So I think it wasn't so bad.</div>
<div>
<br /></div>
<div class="separator" style="clear: both; text-align: center;">
<a href="https://4.bp.blogspot.com/-h-ktTxVwAQ0/V6IanFrvlII/AAAAAAAAKAg/8mmJpLgCD14EgcQKjBw2xO7onoOiQy8gwCPcB/s1600/2016%2B-%2B1" imageanchor="1" style="margin-left: 1em; margin-right: 1em;"><img border="0" height="320" src="https://4.bp.blogspot.com/-h-ktTxVwAQ0/V6IanFrvlII/AAAAAAAAKAg/8mmJpLgCD14EgcQKjBw2xO7onoOiQy8gwCPcB/s320/2016%2B-%2B1" width="240" /></a></div>
<div>
<br />
<br />
There are a few differences to a driving test. A minor one is is that in driving test, you are not expected to explain your steps but simply execute, where as in skills test for flying, you're expected to think everything out loud. But the most major difference is that in driving test, you are not expected to drive on your own until you pass the test, where as in flying test, you are required to have flown solo for at least 10 hours, which needs to include a solo cross country flight of at least a 100 nautical miles (185 KM) involving 3 major aeorodromes. Mine involved Estree, Cranfield and Duxford. I've been GPS logging while flying so I can show you log of my qualifying solo cross country flight (click <a href="https://www.google.com/maps/d/u/0/edit?hl=en&authuser=0&mid=1_XsY9ju__4rEcAw9U6N7G2vlgKE" target="_blank">here</a> to see details and notes):<br />
<br /></div>
<div class="separator" style="clear: both; text-align: center;">
<img border="0" height="218" src="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEi2gmjsC5d3zKrbePsvhp3VF8xfcDYe6zTXmhZnKoz1TartCCtnpveeJV_5MAMtXMHow7sU7bCgU6djGXIp_x-IN1PUfTXT-tM-5i-75bwHRg32DYAdQgjK91vxoX2dZfpid_OKIv244K21/s400/Screenshot+from+2016-08-10+14-06-17.png" width="400" /></div>
<div>
<br /></div>
<div>
<br /></div>
<div>
I still got a long way towards Commercial License but at least now I can share the price with friends so building hours towards commercial license, won't be so expensive (I hope). I've found a <a href="http://www.nheli.se/" target="_blank">nice company in Gothenburg</a> that trains in and rents helicopters so I'm very much looking forward to flying over the costs in there. Wanna join? Let me know. :)</div>
</div>
zeenixhttp://www.blogger.com/profile/04142631863736897222noreply@blogger.com0tag:blogger.com,1999:blog-3575421168816814786.post-5862024533690516802016-02-05T09:19:00.002-08:002016-02-05T09:19:33.915-08:00FOSDEM & Dev-x Hackfest 2016<div dir="ltr" style="text-align: left;" trbidi="on">
Last week I travelled to Brussels to attend and present at <a href="https://fosdem.org/2016/" target="_blank">FOSDEM</a>. Since I was going there anyway, I decided to also join 2.5 days of <a href="https://wiki.gnome.org/Hackfests/DeveloperExperience2016" target="_blank">GNOME Developer Experience Hackfest</a>.<br />
<br />
Travelling to Brussels is usually pretty easy and fast, thanks to Eurostar but I turned it into a bit of nightmare this time. I had completely forgotten how London public transport is a total disasters in peak hours and hence ended-up arriving too late at the station. Not a big deal, they put me on the next train for free. I decided to go through security already and that's when I realized that I have forgotten my laptop at home. :( Fortunately my nephew (who is also my flatmate) was still at home and was going to travel to city centre anyway so I asked him to bring it with him. After two hours of anxiously waiting, he managed to arrive just in time for train staff to let in the very last late arriving passenger. Phew!<br />
<br />
While I didn't have a particular agenda for the hackfest, I had a discussion with Alexander Larsson about <a href="https://wiki.gnome.org/Projects/SandboxedApps" target="_blank">sandboxing</a> in xdg-app and how we will implement per-app authorization to location information from Geoclue. The main problem has always been that we have no means of reliably identifying apps and turns out that xdg-app already solved that problem. Each xdg-app has it's ID (i-e the name of it's desktop file w/o the .desktop suffix) in /proc/PID/cgroup file and app can not change that.<br />
<br />
So I sat down and started working on this. I was able to finish off the Geoclue part of the solution already before the hackfest ended and now working on gnome-shell (currently the only geoclue app authorizing agent) part. Once done I'll then add settings in gnome-control-center so users can change their mind about whether or not they want an app to be able to access their location. Other than that, I helped test a few xdg-app bundles.<br />
<br />
It's important to keep in mind that this solution will still involve trusting the system (non-xdg-app) application as there is no way to reliably identify those. i-e if you download a random script from internet and run it, we can not possibly guarantee that it won't access your location without your consent. Let's hope that xdg-app becomes very ubiquitous and becomes a de-facto standard for distributing your Linux apps in the near future.<br />
<br />
FOSDEM was a fun weekend as usual. I didn't attend a lot of talks but met many interesting people and we had chat about various different open source technologies. I was glad to hear that a <a href="http://zee-nix.blogspot.co.uk/2008/10/rygel-gnome-upnp-media-server.html" target="_blank">project I started off as a simple proof-of-concept</a> for GUPnP, is now a days used in automobiles.<br />
<br />
My own talk about Geospacial technologies in GNOME went fine except for the fact that I ran out of time towards the end and my <a href="https://github.com/zeenix/rasp-led-weather" target="_blank">Raspberry Pi demo</a> didn't work because I forgot to plug-in the WiFi adaptor. :( Still, I was able to cover most of the topics and <a href="https://wiki.gnome.org/Apps/Maps" target="_blank">Maps</a> demo worked pretty smoothly (there was weird libchamplain bug I hit but it wasn't very critical at all).<br />
<br />
While I came back home pumped with a lot of motivation, unfortunately I managed to catch the infamous FOSDEM flu. I've been resting most of the week and today I started to feel better so I'm writing this late blog post as the first thing, before I completely forget what happened last week.<br />
<br />
Oh and last but not the least, many thanks to GNOME foundation for sponsoring my train tickets.<br />
<br />
<div class="separator" style="clear: both; text-align: center;">
<a href="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEhzFM5Vf-VYHtz5uC4d8ZImAqs8ZWOPFdys8R3TiyHKLpm5Hn8CUwsQrtufAysTxsTHtsjD4gmzNXyn0HwBe2715tzX_U9BrgaI-gOct87KBU17YqZYQpWm4lSFii2Kxu6YYoWREe5Yi3oJ/s1600/sponsored-badge-shadow.png" imageanchor="1" style="margin-left: 1em; margin-right: 1em;"><img border="0" src="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEhzFM5Vf-VYHtz5uC4d8ZImAqs8ZWOPFdys8R3TiyHKLpm5Hn8CUwsQrtufAysTxsTHtsjD4gmzNXyn0HwBe2715tzX_U9BrgaI-gOct87KBU17YqZYQpWm4lSFii2Kxu6YYoWREe5Yi3oJ/s1600/sponsored-badge-shadow.png" /></a></div>
<br /></div>
zeenixhttp://www.blogger.com/profile/04142631863736897222noreply@blogger.com0tag:blogger.com,1999:blog-3575421168816814786.post-35248287998236496372015-10-19T04:00:00.000-07:002015-10-19T04:00:04.820-07:00Lessons on being a good maintainer<div dir="ltr" style="text-align: left;" trbidi="on">
<div>
What makes for a good maintainer? Although I do not know of a definite answer to this important but vague and controversial question, maintaining various free software projects over the last many years, I've been learning some lessons on how to strive to be a good maintainer; some self-taught through experience, some from my colleagues (especially our awesome GNOME designers) and some from my GSoC students.<br />
<br />
I wanted to share these lessons with everyone so I arranged a small BoF at <a href="https://2015.guadec.org/" target="_blank">GUADEC</a> and thought it would be nice to share it on planet GNOME as well. Some points only apply to UIs here, some only to libraries (or D-Bus
service or anything with a public API really) and some to any kind of
project. Here goes: <br />
<h2 style="text-align: left;">
Only accept use cases</h2>
<div style="text-align: left;">
There are no valid feature requests without a proper use case behind them. What's a proper use case you ask? In my opinion, it's based on what the user needs, rather than what they desire or think they need. "I want a button X that does Y" is not a use case, let alone a proper one. "I need to accomplish X" is potentially one.</div>
<div style="text-align: left;">
<br /></div>
<div style="text-align: left;">
Even when given a proper use case, does not necessarily mean that you should implement it. You still need to consider the following points before deciding to accept the feature request:</div>
<ul style="text-align: left;">
<li>How many users do you think this impacts?</li>
<li>What's the impact of having this feature to user?</li>
<li>What's the impact on users that do not need that feature?</li>
<li>How does the expected number of users who need this feature compare to ones that do not. </li>
<li>How much work do you think this will be and do you think you (or anyone else in the team) will have the time and motivation to implement it?</li>
</ul>
<ul style="text-align: left;">
</ul>
</div>
<h2 style="text-align: left;">
Get a thicker skin</h2>
<div style="text-align: left;">
Everyone wants software to be tailored for them so unless you have only a few users of your software, you can not possibly satisfy all users. Sometimes users even demand contradictory features so if you are going to be a slave of user demands, you'll not last very long and your software will soon look like my bedroom: random stuff in random places and hard to find what you are looking for.<br />
<br />
So don't be afraid of WONTFIX bug resolution. I do agree that this sounds harsh but I think the most important thing is to be honest with your users and not to give them false hopes.</div>
<h2 style="text-align: left;">
A good API maintainer is a slave of apps</h2>
<div style="text-align: left;">
Your library or D-Bus service is as useful and important as the applications that use it. Never forget that while making decisions about public APIs.</div>
<div style="text-align: left;">
<br /></div>
<div style="text-align: left;">
Furthermore, if possible, try your best to be involved in at least one of the applications that use your API. Even better if you'd be maintaining one such application. There has been a few occasions where I had to had long debates with library developers about how their API could do much better and I felt that the debate could have been avoided if they had more insights about the applications that use their API. Also, they'd likely care more if they'd experience the pain of the problematic part of their API first hand. </div>
<h2 style="text-align: left;">
History is important!</h2>
<div style="text-align: left;">
VCS (which translates to git for most of us these days) history, that is. I think this is something most developers would readily agree on and some readers must be thinking why do I need to even mention this. However, I've seen that while many would agree in principle to this, in practice they don't care too much. I've seen so many projects out there, where it's very hard or even impossible to find out why a particular line of code was changed in a particular way. Not only it makes maintenance hard, but also discourages new contributors since they'd not feel confident about changing an LOC if they can't be sure why it's how it is and not already what they think it should be like.</div>
<div style="text-align: left;">
<br /></div>
<div style="text-align: left;">
So kids, please try to follow some sane commit log rules. We have some <a href="https://wiki.gnome.org/Git/CommitMessages" target="_blank">here</a> and Lasse has created an extensive version of that document with rationale for each point, for his project <a href="http://coala.readthedocs.org/en/latest/Getting_Involved/Writing_Good_Commits/" target="_blank">here</a>. </div>
<h2 style="text-align: left;">
Quality of code</h2>
<div style="text-align: left;">
This is a bit related to the previous point. To be very honest, if you don't care about quality enough, you really should not be even working on software that effects others, let alone maintaining them.</div>
<div style="text-align: left;">
<br /></div>
<div style="text-align: left;">
How successful you are at maintaining high quality is another thing, and sometimes even not in your hands entirely, but you should always strive for highest quality. The two most important sub-goals in that direction in my opinion, are: </div>
<h3>
Simplicity</h3>
<div style="text-align: left;">
[Insert cliché Einstein quote about simple solutions here.] Each time you come up with a solution (or receive one in the form of patches), ask yourself how it can be done with fewer lines of code. The fewer lines of code you have, the fewer lines of code you'd need to maintain. </div>
<h3 style="text-align: left;">
Consistency</h3>
<div style="text-align: left;">
Come up with a (or adopt an existing) coding style with specific set of rules to follow and try your very best to follow them. Many contributors would simply dive directly into your project's source code and not read any coding style manual you provide and there is nothing wrong with that. If you are consistent in your code, they'll figure out at least most of your coding style while hacking on your sources. Also chances are that your coding style would even grow on them and that'll save you a lot of time during your reviews of their patches. That's unlikely to happen if you are not very consistent with your coding style. </div>
<h2 style="text-align: left;">
Conclusion</h2>
<div style="text-align: left;">
None, what so ever. Do what you think is right. This blog post is nothing more than my personal opinions so take it or leave it, it's all up to you!</div>
</div>
zeenixhttp://www.blogger.com/profile/04142631863736897222noreply@blogger.com0tag:blogger.com,1999:blog-3575421168816814786.post-89039359697618244282015-10-14T10:30:00.001-07:002015-10-15T09:45:46.045-07:00Geoclue convenience library just got even simpler<div dir="ltr" style="text-align: left;" trbidi="on"><div dir="ltr" style="text-align: left;" trbidi="on">After <a href="http://zee-nix.blogspot.co.uk/2015/10/new-in-geoclue-location-sharing.html" target="_blank">writing the blog post about the new Geoclue convenience library</a>, I felt that while the helper API was really simple for single-shot usage, it still wasn't as simple as it should be for most applications, that would need to monitor location updates. They'll still need to make async calls (they could do it synchronously too but that is hardly ever a good idea) to create proxy for location objects on location updates.<br />
<br />
So yesterday, I came up with <a href="http://www.freedesktop.org/software/geoclue/docs/libgeoclue/GClueSimple.html" target="_blank">even simpler API</a> that should make interacting with Geoclue as simple as possible. I'll demonstrate through some gjs code that simply awaits for location updates forever and prints the location on console each time there is a location update:<br />
<br />
</div><pre>const Geoclue = imports.gi.Geoclue;
const MainLoop = imports.mainloop;
let onLocationUpdated = function(simple) {
let location = simple.get_location ();
print("Location: " +
location.latitude + "," +
location.longitude);
};
let onSimpleReady = function(object, result) {
let simple = Geoclue.Simple.new_finish (result);
simple.connect("notify::location", onLocationUpdated);
onLocationUpdated (simple);
};
Geoclue.Simple.new ("geoclue-where-am-i", /* Let's cheat */
Geoclue.AccuracyLevel.EXACT,
null,
onSimpleReady);
MainLoop.run('');
</pre><br />
Yup, that easy! If I had chosen to use the synchronous API, it would be even simpler. I have already <a href="https://bugzilla.gnome.org/show_bug.cgi?id=756580" target="_blank">provided a patch</a> for Maps to take advantage of this and I'm planning to provide patches for other apps too.</div>zeenixhttp://www.blogger.com/profile/04142631863736897222noreply@blogger.com0tag:blogger.com,1999:blog-3575421168816814786.post-90024087645123695272015-10-09T12:45:00.000-07:002015-10-09T12:45:19.102-07:00New in Geoclue: Location sharing & convenience library<div dir="ltr" style="text-align: left;" trbidi="on">
Apart from many fixes, <a href="http://geoclue.freedesktop.org/" target="_blank">Geoclue</a> recently gained some new features as well.<br />
<br />
<h2 style="text-align: left;">
Sharing location from phones</h2>
<div style="text-align: left;">
If you read <a href="https://planet.gnome.org/" target="_blank">planet GNOME</a>, you must have seen my <a href="https://developers.google.com/open-source/gsoc/" target="_blank">GSoC</a> student, Ankit already <a href="http://codeankit.me/" target="_blank">posting about this</a>. Basically his work enabled Geoclue to search for, and make use of any <a href="http://www.gpsinformation.org/dale/nmea.htm" target="_blank">NMEA</a> providers on the local network. The second part of this project, involved implementation of such a service for Android devices. I'm pleased that he managed to get the project working in time and even went the extra mile to fix issues with his code, after GSoC.</div>
<div style="text-align: left;">
<br /></div>
<div style="text-align: left;">
This is useful since GPS-based location from android is almost always going to be more accurate than WiFi-based one (assuming neighbouring WiFi networks are covered by <a href="https://location.services.mozilla.com/" target="_blank">Mozilla Location Service</a>). This is especially useful for desktop machines since they typically do not have even WiFi hardware on them and have until now been limited to GeoIP, which at best gives city-level accurate location.</div>
<div style="text-align: left;">
<br /></div>
<div style="text-align: left;">
This feature was included in release <a href="http://www.freedesktop.org/software/geoclue/releases/2.3/" target="_blank">2.3.0</a> and you can download the Android app from <a href="https://github.com/ankitstarski/GeoclueShare/releases" target="_blank">here</a>.</div>
<div style="text-align: left;">
<br /></div>
<h2 style="text-align: left;">
Conveniece library</h2>
<div style="text-align: left;">
Almost since the beginning of Geoclue2 project, many people <a href="https://bugs.freedesktop.org/show_bug.cgi?id=68658" target="_blank">complained</a> that using the new API is far from easy and simple, as it should be. While we have good reasons to keep D-Bus API as it is now, the fact that a lot of time passed since I got around to doing anything about this, meant that it was best if D-Bus API was not changed, Geoclue being a system service.</div>
<div style="text-align: left;">
<br /></div>
<div style="text-align: left;">
So this week, I took up the task of implementing a client-side library, that not only exposes gdbus-codegen generated API to communicate with the service but also added a convenience <a href="http://www.freedesktop.org/software/geoclue/docs/libgeoclue/libgeoclue-Geoclue-convenience-API.html" target="_blank">helper API</a> to make things <a href="http://cgit.freedesktop.org/geoclue/commit/?id=c9ef691d1756b17d3456f230818aba642c521b98" target="_blank">very simple</a>. Basically, you just have to call a few functions now if you simply want to get a location fix quickly and don't care much about accuracy nor interested in subsequent location updates.</div>
<div style="text-align: left;">
<br /></div>
<div style="text-align: left;">
I only pushed the changes today to git master so if you have any input, now would be the best time to speak up. I wouldn't want to change API after release.</div>
</div>
zeenixhttp://www.blogger.com/profile/04142631863736897222noreply@blogger.com0tag:blogger.com,1999:blog-3575421168816814786.post-33335201681597707952014-10-10T10:53:00.000-07:002014-10-10T11:09:31.465-07:00Life update<div dir="ltr" style="text-align: left;" trbidi="on">
Like many others on planet.gnome, it seems I also don't feel like posting much on my blog any more since I post almost all major events of my life on social media (or SOME, as its for some reason now known as in Finland). To be honest, the thought usually doesn't even occur to me anymore. :( Well, anyway! Here is a brief of what's been up for the last many months:<br />
<ul style="text-align: left;">
<li>Got divorced. Yeah, not nice at all but life goes on! At least I got to keep my lovely cat.<br /><br /><a href="http://4.bp.blogspot.com/-0UgyZZXrlGI/VBa6r6qezNI/AAAAAAAAGgw/uqwLUSCLIMA/s1600/20140915_104131.jpg" style="margin-left: 1em; margin-right: 1em;"><img border="0" src="http://4.bp.blogspot.com/-0UgyZZXrlGI/VBa6r6qezNI/AAAAAAAAGgw/uqwLUSCLIMA/s1600/20140915_104131.jpg" height="180" width="320" /></a></li>
<li>Its been almost an year (14 days less) that I moved to London. In a way it was good that I was in a new city at the time of divorce as its an opportunity to start a new life. I made some cool new friends, mostly the GNOME gang in here.<br /><br />London has its quirks but over all I'm pretty happy to be living here. One big issue is that most of my friends are in Finland so I miss them very much. Hopefully, in time I'll also make a lot more friends in London and also my friends from Finland will visit me too.<br /><br />The best thing about London is the weather! No, I'm not joking at all. Not only its a big improvement when compared to Helsinki, the rumours about "Its always raining in London" are greatly (I can't stress on this word enough) exaggerated.</li>
<li>I got my eyes Z-LASIK'ed so no more glasses!<br /><br /> </li>
<li>Started taking:<br /><br /><ul>
<li>Driving lessons. Failed the first driving test today. Having known what I did wrong, I'm sure I wont repeat the same mistakes again next time and will pass.</li>
<li>Helicopter flying lessons. Yes! I'm not joking. I grew up watching Airwolf and ever since then I've been fascinated by helicopters and wanted to fly them but never got around to doing it. Its very expensive, as you'd imagine so I'm only taking two lessons a month. With this pace, I should be have my PPL(H) by end of 2015.<br /><br />Turns out that I'm very good at one thing that most people find very challenging to master: Hovering. The rest isn't hard either in practice. Theory is the biggest challenge for me. <a href="https://www.youtube.com/watch?v=YaPLsEIji74" target="_blank">Here is the video recording</a> of the 15 mins trial lesson I started with.</li>
</ul>
<div class="separator" style="clear: both; text-align: center;">
<a href="http://3.bp.blogspot.com/-T8Lssb4vBzk/U3aC_X5CTqI/AAAAAAAAF4M/H-CSw7Q_lvM/s1600/P1070729%2Bemail%2Bto%2BZeeshan.JPG" imageanchor="1" style="margin-left: 1em; margin-right: 1em;"><br /><img border="0" src="http://3.bp.blogspot.com/-T8Lssb4vBzk/U3aC_X5CTqI/AAAAAAAAF4M/H-CSw7Q_lvM/s1600/P1070729%2Bemail%2Bto%2BZeeshan.JPG" height="240" width="320" /></a></div>
</li>
</ul>
</div>
zeenixhttp://www.blogger.com/profile/04142631863736897222noreply@blogger.com4tag:blogger.com,1999:blog-3575421168816814786.post-54838693409388587182014-07-21T16:12:00.000-07:002014-07-21T16:12:07.288-07:00GUADEC<div dir="ltr" style="text-align: left;" trbidi="on">
So its that time of the year! <a href="https://www.guadec.org/" target="_blank">GUADEC</a> is always loads of fun and meeting all those the awesome GNOME contributors in person and listening to their exciting stories and ideas gives me a renewed sense of motivation.<br /><br />I have two regular talks this year:<br />
<ul style="text-align: left;">
<li>Boxes: All packed & ready to go?</li>
<li>Geo-aware OS: Are we there yet?</li>
</ul>
Apart from that I also intend to present a lightning talk titled "Examples to follow". This talk will present stories of few of our awesome GNOME contributors and what we all can learn from them.<br />
<br />
<div class="separator" style="clear: both; text-align: center;">
<a href="https://www.guadec.org/wp-content/uploads/2014/07/guadec-2014-badge-large.png" imageanchor="1" style="margin-left: 1em; margin-right: 1em;"><img border="0" src="https://www.guadec.org/wp-content/uploads/2014/07/guadec-2014-badge-large.png" /></a></div>
<br /></div>
zeenixhttp://www.blogger.com/profile/04142631863736897222noreply@blogger.com0tag:blogger.com,1999:blog-3575421168816814786.post-57162167154111403322014-06-23T17:28:00.000-07:002014-06-23T17:28:43.073-07:00oFono? Its dead jim!<div dir="ltr" style="text-align: left;" trbidi="on">Soon after I mentioned the need for an <a href="https://ofono.org/" target="_blank">oFono</a>-backend in <a href="http://www.freedesktop.org/wiki/Software/GeoClue/" target="_blank">Geoclue</a> in <a href="http://zee-nix.blogspot.co.uk/2014/05/location-hackfest-2014-report.html" target="_blank">my blog</a>, <a href="http://blogs.gnome.org/sri/" target="_blank">Sri</a> kindly helped me get in touch with oFono developers. What started as a nice friendly discussion soon was turned into a not so nice discussion. I won't get into details and blames but here is what I found out about the project:<br />
<br />
<ul style="text-align: left;"><li> oFono developers claim that its is still a maintained project while rest of the world think its a dead project, even people who love the project. Last release being in 2012 and loads of missing essential features (see rest of the points below) and link to <a href="https://lists.ofono.org/listinfo/ofono" target="_blank">mailing-list broken</a> (even though I pointed it out 3 weeks ago and its been broken for much longer) on the homepage all points to the fact that its essentially a dead project.<br />
<br />
<div class="separator" style="clear: both; text-align: center;"><a href="http://millicentmedia.files.wordpress.com/2011/10/dead-parrot-1.png" imageanchor="1" style="margin-left: 1em; margin-right: 1em;"><img border="0" src="http://millicentmedia.files.wordpress.com/2011/10/dead-parrot-1.png" height="180" width="320" /></a></div></li>
<li>No proper D-Bus introspection nor any client libraries. This already makes it extremely difficult to work with oFono but wait there is more hurdles on the way.<br />
</li><br>
<li>No online cross-references documentation: The <a href="https://ofono.org/documentation" target="_blank">documentation link on the home-page</a> leads you to an architecture diagram and gives you no information about the API. Searching through google doesn't yield any results either. The developers pointed out that all documentation lives in the source tree in the form of plain-text documents and hence not very appropriate for the web.<br />
</li><br>
<li>It does not implement the standard <a href="http://dbus.freedesktop.org/doc/dbus-specification.html#standard-interfaces-properties" target="_blank">D-Bus Properties interface</a>. This combined with the fact that their D-Bus API is heavily based on properties makes it yet even harder to work with OFono, not to mention very weird.<br />
</li><br>
<li>None of the modern 3G modems supported, at least out of the box. I tried both Option and Qualcomm Gobi that I have and they both didn't work.</li><br>
</ul><br />
While rest of the issues can be overcome, the last makes it impossible for me to test any code written against oFono. So I'm giving up on this.<br />
<br />
With a nice <a href="http://www.freedesktop.org/wiki/Software/ModemManager/" target="_blank">alternative that is well-maintained</a>, and with which most modems work out of the box, has a <a href="http://www.freedesktop.org/software/ModemManager/api/latest/" target="_blank">nice OO, well-documented and introspectable D-Bus API</a> and also provides a <a href="http://www.freedesktop.org/software/ModemManager/libmm-glib/latest/" target="_blank">nice client library</a>, I don't understand why phone vendors insist on supporting oFono interface. Could it be because the name makes it sound like its *the* solution for phones? Well, they do have the right to use whatever they like. I'm just curious.<br />
<br />
Having said all that, I <a href="http://cgit.freedesktop.org/geoclue/commit/?id=c84a0972058de25e2a4eb987458f31317bcf47a6" target="_blank">did make it easy for anyone to add oFono support to Geoclue</a> as promised in <a href="http://zee-nix.blogspot.co.uk/2014/05/location-hackfest-2014-report.html" target="_blank">my last blog post</a>. Patches to add that are more than welcome!</div>zeenixhttp://www.blogger.com/profile/04142631863736897222noreply@blogger.com5tag:blogger.com,1999:blog-3575421168816814786.post-24344292290553845862014-05-28T04:57:00.000-07:002014-05-28T04:58:39.653-07:00Location hackfest 2014 report<div dir="ltr" style="text-align: left;" trbidi="on"><div><div>So the <a href="https://wiki.gnome.org/Hackfests/Location2014" target="_blank">Location hackfest 2014</a> took place at the awesome <a href="https://wiki.mozilla.org/London" target="_blank">Mozilla offices</a> in London during last weekend. Even though some of the important participants didn't manage to be physically present, enough people did:<br />
<ul style="text-align: left;"><li>John Layt (KDE)</li>
<li>Hanno Schlichting (Mozilla)</li>
<li>Mattias Bengtsson (GNOME)</li>
<li>Jonas Danielsson (GNOME)</li>
</ul>and some participated remotely:<br />
<ul style="text-align: left;"><li>Bastien Nocera (GNOME)</li>
<li>Garvan Keeley (Mozilla)</li>
</ul>Unfortunately Aaron McCarthy of Jolla couldn't attend remotely either as he lives in a very incompatible timezone (AU) but we had a lot of productive discussion with him through email that still continues.<br />
<br />
Some very fruitful discussions we had:<br />
<br />
<ul style="text-align: left;"><li>Why Mozilla doesn't make wifi data it gathers for its <a href="https://wiki.mozilla.org/CloudServices/Location" target="_blank">location service</a>, available for everyone to download? Hanno explained in great detail how making this data available would seriously compromise privacy and even safety of people. One good example given was someone getting out of an abusive relationship and not wanting to be traceable by their ex- but if they take their wifi router with them, their significant other has a possible way to easily track them using the wifi database. There is an easy (even though very ugly) way to avoid your AP being scanned by harvesters of such services but most people do not possess enough technical knowledge to know to enable that.<br />
<br />
Hence their reluctance to making it available for download, even though they'd want to. If you are interested in more details, you should read up all about that on <a href="http://blog.hannosch.eu/" target="_blank">Hanno's blog.<br />
</a></li>
<li>Had some discussion with Firefox and Firefox OS using <a href="http://geoclue.freedesktop.org/" target="_blank">Geoclue2</a>. Hopefully we'll at least have Firefox using Geoclue2 soon. I might need to add support for totally unmaintained ofono in Geoclue2 unfortunately for making a very compelling case for Firefox OS to adapt geoclue2.<br />
</li>
<li>We had a discussion about GPS-A support in Geoclue. There are two possible ways to do that:<br />
<ol><li>Give URL of a SUPL service to the modem and let it do everything for you.</li>
<li>Get the geospacial data that (SUPL service would provide) from a custom service and feed that to the modem.</li>
</ol>Hanno informed us that the only free SUPL implementation out there is that from Google but nobody knows what the ToS really are. He also informed us of how many modem chipsets just don't implement the API to feed it geospatial data and that makes SUPL our only hope to implement GPS-A.<br />
</li>
<li>There was a discussion about POI and check-in UI in <a href="https://wiki.gnome.org/Apps/Maps" target="_blank">Maps</a> between me and Mattias. We had a bit of disagreement about it but seems now we are coming to come conclusions about how it should look like.</li>
</ul></div>It was a hackfest so we also did some hacking:<br />
<br />
<ul style="text-align: left;"><li>John spent most of his time getting familiar with Qt's location code and how to port to Geoclue2. <a href="https://plus.google.com/+JohnLayt/posts/iw6cW48TohU" target="_blank">He wrote a nice post about it </a>so I wont get into details here.</li>
<li>Mattias worked tirelessly to finish off his routing branch to be finally merged. Its not a very easy task so its not surprising that he hasn't managed to finish it yet. I'm pretty hopeful it will be merged in the following few weeks.<br />
</li>
<li>Hanno added proper support for geoip-only queries in Mozilla location service, made it do better against queries w/ stale wifi data and improved accuracy of results from 300m to 100m among other things.<br />
</li>
<li>Jonas was doing live reviews of Mattias' patches (in Swedish!) and at the same time working on getting <a href="https://bugzilla.gnome.org/show_bug.cgi?id=725614" target="_blank">command-line options parsing</a> <a href="https://bugzilla.gnome.org/show_bug.cgi?id=727455" target="_blank">to work in</a> gjs so we can do so in Maps.<br />
</li>
<li>Garvan was working on adding Geoclue2 support to Firefox/Gecko.<br />
</li>
<li>I finished off my patches to port geoclue2 to directly use wpa_supplicant rather than NetworManager, which makes wifi-geolocation work on FreeBSD, Firefox OS and Jolla. The last two don't use Geoclue2 but I'm hoping that this is a step forward towards convincing them to use it. I provided a patch to wpa_supplicant to make its D-Bus policy a bit lenient, while at it.<br />
<br />
I also looked into ofono API but not only is the project unmaintained, it doesn't provide proper introspection on D-Bus and there is no API docs. :( To make things worse, both my modems don't seem to work at least out of the box. I'd really rather I didn't have to deal with it but if I can't convince Firefox OS folks to provide ModemManager API, adding ofono support is essential to get them to use Geoclue.<br />
<br />
I started refactoring of Modem sources in Geoclue so that:<br />
<ul><li>all ModemManager code is isolated in its own module so that its easy to add a ofono handling code w/o changing anything in the sources themselves.</li>
<li>3G source can more easily/cleanly share code with Wifi source, use Mozilla Location Service (rather than opencellid that it currently does) and also submit cell tower data to Mozilla.</li>
</ul></li>
</ul></div>I can't thank Mozilla and specifically <a href="http://chrislord.net/index.php/author/admin/" target="_blank">Chris Lord</a> enough for hosting this event for hosting this event.<br />
<div><div><ul style="text-align: left;"></ul></div></div></div>zeenixhttp://www.blogger.com/profile/04142631863736897222noreply@blogger.com1London, UK51.508515 -0.1254871999999522851.192402 -0.77093419999995227 51.824628000000004 0.51995980000004771tag:blogger.com,1999:blog-3575421168816814786.post-70949502939673566452014-05-05T16:41:00.000-07:002014-05-05T16:42:32.284-07:00Berlin, DX hackfest, Boxes, rain & sunshine<div dir="ltr" style="text-align: left;" trbidi="on">
I just flew back from Berlin where I spent the last week, mainly to participate in the <a href="https://wiki.gnome.org/Hackfests/DeveloperExperience2014" target="_blank">GNOME Developer Experience hackfest</a>. As you can see from <a href="http://sindhus.bitbucket.org/dev-x-day-2-3.html" target="_blank">blog</a> <a href="https://tecnocode.co.uk/2014/05/01/developer-experience-hackfest-2014/" target="_blank">posts</a> <a href="https://sigquit.wordpress.com/2014/05/01/profiles-in-devhelp/" target="_blank">from</a> <a href="http://blogs.gnome.org/cosimoc/2014/05/02/dx-hackfest-in-berlin/" target="_blank">other</a> <a href="http://bergie.iki.fi/blog/flowhub-gnome-dx/" target="_blank">awesome</a> <a href="http://blogs.gnome.org/ebassi/2014/05/02/berlin-dx-hackfest-day-3/" target="_blank">gnomies</a>, the hackfest was a pretty big success.<br />
<br />
I focused on the use of virtual machines (as thats right up my alley) for making application development as easy as possible. I talked to <a href="http://www.hergert.me/blog/" target="_blank">Christian</a>, who has been working on an IDE for GNOME about his idea of a simulator VM which allows the developer to quickly test their app in a pristine environment. We discussed if and how <a href="https://wiki.gnome.org/Apps/Boxes" target="_blank">Boxes</a> can be involved. After some discussion we decided that we probably don't want to use Boxes but rather create another binary that re-uses the existing virtualization infrastructure: libvirt, qemu, spice (and maybe libosinfo) etc.<br />
<br />
Another way to make GNOME development easy through VM would be what we already have on a very crude level: Distribution of ready-made VMs with all the development environment setup. <a href="https://wiki.gnome.org/Projects/GnomeContinuous" target="_blank">Continuous</a> already creates and distributes <a href="http://build.gnome.org/continuous/buildmaster/images/current/" target="_blank">ready VM disk images</a> of latest GNOME (almost everything from git) and Boxes can import these images. These images however are insufficient and unreliable since they do not contain any metadata, especially recommended/required system resources, about the VM. Christian recommended VMware's wmx format but that turned out to only contain metadata instead and you'd need a separate file (vmdk) for the disk image with that. What we really need here is a format that contains both metadata and all disk images in one file, in other words a <a href="http://en.wikipedia.org/wiki/Virtual_appliance" target="_blank">virtual appliance</a>. After doing some research on this, I once again came to the conclusion that <a href="https://en.wikipedia.org/wiki/Open_Virtualization_Format" target="_blank">OVF</a> is our only hope here. Not only its one file that can contain all important aspects of a VM, its an open standard that is agreed and implemented by many different vendors. Boxes being able to import/export from/to this format and Continuous being able to provide these virtual appliances wouldn't just enable a more reliable producer-consumer relationship between Continuous and Boxes but also allow individual developers to be easily able to share their work with others: "Hey! I've been working on this project/feature X last few days and want to get some input. I'm sending you the VM, just import it in Boxes and let me know what you think..".<br />
<br />
We've actually been wanting to have this feature for a very long time and I've mentioned the need for OVF support quite a few times so I decided its about time I do something about it. So during the hackfest, I designed the minimum interface for a library to convert from/to libvirt domain (or configuration) to/from OVF files and <a href="https://gitorious.org/govf" target="_blank">started the implementation</a> too. I hope to continue working on it to have something demoable by end of this month.<br />
<br />
Some other discussions/activities I had during/around the hackfest:<br />
<br />
* Talked with <a href="https://sigquit.wordpress.com/" target="_blank">Aleksander </a>about modem enabling/disabling. Currently geoclue has to enable the modem itself for using it but since it doesn't know if the modem is in use by another application, it doesn't disable it after using it. This results in waste of battery power. I suggested to Aleksander that the best thing would be for ModemManager to take care of that as it knows if modem is in use or not. The alternative would be some kind of explicit UI but throwing this decision on user would be a terrible thing to do. Aleksander liked the idea and he promised to look into implementing it.<br />
<br />
* I took part in Gtk+ roadmap discussion, mostly as a silent observer (Gtk+ hackers and designers covered it nicely so I didn't feel like saying anything) but during the meeting I learnt of a widget that was introduced in 3.12 that I had missed completely, <a href="https://developer.gnome.org/gtk3/stable/GtkFlowBox.html" target="_blank">GtkFlowBox</a>. Since developers were unhappy that we introduced a widget that is not used by any GNOME app and I realized that use of this widget in Boxes will bring me very close to my aim of dropping <a href="http://git.gnome.org/browse/libgd" target="_blank">libgd</a> usage, I decided to make Boxes the first user of this widget soon.<br />
<br />
* I realized (very late) that both my SoC studends live in Germany so I asked both of them if they can join us for any of the days. While it was impossible for <a href="http://baedert-gsoc.blogspot.com/" target="_blank">baedert</a> to join us on such short notice, <a href="http://schuirmann.eu/" target="_blank">Lasse</a> was still able to make it for the last day. It was really nice to meet this very bright young fellow. We had a lot of discussion about past, present and future of Boxes. Lasse has already written a very nice and detailed blog post about that so I'll leave you with a <a href="http://schuirmann.eu/2014/05/hackfest/" target="_blank">link to that</a> if you are interested.<br />
<br />
* Talked with <a href="http://blogs.gnome.org/cosimoc/" target="_blank">Cosimo</a> about use of Geoclue by <a href="https://endlessm.com/" target="_blank">Endless mobile</a>.<br />
<br />
* Tested <a href="http://people.collabora.com/~pwith/gnome-clang/" target="_blank">gnome-clang</a> against Geoclue to provide feedback to <a href="https://tecnocode.co.uk/" target="_blank">Philip</a> and it resulted in him fixing some important bugs.<br />
<br />
* Talked briefly to <a href="http://0pointer.de/blog%E2%80%8E" target="_blank">Lennart</a> about<br />
* How authorization of geoclue-using apps will/can work in the kdbus world.<br />
* The best way to allow Boxes to access USB devices with ISO9660 filesystems on them.<br />
<br />
Thats mostly it! I would like to thank Lennart for providing me with a nice accommodation, <a href="https://endocode.com/" target="_blank">Endocode</a> for providing us a great venue (+ endless supply of Club mate) and GNOME foundation for sponsoring my travel.<br />
<br />
<div class="separator" style="clear: both; text-align: center;">
<a href="https://wiki.gnome.org/Travel/Policy?action=AttachFile&do=get&target=sponsored-badge-shadow.png" imageanchor="1" style="margin-left: 1em; margin-right: 1em;"><img border="0" src="https://wiki.gnome.org/Travel/Policy?action=AttachFile&do=get&target=sponsored-badge-shadow.png" /></a></div>
<br />
<div style="text-align: left;">
<br /></div>
<div style="text-align: left;">
<br /></div>
<div style="text-align: left;">
</div>
</div>
zeenixhttp://www.blogger.com/profile/04142631863736897222noreply@blogger.com0tag:blogger.com,1999:blog-3575421168816814786.post-43755144895263234162014-04-22T04:30:00.003-07:002014-04-22T04:30:31.054-07:00What's coming in Maps 3.14 and beyond<div dir="ltr" style="text-align: left;" trbidi="on">
Jonas has written a <a href="http://jonasdn.blogspot.se/2014/04/whats-coming-in-maps-314-and-beyond.html?m=1" target="_blank">very nice blog post about present and future of Maps project</a>. I definitely recommending reading it if you are interested in this project. Since he is not on planet.gnome yet (some policy about having some posts before applying to be added), I thought I share it here.</div>
zeenixhttp://www.blogger.com/profile/04142631863736897222noreply@blogger.com0