The tint package is now on CRAN. Its name stands for Tint Is Not Tufte and it offers a fresh take on the excellent Tufte-style html (and now also pdf) presentations.
As a little teaser, here is what the html variant looks like:
This post by Dirk Eddelbuettel originated on his Thinking inside the box blog. Please report excessive re-aggregation in third-party for-profit settings.
SUBSYSTEM=="usb", ACTION=="add", ATTR idVendor =="0694", ATTR idProduct =="0001", \
SYMLINK+="rcx-%k", TAG+="uaccess"
The key part is the 'TAG+="uaccess"' at the end. I suspect all
packages using plugdev in their /lib/udev/rules.d/ files should be
changed to use this tag (either directly or indirectly via
70-uaccess.rules). Perhaps a lintian check should be created
to detect this?
I've been unable to find good documentation on the uaccess feature.
It is unclear to me if the uaccess tag is an internal implementation
detail like the udev-acl tag used by
/lib/udev/rules.d/70-udev-acl.rules. If it is, I guess the
indirect method is the preferred way. Michael
asked for more
documentation from the systemd project and I hope it will make
this clearer. For now I use the generic classes when they exist and
is already handled by 70-uaccess.rules, and add the tag
directly if no such class exist.
To learn more about the isenkram system, please check out
my
blog posts tagged isenkram.
To help out making life for LEGO constructors in Debian easier,
please join us on our IRC channel
#debian-lego and join
the Debian
LEGO team in the Alioth project we created yesterday. A mailing
list is not yet created, but we are working on it. :)
As usual, if you use Bitcoin and want to show your support of my
activities, please send Bitcoin donations to my address
15oWEoG9dUPovwmUL9KWAnYRtNJEkP1u1b.
If your gpg key is too valuable for you to feel comfortable with
backing it up to the cloud using keysafe, here's an alternative
that might appeal more.
Keysafe can now back up some shares of the key to local media, and other
shares to the cloud. You can arrange things so that the key can't be
restored without access to some of the local media and some of the cloud
servers, as well as your password.
For example, I have 3 USB sticks, and there are 3 keysafe servers. So let's
make 6 shares total of my gpg secret key and require any 4 of them to
restore it.
I plug in all 3 USB sticks and look at mount to get the paths to them.
Then, run keysafe, to back up the key spread amoung all 6 locations.
keysafe --backup --totalshares 6 --neededshares 4 \
--add-storage-directory /media/sdc1 \
--add-storage-directory /media/sdd1 \
--add-storage-directory /media/sde1
keysafe --restore --totalshares 6 --neededshares 4 \
--add-storage-directory /media/sdb1
This post is long past due, but I figured it is better late than never. At the start of the year, I set a goal to get more involved with attending and speaking at conferences. Through work, I was able to attend the Southern California Linux Expo (SCALE) in Pasadena, CA in January. I also got to give a talk at O'Relly's Open Source Convention (OSCON) in Austin, TX in May. However, I really wanted to give a talk about my experience contributing in the Ubuntu community.
Jos Antonio Rey encouraged me to submit the talk to FOSSCON. While I've been aware of FOSSCON for years thanks to my involvement with the freenode IRC network (which has had a reference to FOSSCON in the /motd for years), I had never actually attended it before. I also wasn't quite sure how I would handle traveling from San Francisco, CA to Philadelphia, PA. Regardless, I decided to go ahead and apply.
Fast forward a few weeks, and imagine my surprise when I woke up to an email saying that my talk proposal was accepted. People were actually interested in me and what I had to say. I immediately began researching flights. While they weren't crazy expensive, they were still more money than I was comfortable spending. Luckily, Jos had a solution to this problem as well; he suggested applying for funding through the Ubuntu Community Donations fund. While I've been an Ubuntu Member for over 8 years, I've never used this resource before. However, I was happy when I received a very quick approval.
The conference itself was smaller than I was expecting. However, it was packed with lots of friendly and familiar faces of people I've interacted with online and in person over the years at various Open Source events.
I started off the day by learning from Jos how to use Juju to quickly setup applications in the cloud. While Juju has definitely come a long way over the last couple of years, and it appears t be quite easy to learn and use, it still appears to be lacking some of the features needed to take full control over how the underlying applications interact with each other. However, I look forward to continuing to watch it grow and mature.
Net up, we had a lunch break. There was no catered lunch at this conference, so we decided to get some cheesesteak at Abner's (is any trip to Philadelphia complete without cheesesteak?).
Following lunch, I took some time to make a few last minute changes to my presentation and rehearse a bit. Finally, it was time. I got up in front of the audience and gave my presentation. Overall, I was quite pleased. It was not perfect, but for the first time giving the talk, I thought it went pretty well. I will work hard to make it even better for next tme.
Following my talk was a series of brief lightning talks prior to the closing keynote. Another long time friend of mine, Elizabeth Krumbach Joseph, was giving the keynote about listening to the needs of your global open source community. While I have seen her speak on several other occassions, I really enjoyed this particular talk. It was full of great examples and anecdotes that were easy for the audience to relate to and start applying to their own communities.
After the conference, a few of us went off and played tourist, paying the Liberty Bell a visit before concluding our trip in Philadelpha.
Overall, I had a great time as FOSSCON. It was great being re-united with so many friends. A big thank you to Jos for his constant support and encouragement and to Canonical and the Ubuntu Community for helping to make it possible for me to attend this conference. Finally, thanks to the terrific FOSSCON staff for volunteering so much time to put on this great event.
I was assigned 12.3 hours of work by Freexian's Debian LTS
initiative and carried over 1.45 from last month. I was unwell for
much of this month and only worked 6 hours on LTS. I returned 7
hours to the pool and carry over 0.75 hours.
I wrote and sent
the DLA
for linux 3.2.81-2, and I discussed various handling of various
issues on the debian-lts mailing list. Most of my time was spent
working on the long backlog
of security
issues in imagemagick. I hope to complete this and upload a
fixed version this month.
People keep ignoring the status of the Pacemaker HA stack in Debian
Jessie. Most people think that they should stick to Debian Wheezy.
Why does this happen? Perhaps little or none publicity of the situation.
Since some time now, Debian contains a Pacemaker stack which is ready
to use in both Debian Jessie and in Debian Stretch.
Anyway, let s see what we have so far:
| package | jessie-backports | stretch | sid | upstream |
|---|---|---|---|---|
| corosync | 2.3.6 | 2.3.6 | 2.3.6 | 2.4.1 |
| pacemaker | 1.1.14 | 1.1.15 | 1.1.15 | 1.1.15 |
| crmsh | 2.2.0 | 2.2.1 | 2.2.1 | 2.4.1 |
| libqb | 1.0 | 1.0 | 1.0 | 1.0 |
debrepro
script by Antonio Terceiro which is similar in purpose to reprotest but more
lightweight; specific to Debian packages and without support for virtual servers
or configurable variations.
Packages reviewed and fixed, and bugs filed
The following updated packages have become reproducible in our testing framework
after being fixed:
61 was
uploaded to unstable by Chris
Lamb. It included
contributions
from:
--help text and add an --output-empty option.--status-fd CLI option.0.3.2 was
uploaded to unstable by Ximin
Luo. It included
contributions
from:
--diffoscope-arg CLI option to pass extra args to diffoscope.
Ria has the sprue. She keeps her c liac disease a secret, though,
because she works in food service, and customers knowing about her
little gluten-sensitive enterology problem would, she feels, damage
her credibility.
The fried chicken is delicious, she coos. There is nothing
gluten-free on the menu, so she does not have first-hand knowledge
of this. Instead she is proxying the amalgamated judgments of
others.
My house entered full power saving mode with fall.
Lantern light and all devices shutdown at bedtime.
But, it felt early to need to do this. Comparing with my logbook for last
year, the batteries were indeed doing much worse.
I had added a couple of new batteries to the bank last winter, and they
seemed to have helped at the time, although it's difficult to tell when you
have a couple of good batteries amoung a dozen failing ones.
The bank was set up like this:
+---- house ----
+( 6v )-+( 6v )-
+( 6v )-+( 6v )-
+( 6v )-+( 6v )-
+( 6v )-+( 6v )-
+( 6v )-+( 6v )-
+( new 12v )-
+( new 12v )-
+---- house ----
+( 6v )-+( 6v )-
+( 6v ) ( 6v )-
+( 6v ) ( 6v )-
+( 6v ) ( 6v )-
+( 6v ) ( 6v )-
+( new 12v )-
+( new 12v )-
I had a great time last week and the web engines hackfest! It was the 7th web hackfest hosted by Igalia and the 7th hackfest I attended. I m almost a local Galician already. Brazilian Portuguese being so close to Galician certainly helps! Collabora co-sponsored the event and it was great that two colleagues of mine managed to join me in attendance.
It had great talks that will eventually end up in videos uploaded to the web site. We were amazed at the progress being made to Servo, including some performance results that blew our minds. We also discussed the next steps for WebKitGTK+, WebKit for Wayland (or WPE), our own Clutter wrapper to WebKitGTK+ which is used for the Apertis project, and much more.
Zan giving his talk on WPE (former WebKitForWayland)
Introducing WebKitClutterGTK+ 
Igalia 15 years cake| Publisher: | Del Rey |
| Copyright: | 2015 |
| Printing: | 2016 |
| ISBN: | 0-8041-7904-2 |
| Format: | Kindle |
| Pages: | 465 |
A new version of RcppGSL in now on CRAN and in Debian. The RcppGSL package provides an interface from R to the GNU GSL using our Rcpp package.
This release is one that entirely focused on maintenance. CRAN asked us to change on aspect relative to vignettes, and we added a few more small updates related entirely to packaging. In other words, no user-facing changes.
The NEWS file entries follows below:
Courtesy of CRANberries, a summary of changes to the most recent release is available. More information is on the RcppGSL page. Questions, comments etc should go to the issue tickets at the GitHub repo.Changes in version 0.3.1 (2016-10-02)
- The unit test driver was updated and simplified, (by request of CRAN) no longer leaves files in '/tmp', and removes two unexported (and unused) test helper functions (PR #10)
- Switched to
run.shfor Travis (PR #11)- Use canonical CRAN URLs in README.md
- Restored 'boxed' display of code in vignette (PR #12)
This post by Dirk Eddelbuettel originated on his Thinking inside the box blog. Please report excessive re-aggregation in third-party for-profit settings.
Previously: v4.7. Here are a bunch of security things I m excited about in Linux v4.8:
SLUB freelist ASLR
Thomas Garnier continued his freelist randomization work by adding SLUB support.
x86_64 KASLR text base offset physical/virtual decoupling
On x86_64, to implement the KASLR text base offset, the physical memory location of the kernel was randomized, which resulted in the virtual address being offset as well. Due to how the kernel s -2GB addressing works (gcc s -mcmodel=kernel ), it wasn t possible to randomize the physical location beyond the 2GB limit, leaving any additional physical memory unused as a randomization target. In order to decouple the physical and virtual location of the kernel (to make physical address exposures less valuable to attackers), the physical location of the kernel needed to be randomized separately from the virtual location. This required a lot of work for handling very large addresses spanning terabytes of address space. Yinghai Lu, Baoquan He, and I landed a series of patches that ultimately did this (and in the process fixed some other bugs too). This expands the physical offset entropy to roughly $physical_memory_size_of_system / 2MB bits.
x86_64 KASLR memory base offset
Thomas Garnier rolled out KASLR to the kernel s various statically located memory ranges, randomizing their locations with CONFIG_RANDOMIZE_MEMORY. One of the more notable things randomized is the physical memory mapping, which is a known target for attacks. Also randomized is the vmalloc area, which makes attacks against targets vmalloced during boot (which tend to always end up in the same location on a given system) are now harder to locate. (The vmemmap region randomization accidentally missed the v4.8 window and will appear in v4.9.)
x86_64 KASLR with hibernation
Rafael Wysocki (with Thomas Garnier, Borislav Petkov, Yinghai Lu, Logan Gunthorpe, and myself) worked on a number of fixes to hibernation code that, even without KASLR, were coincidentally exposed by the earlier W^X fix. With that original problem fixed, then memory KASLR exposed more problems. I m very grateful everyone was able to help out fixing these, especially Rafael and Thomas. It s a hard place to debug. The bottom line, now, is that hibernation and KASLR are no longer mutually exclusive.
gcc plugin infrastructure
Emese Revfy ported the PaX/Grsecurity gcc plugin infrastructure to upstream. If you want to perform compiler-based magic on kernel builds, now it s much easier with CONFIG_GCC_PLUGINS! The plugins live in scripts/gcc-plugins/. Current plugins are a short example called Cyclic Complexity which just emits the complexity of functions as they re compiled, and Sanitizer Coverage which provides the same functionality as gcc s recent -fsanitize-coverage=trace-pc but back through gcc 4.5. Another notable detail about this work is that it was the first Linux kernel security work funded by Linux Foundation s Core Infrastructure Initiative. I m looking forward to more plugins!
If you re on Debian or Ubuntu, the required gcc plugin headers are available via the gcc-$N-plugin-dev package (and similarly for all cross-compiler packages).
hardened usercopy
Along with work from Rik van Riel, Laura Abbott, Casey Schaufler, and many other folks doing testing on the KSPP mailing list, I ported part of PAX_USERCOPY (the basic runtime bounds checking) to upstream as CONFIG_HARDENED_USERCOPY. One of the interface boundaries between the kernel and user-space are the copy_to_user()/copy_from_user() family of functions. Frequently, the size of a copy is known at compile-time ( built-in constant ), so there s not much benefit in checking those sizes (hardened usercopy avoids these cases). In the case of dynamic sizes, hardened usercopy checks for 3 areas of memory: slab allocations, stack allocations, and kernel text. Direct kernel text copying is simply disallowed. Stack copying is allowed as long as it is entirely contained by the current stack memory range (and on x86, only if it does not include the saved stack frame and instruction pointers). For slab allocations (e.g. those allocated through kmem_cache_alloc() and the kmalloc()-family of functions), the copy size is compared against the size of the object being copied. For example, if copy_from_user() is writing to a structure that was allocated as size 64, but the copy gets tricked into trying to write 65 bytes, hardened usercopy will catch it and kill the process.
For testing hardened usercopy, lkdtm gained several new tests: USERCOPY_HEAP_SIZE_TO, USERCOPY_HEAP_SIZE_FROM, USERCOPY_STACK_FRAME_TO,SECCOMP_RET_TRACE) could explicitly bypass seccomp filtering and force a desired syscall. Nothing actually used this feature, and as it turns out, it s not compatible with process launchers that install seccomp filters (e.g. systemd, lxc) since as long as the ptrace and fork syscalls are allowed (and fork is needed for any sensible container environment), a process could spawn a tracer to help bypass a filter by injecting syscalls. After Andy Lutomirski convinced me that ordering ptrace first does not change the attack surface of a running process (unless all syscalls are blacklisted, the entire ptrace attack surface will always be exposed), I rearranged things. Now there is no (expected) way to bypass seccomp filters, and containers with seccomp filters can allow ptrace again.
That s it for v4.8! The merge window is open for v4.9
2016, Kees Cook. This work is licensed under a Creative Commons Attribution-ShareAlike 3.0 License.
My monthly report covers a large part of what I have been doing in the free software world. I write it for my donators (thanks to them!) but also for the wider Debian community because it can give ideas to newcomers and it s one of the best ways to find volunteers to work with me on projects that matter to me.
Debian LTS
With the increasing number of paid contributors, easy fixes (CVE with patches available) tend to be processed rather quickly. All the package I worked on had issues that were open for a long time because they were hard to handle.
I prepared DLA-613-1 fixing 3 CVE on roundcube. The fix required to manually backport the CRSF handling code which was not available in the wheezy version. I spent almost 8 hours on roundcube.
Then I started to work on tiff3. I reviewed many CVE: CVE-2016-3658, CVE-2015-7313, CVE-2015-7554, CVE-2015-8668, CVE-2016-5318, CVE-2016-3625, CVE-2016-5319. I updated their status for tiff3 in wheezy, requested reproducer files to people who reported the CVE when the files were not publicly available and made sure that everything was recorded in the upstream bug tracker. The 4.25 hours I spent on the package were not enough to work on patches, so I put the package back in the work queue.
GNOME 3.22 transition
I uploaded a new gnome-shell-timer that would work with GNOME 3.21 that had been uploaded to sid.
Unfortunately, that new GNOME (and GTK+) version caused many regressions that affected Debian Testing (and thus Kali) users in particular in gnome-control-center. I uploaded a new version fixing some of those issues and I reported a bunch of them to upstream too (#771515, #771517, #771696).
Kali
I worked on #836211 creating a dpkg patch to work-around the overlayfs limitation (we use it in Kali because persistence of live system relies on overlayfs) and I contacted the upstream overlayfs maintainer to hopefully get a proper fix on the overlayfs side instead.
I uploaded radcli 1.2.6-2.1 to fix RC bug #825121 as the package was removed from testing and openvas depends on it in Kali.
As part of the pkg-security team, I sponsored/uploaded acccheck and arp-scan for Marcos Fouces, and p0f 3.09b as well.
Misc Debian work
Distro Tracker. I tested, fixed and merged Paul Wise s patch integrating multiarch hints into tracker.debian.org (#833623).
Debian Handbook. I enabled the new Vietnamese translation on debian-handbook.info and updated all translations with Weblate updates.
systemd units for apache2. I prepared systemd units for apache2 which I submitted in #798430. With approval of Stefan Fritsch, I committed my work to the git repository and then uploaded the result in version 2.4.23-5.
Hindsight packaging. I first packaged lua-sandbox (#838969) which is a dependency of Hindsight and then Hindsight itself (#838968). In this process, I opened a couple of upstream tickets.
PIE by default. I uploaded a new version of cpputest compiled with -fPIC so shat executable linking to its static library can be compiled with -fPIE (#837363, forwarded upstream here).
Bugs filed. Bad homepage link in haskell-dice-entropy-conduit. Inconsistent options --onlyscripts and --noscripts in debhelper. pidgin entry in security-support-limited is out of date in debian-security-support. New upstream version (2.0.2) in puppet-lint.
Thanks
See you next month for a new summary of my activities.
No comment Liked this article? Click here. My blog is Flattr-enabled.
I have been working quite hard, along with my friend and colleague
Richard Maw, on getting Gitano ready for a release suitable for
inclusion into Debian Stretch.
You can see how we're doing on the various Trello boards for:
As Richard and I work toward a version of Gitano we're prepared to support
long-term in Debian we are making many changes to make our lives easier. For
those of you who have been using Gitano over the past few years, you'll need to
pay attention to some postings which will be coming soon about how to make the
changes you need so as to not explode horribly when you upgrade to the version
we're releasing soon. For those of you who are not yet using Gitano but feel
like you might want to; I'll also be producing some postings about getting
started with the packages. And for those happily running current HEAD of
Gitano already, I'll be posting about some of the new features over the next
little while in case you're not aware of them.
IMPORTANT: If you're using Gitano already and have any issues or feature requests then please please please let me know ASAP otherwise they're unlikely to be resolved/implemented before 1.0. irl already asked for the facility to verify GPG signed commits and tags, but if you want anything else considering then I need to know v. soon. (Ideally email me, but you may comment on this posting too if you must)
Shipping Position Independent Executables and using read-only Global Offset Table was already possible for packages but needed package maintainers to opt-in for each package (see Hardening wiki) using the pie and bindnow Dpkg hardening flags.
Many critical packages enabled the extra flags but there are still way more left out according to Lintian hardening-no-bindnow and hardening-no-pie warnings.
Now we can change that. We can make those hardening flags the default for every package.
Welcome to gambaru.de. Here is my monthly report that covers what I have been doing for Debian. If you re interested in Android, Java, Games and LTS topics, this might be interesting for you.
Debian Android
Trust is important in any kind of interpersonal relationship. It's inevitable that there will be cases where something you do will irritate or upset others, even if only to a small degree. Handling small cases well helps build trust that you will do the right thing in more significant cases, whereas ignoring things that seem fairly insignificant (or saying that you'll do something about them and then failing to do so) suggests that you'll also fail when there's a major problem. Getting the small details right is a major part of creating the impression that you'll deal with significant challenges in a responsible and considerate way.
This would be a longish post. I had bought a Samsung Galaxy J-5/500 just a few days before Debconf16 which I had written about a bit earlier as well. As can be seen in the specs there isn t much to explore other than A-GPS. There were a couple of temperature apps. which I wanted to explore before buying the smartphone but as there were budget constraints and there weren t any good budget smartphones with environmental sensors built-in had to let go of those features.
I was looking for a free app. which would have OSM support and came across osmand . I was looking for an app. which would have support for OSM and support for the gpx format.
I was planning to use osmand in South Africa but due to the over-whelming nature of meeting people, seeing places and just being didn t actually get the time and place to try it.
Came back home and a month and a half passed. In-between I had done some simple small tracks but nothing major. This week-end I got the opportunity as I got some free data balance from my service provider (a princely 50 MB) as well an opportunity to go about 40 odd kms. from the city. I had read about osmand and was looking if the off-line method worked or not from the webpage
Works online (fast) or offline (no roaming charges when you are abroad)
So armed with a full battery I started the journey which took about an hour and half even though technically it was a holiday. On the way back, got a different route and recorded that as well. The app. worked flawlessly. I was able to get the speed of the vehicle and everything. The only thing I haven t understood till date is how to select waypoints but other than that I got the whole route on my mobile.
What was cool to see that on most roads, at least through the app. there were speed limits. Now I don t know from where the data was getting there. Most city roads had 65 and some roads had 55 at the maximum. I am assuming that it was at km/hr as also shared later.
Just for fun I also looked at the gpx file after copying it from mobile to hdd (an extract) https://paste.debian.net/853231/
While it s not a complete extract, What was interesting for me to note here is the time was in UTC . What was also interesting is that in the gpx tracks I also saw some entries about speed as can be seen in the paste above. Although it doesn t say whether it was in km/hr or mph, I believe it probably is km/hr. as that is the unit I defined in the app.
Anyways, the next step was trying to see which tool was good enough to show me the tracks with tiles underneath and labels of places, paths etc.
I tried three tools
1. jmapviewer this didn t work at all. [shirish@debian] - [~/osmand] - [10149]
[$] gnome-maps 2016-10-01_08-11_Sat.gpx
(gnome-maps:21017): Gtk-WARNING **: Theme parsing error: gtk.css:63:28: The :prelight pseudo-class is deprecated. Use :hover instead.
(gnome-maps:21017): Gtk-WARNING **: Theme parsing error: gtk.css:73:35: The :prelight pseudo-class is deprecated. Use :hover instead.
(gnome-maps:21017): Gtk-WARNING **: Theme parsing error: application.css:14:30: The style property GtkButton:image-spacing is deprecated and shouldn't be used anymore. It will be removed in a future version
(gnome-maps:21017): Gtk-WARNING **: Theme parsing error: application.css:15:31: The style property GtkWidget:interior-focus is deprecated and shouldn't be used anymore. It will be removed in a future version
(gnome-maps:21017): Gdk-WARNING **: /build/gtk+3.0-Tod2iD/gtk+3.0-3.22.0/./gdk/x11/gdkwindow-x11.c:5554 drawable is not a native X11 window
(gnome-maps:21017): Gdk-WARNING **: /build/gtk+3.0-Tod2iD/gtk+3.0-3.22.0/./gdk/x11/gdkwindow-x11.c:5554 drawable is not a native X11 window
(gnome-maps:21017): Gdk-WARNING **: /build/gtk+3.0-Tod2iD/gtk+3.0-3.22.0/./gdk/x11/gdkwindow-x11.c:5554 drawable is not a native X11 window
(gnome-maps:21017): Gdk-WARNING **: /build/gtk+3.0-Tod2iD/gtk+3.0-3.22.0/./gdk/x11/gdkwindow-x11.c:5554 drawable is not a native X11 window
(gnome-maps:21017): Gdk-WARNING **: /build/gtk+3.0-Tod2iD/gtk+3.0-3.22.0/./gdk/x11/gdkwindow-x11.c:5554 drawable is not a native X11 window
(gnome-maps:21017): Gdk-WARNING **: /build/gtk+3.0-Tod2iD/gtk+3.0-3.22.0/./gdk/x11/gdkwindow-x11.c:5554 drawable is not a native X11 window
(gnome-maps:21017): Gtk-WARNING **: GtkClutterOffscreen 0x4c4f3f0 is drawn without a current allocation. This should not happen.
(gnome-maps:21017): Gtk-WARNING **: GtkImage 0x4ed4140 is drawn without a current allocation. This should not happen.
Now I m not sure whether all of those are gtk3+ issues or me running them under Debian MATE. I know that there are issues with mate and gtk3+ as had been told/shared a few times in p.d.o.
Anyways, one of the issues I encountered is that gnome-maps doesn t work in offline-mode, saw https://bugzilla.gnome.org/show_bug.cgi?id=708799 . Also saw ~/.cache/champlain/osm-mapquest and the listing underneath is gibberish in the sense you don t know what it meant to do
[shirish@debian] - [~/.cache/champlain/osm-mapquest] - [10163]
[$] ll -h
drwx------ 6 shirish shirish 4.0K Jun 11 2015 10
drwx------ 26 shirish shirish 4.0K Oct 24 2014 11
drwx------ 10 shirish shirish 4.0K Jun 11 2015 12
drwx------ 11 shirish shirish 4.0K Jun 11 2015 13
drwx------ 12 shirish shirish 4.0K Jun 11 2015 14
drwx------ 12 shirish shirish 4.0K Jun 11 2015 15
drwx------ 27 shirish shirish 4.0K Oct 24 2014 16
drwx------ 25 shirish shirish 4.0K Oct 24 2014 17
drwx------ 4 shirish shirish 4.0K Mar 4 2014 3
drwx------ 5 shirish shirish 4.0K Mar 4 2014 8
drwx------ 9 shirish shirish 4.0K Mar 29 2014 9
What was/is interesting to see things like this
As I was in a moving vehicle, it isn t easy to know if the imagery is at fault or was it app. , sensor of my mobile ?
Did see http://learnosm.org/en/josm/correcting-imagery-offset/ but as can be seen that requires more effort from my side.
The last tool proved to be the most problematic
3. JOSM Getting the tracks into josm which was easily done. While firing up josm came across https://josm.openstreetmap.de/ticket/13735 which I subsequently filed.
One of the other first things which has been a major irritant for a long time is JOSM is, for a lack of better term, ugly. See the interface, especially the one having preferences, all cluttered look and specifically see the plugins corner/tab
The part about it being ugly, I dunno but have seen most java apps are a bit ugly. It is a bit generalist I know but that has been my experience with whatever little java apps. I have used.
I don t know what the reasons for that are, maybe because java is known/rumoured to use lot of memory which seems true in my case as well OR it doesn t have toolkits like gtk3+ or qt quick, although have to say that the looks have improved from before when I used it last some years ago
[shirish@debian] - [~] - [10340]
[$] ps -eo size,pid,user,command awk ' hr=$1/1024 ; printf("%13.6f Mb ",hr) for ( x=4 ; x<=NF ; x++ ) printf("%s ",$x) print "" ' grep josm
0.324219 Mb /bin/sh /usr/bin/josm
419.468750 Mb /usr/lib/jvm/java-8-openjdk-amd64/bin/java -Djosm.restart=true -Djava.net.useSystemProxies=true -jar /usr/share/josm/josm.jar
This is when I m just opening josm and have not added any tracks or done any work.
Now I wanted to explore the routing in good amount of detail on josm. This was easily said than done. When trying to get imagery I got the Download area too large issue/defect . Multiple tries didn t get me anywhere. Then hunting on the web came across the continous-download plugin which is part of the plugin infrastructure . This I found to be a very good tool. It downloads the tiles and puts them in ~/.josm/cache/tiles
[shirish@debian] - [~/.josm/cache/tiles] - [10147]
[$] ll -h
total 28M
-rw-r--r-- 1 shirish shirish 28M Oct 2 02:13 TMS_BLOCK_v2.data
-rw-r--r-- 1 shirish shirish 290K Oct 3 12:59 TMS_BLOCK_v2.key
-rw-r--r-- 1 shirish shirish 4 Oct 3 12:59 WMS_BLOCK_v2.key
-rw-r--r-- 1 shirish shirish 4 Oct 3 12:59 WMTS_BLOCK_v2.key
While unfortunately I cannot see this/make sense of it I m guessing it is some sort of database with key and data files.
What did become apparent is that the OSM needs lots more love if it is to become something which can be used everyday. At the end I had to change the open-source gpx track file to a Google map kml file to be able to make sense as there are whole areas which need to be named, numbered etc.
One of the newbie mistakes that I did was trying to use the slippy map in josm (using Openstreetmap/Mapnik at the back-end) to move/pan using the left-hand mouse button. It took me quite sometime to figure out that it is with right-hand mouse button that you can make the slippy map pan. This is different from almost all maps, gnome-maps uses the traditional left-hand button, Google maps also uses the same. I have filed it in upstream as https://josm.openstreetmap.de/ticket/13751 .
So at least, in these rounds it is gnome-maps which has kind of won even though it doesn t do any of the things that josm claims to do.
I am sure there might be some interesting tricks and tips that people might have to share about mapping
Next.