<link>http://people.skolelinux.org/pere/blog/</link>
<atom:link href="http://people.skolelinux.org/pere/blog/index.rss" rel="self" type="application/rss+xml" />
+ <item>
+ <title>Generating 3D prints in Debian using Cura and Slic3r(-prusa)</title>
+ <link>http://people.skolelinux.org/pere/blog/Generating_3D_prints_in_Debian_using_Cura_and_Slic3r__prusa_.html</link>
+ <guid isPermaLink="true">http://people.skolelinux.org/pere/blog/Generating_3D_prints_in_Debian_using_Cura_and_Slic3r__prusa_.html</guid>
+ <pubDate>Mon, 9 Oct 2017 10:50:00 +0200</pubDate>
+ <description><p>At my nearby maker space,
+<a href="http://sonen.ifi.uio.no/">Sonen</a>, I heard the story that it
+was easier to generate gcode files for theyr 3D printers (Ultimake 2+)
+on Windows and MacOS X than Linux, because the software involved had
+to be manually compiled and set up on Linux while premade packages
+worked out of the box on Windows and MacOS X. I found this annoying,
+as the software involved,
+<a href="https://github.com/Ultimaker/Cura">Cura</a>, is free software
+and should be trivial to get up and running on Linux if someone took
+the time to package it for the relevant distributions. I even found
+<a href="https://bugs.debian.org/706656">a request for adding into
+Debian</a> from 2013, which had seem some activity over the years but
+never resulted in the software showing up in Debian. So a few days
+ago I offered my help to try to improve the situation.</p>
+
+<p>Now I am very happy to see that all the packages required by a
+working Cura in Debian are uploaded into Debian and waiting in the NEW
+queue for the ftpmasters to have a look. You can track the progress
+on
+<a href="https://qa.debian.org/developer.php?email=3dprinter-general%40lists.alioth.debian.org">the
+status page for the 3D printer team</a>.</p>
+
+<p>The uploaded packages are a bit behind upstream, and was uploaded
+now to get slots in <a href="ftp-master.debian.org/new.html">the NEW
+queue</a> while we work up updating the packages to the latest
+upstream version.</p>
+
+<p>On a related note, two competitors for Cura, which I found harder
+to use and was unable to configure correctly for Ultimaker 2+ in the
+short time I spent on it, are already in Debian. If you are looking
+for 3D printer "slicers" and want something already available in
+Debian, check out
+<a href="https://tracker.debian.org/pkg/slic3r">slic3r</a> and
+<a href="https://tracker.debian.org/pkg/slic3r-prusa">slic3r-prusa</a>.
+The latter is a fork of the former.</p>
+</description>
+ </item>
+
<item>
<title>Mangler du en skrue, eller har du en skrue løs?</title>
<link>http://people.skolelinux.org/pere/blog/Mangler_du_en_skrue__eller_har_du_en_skrue_l_s_.html</link>
</description>
</item>
- <item>
- <title>Idea for storing trusted timestamps in a Noark 5 archive</title>
- <link>http://people.skolelinux.org/pere/blog/Idea_for_storing_trusted_timestamps_in_a_Noark_5_archive.html</link>
- <guid isPermaLink="true">http://people.skolelinux.org/pere/blog/Idea_for_storing_trusted_timestamps_in_a_Noark_5_archive.html</guid>
- <pubDate>Wed, 7 Jun 2017 21:40:00 +0200</pubDate>
- <description><p><em>This is a copy of
-<a href="https://lists.nuug.no/pipermail/nikita-noark/2017-June/000297.html">an
-email I posted to the nikita-noark mailing list</a>. Please follow up
-there if you would like to discuss this topic. The background is that
-we are making a free software archive system based on the Norwegian
-<a href="https://www.arkivverket.no/forvaltning-og-utvikling/regelverk-og-standarder/noark-standarden">Noark
-5 standard</a> for government archives.</em></p>
-
-<p>I've been wondering a bit lately how trusted timestamps could be
-stored in Noark 5.
-<a href="https://en.wikipedia.org/wiki/Trusted_timestamping">Trusted
-timestamps</a> can be used to verify that some information
-(document/file/checksum/metadata) have not been changed since a
-specific time in the past. This is useful to verify the integrity of
-the documents in the archive.</p>
-
-<p>Then it occured to me, perhaps the trusted timestamps could be
-stored as dokument variants (ie dokumentobjekt referered to from
-dokumentbeskrivelse) with the filename set to the hash it is
-stamping?</p>
-
-<p>Given a "dokumentbeskrivelse" with an associated "dokumentobjekt",
-a new dokumentobjekt is associated with "dokumentbeskrivelse" with the
-same attributes as the stamped dokumentobjekt except these
-attributes:</p>
-
-<ul>
-
-<li>format -> "RFC3161"
-<li>mimeType -> "application/timestamp-reply"
-<li>formatDetaljer -> "&lt;source URL for timestamp service&gt;"
-<li>filenavn -> "&lt;sjekksum&gt;.tsr"
-
-</ul>
-
-<p>This assume a service following
-<a href="https://tools.ietf.org/html/rfc3161">IETF RFC 3161</a> is
-used, which specifiy the given MIME type for replies and the .tsr file
-ending for the content of such trusted timestamp. As far as I can
-tell from the Noark 5 specifications, it is OK to have several
-variants/renderings of a dokument attached to a given
-dokumentbeskrivelse objekt. It might be stretching it a bit to make
-some of these variants represent crypto-signatures useful for
-verifying the document integrity instead of representing the dokument
-itself.</p>
-
-<p>Using the source of the service in formatDetaljer allow several
-timestamping services to be used. This is useful to spread the risk
-of key compromise over several organisations. It would only be a
-problem to trust the timestamps if all of the organisations are
-compromised.</p>
-
-<p>The following oneliner on Linux can be used to generate the tsr
-file. $input is the path to the file to checksum, and $sha256 is the
-SHA-256 checksum of the file (ie the "<sjekksum>.tsr" value mentioned
-above).</p>
-
-<p><blockquote><pre>
-openssl ts -query -data "$inputfile" -cert -sha256 -no_nonce \
- | curl -s -H "Content-Type: application/timestamp-query" \
- --data-binary "@-" http://zeitstempel.dfn.de > $sha256.tsr
-</pre></blockquote></p>
-
-<p>To verify the timestamp, you first need to download the public key
-of the trusted timestamp service, for example using this command:</p>
-
-<p><blockquote><pre>
-wget -O ca-cert.txt \
- https://pki.pca.dfn.de/global-services-ca/pub/cacert/chain.txt
-</pre></blockquote></p>
-
-<p>Note, the public key should be stored alongside the timestamps in
-the archive to make sure it is also available 100 years from now. It
-is probably a good idea to standardise how and were to store such
-public keys, to make it easier to find for those trying to verify
-documents 100 or 1000 years from now. :)</p>
-
-<p>The verification itself is a simple openssl command:</p>
-
-<p><blockquote><pre>
-openssl ts -verify -data $inputfile -in $sha256.tsr \
- -CAfile ca-cert.txt -text
-</pre></blockquote></p>
-
-<p>Is there any reason this approach would not work? Is it somehow against
-the Noark 5 specification?</p>
-</description>
- </item>
-
</channel>
</rss>
projects / homepage.git / blobdiff