X-Git-Url: http://pere.pagekite.me/gitweb/homepage.git/blobdiff_plain/65281b7e0834062f88eea395975ffe9a1c523fed..86cf64ab1254f8c6c839c1c0060370cc7892f99a:/blog/index.rss diff --git a/blog/index.rss b/blog/index.rss index f0465a445f..01e425ad65 100644 --- a/blog/index.rss +++ b/blog/index.rss @@ -6,6 +6,49 @@ http://people.skolelinux.org/pere/blog/ + + Generating 3D prints in Debian using Cura and Slic3r(-prusa) + http://people.skolelinux.org/pere/blog/Generating_3D_prints_in_Debian_using_Cura_and_Slic3r__prusa_.html + http://people.skolelinux.org/pere/blog/Generating_3D_prints_in_Debian_using_Cura_and_Slic3r__prusa_.html + Mon, 9 Oct 2017 10:50:00 +0200 + <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> + + + Mangler du en skrue, eller har du en skrue løs? http://people.skolelinux.org/pere/blog/Mangler_du_en_skrue__eller_har_du_en_skrue_l_s_.html @@ -500,99 +543,5 @@ mailing list).</p> - - Idea for storing trusted timestamps in a Noark 5 archive - http://people.skolelinux.org/pere/blog/Idea_for_storing_trusted_timestamps_in_a_Noark_5_archive.html - http://people.skolelinux.org/pere/blog/Idea_for_storing_trusted_timestamps_in_a_Noark_5_archive.html - Wed, 7 Jun 2017 21:40:00 +0200 - <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> - - -