Julio Biason
5 years ago
2 changed files with 68 additions and 0 deletions
@ -0,0 +1,62 @@
|
||||
+++ |
||||
title = "Links for 2020-03-11" |
||||
date = 2020-03-11 |
||||
|
||||
[taxonomies] |
||||
tags = ["links", "google", "agpl"] |
||||
+++ |
||||
|
||||
Google Policy towards AGPL software, Swift vs Rust, Open Source Economics, |
||||
JUnit 5, cfg(doctest), Firefox on Flathub. |
||||
|
||||
<!-- more --> |
||||
|
||||
# [AGPL Policy](https://opensource.google/docs/using/agpl-policy/) |
||||
|
||||
Google policy towards using AGPL software. Basically, because AGPL says |
||||
"source is _always_ available", Google says "maintain an aggressively-broad |
||||
ban on all AGPL software" |
||||
|
||||
Take away: Release **everything** under the AGPL. |
||||
|
||||
# [Impressions of Rust as a Swift Developer: Memory Management](https://blog.spencerkohan.com/impressions-of-rust-as-a-swift-developer-2/) |
||||
|
||||
A take on the way Rust and Swift manages memory. While I agree with the |
||||
drawbacks of Rust, the author forgets to mention the price Swift pays for its |
||||
simplicity: A runtime. |
||||
|
||||
Having a runtime is bad? Well, it depends: If you're not using anything the |
||||
runtime offers (your application does a full allocation upfront and never |
||||
deallocates, it completes its job before it has time to actually use the |
||||
garbage collector), you're basically wasting resources. Sure, you pay this in |
||||
development time, but this has to be measured. |
||||
|
||||
Also, a runtime means another problem: Runtime errors. Unless your compiler |
||||
picks those and stop you from creating code that can generate those errors, |
||||
you'll get those. |
||||
|
||||
(Also, fun fact: Graydon Hoare, the creator of Rust, worked on Swift.) |
||||
|
||||
# [cfg(doctest) is stable and you should use it](https://blog.guillaume-gomez.fr/articles/2020-03-07+cfg%28doctest%29+is+stable+and+you+should+use+it) |
||||
|
||||
Speaking of Rust, here's a feature I was not aware of: You can create testing |
||||
modules that test Markdown documentation. Why would anyone do that? Well, |
||||
markdown is usually the way people document their applications and you want |
||||
your examples to actually work, right? |
||||
|
||||
# [Can We Make Open Source More Sustainable?](https://www.telerik.com/blogs/can-we-make-open-source-more-sustainable) |
||||
|
||||
A big problem with open source is that actually nobody cares about how it is |
||||
developed: Sure, there is a _person_ (or _persons_) behind it, but how are |
||||
those people paying for their living, eating and health? The post points some |
||||
things open source developers can do to get something out. |
||||
|
||||
# [Improve your tests with JUnit 5](https://98elements.com/blog/improve-your-tests-with-junit-5/) |
||||
|
||||
A few tips on using JUnit 5 -- some that I was not aware of. |
||||
|
||||
# [Mozilla makes Firefox Beta available on Flathub](https://eischmann.wordpress.com/2020/03/10/mozilla-makes-firefox-beta-available-on-flathub/) |
||||
|
||||
Mozilla is making Firefox available on Flathub, which means now it is even |
||||
easier to test Firefox without breaking your system -- 'cause Flatpak keeps |
||||
the whole package in its own container and it does not touch your system. |
Loading…
Reference in new issue