Disclaimer: I am in no way affiliated with the POSM or its development. I’m just an OSM contributor who thought this was neat and wanted to share the love.
For a while I’ve been envisioning some sort of system that would allow map data to be collected over a large area and then committed and later shared without an Internet connection. Going into a rural area without sufficient or existing Internet connectivity would surely be a problem with using tools for compiling and rendering OpenStreetMap (OSM) data. I had come up with a few solutions that were not unique and seems to have been tried before.
Yep, just toss your GPS tracks, pictures, and JOSM output onto a USB thumb drive and walk/drive it over to a centralized location, where Internet connectivity is available, for processing. Sure, it might take a while to collect all the information and take a while longer to redistribute all the information to the people in the field but it works.
Okay, being a network geek this is my favorite solution; build your own network! For the record, I’m not talking about stringing wire from village to village like soldiers did around Europe in WWII. No, I’m talking about building wireless MANs to connect wired/wireless LANs that may already exist in these villages (or we can build our own!).
Adding our own infrastructure (email, web, and other servers) to the network would provide basic communications between villages with a potential connection to the Internet from a faraway town.
But this is far from fun for a software geek (I’m not one of those). From here enter the POSM.
The Portable OpenStreetMap, or POSM, device is a small server that hosts all the tools needed to compile, edit, and publish collected mapping data without Internet connectivity. The project was discussed at the US State of the Map (2016) and the video is a must-watch.
Of course a POSM could be added to either a Sneakernet or Intranet to allow for distributed data to be collected faster but the POSM, alone, seems to make working with this data much easier in the field.
Back to my thoughts
Honestly, my first thoughts around making a box like this, even before I heard about POSM, was the syncing of data back to the master OSM database. If you watched the video to the end it appears someone else in the crowd had the same concern. The answer to this was the use of git to manage conflicts. To me this is very smart as git was made for this type of use-case (distributed data that needs to be compiled together at a core location).
I do wonder how well POSM would work if you had one in each village with MAN connections between and having the POSMs sync among themselves, sharing the data in near-real time. This would be beneficial as there would be a backup of the data in the event one of the POSM devices died and could add some redundancy. Providing connectivity could also aid in communications between sites through IRC or XMPP.
Lots of ideas… Lots of options…
I’ve been enjoying watching these trends.
This time the results are not really different from past month’s ones. About two percent of servers more use SHA-256 signed certificates and 1% more has configuration that allows negotiation of PFS suites.
Small change to reported results: I’ve added “Insecure” entry which counts the number of servers that will use completely insecure cipher suite like single DES, RC2 or export grade ciphers. It doesn’t include the “controversial but not broken” IDEA and SEED ciphers.
SSL/TLS survey of 402742 websites from Alexa's top 1 million Stats only from connections that did provide valid certificates (or anonymous DH from servers that do also have valid certificate installed) Supported Ciphers Count Percent -------------------------+---------+------- 3DES 349454 86.7687 3DES Only 164 0.0407 AES 374868 93.0789 AES Only 1017 0.2525 AES-CBC Only 553 0.1373 AES-GCM 172322 42.7872 AES-GCM Only 7 0.0017 CAMELLIA 170577 42.3539 CHACHA20 15137 3.7585 Insecure 79666 19.7809 RC4 355750 88.332 RC4…
View original post 1,216 more words
This is awesome news. Passing it along.
After everybody said not to use RC4 any more, Google finally enabled one additional cipher on Google video servers: TLS_RSA_WITH_AES_128_GCM_SHA256.Unfortunately, this cipher is not supported either by Firefox 30 nor by Internet Explorer on Windows 8.1 or earlier.
Users of Firefox will have to wait for the bug 1029179 to be fixed.
This cipher is though supported by Google Chrome and Chromium, so if you’re a user of those browsers, you can finally disable RC4 for everyday browsing. You can do it either by creating a wrapper script, or modifying the shortcut you use to run those browsers to have one additional option:
This will disable following cipher suites:
- 0x0003 – TLS_RSA_EXPORT_WITH_RC4_40_MD5
- 0x0004 – TLS_RSA_WITH_RC4_128_MD5
- 0x0005 – TLS_RSA_WITH_RC4_128_SHA
- 0x0017 – TLS_DH_anon_EXPORT_WITH_RC4_40_MD5
- 0x0018 – TLS_DH_anon_WITH_RC4_128_MD5
- 0x0020 – TLS_KRB5_WITH_RC4_128_SHA
- 0x0024 – TLS_KRB5_WITH_RC4_128_MD5
- 0x0028 – TLS_KRB5_EXPORT_WITH_RC4_40_SHA
- 0x002B – TLS_KRB5_EXPORT_WITH_RC4_40_MD5
- 0x0066 – SSL_DHE_DSS_WITH_RC4_128_SHA
- 0x008A – TLS_PSK_WITH_RC4_128_SHA
- 0x008E – TLS_DHE_PSK_WITH_RC4_128_SHA
- 0x0092 –…
View original post 87 more words
The WordPress.com stats helper monkeys prepared a 2013 annual report for this blog.
Here’s an excerpt:
The concert hall at the Sydney Opera House holds 2,700 people. This blog was viewed about 34,000 times in 2013. If it were a concert at Sydney Opera House, it would take about 13 sold-out performances for that many people to see it.
Secure coding advice for dealing with temporary files.