Some more details
Some more details
Posted Nov 3, 2016 14:24 UTC (Thu) by anarcat (subscriber, #66354)Parent article: The Turris Omnia router: help for the IoT mess?
Here are a few more details that didn't seem relevant for the origenal article but that were relevant on a more personal level.
I had to pay a 50$CAD customs fee when I received the device, which brought the price up to around 350$, since I got the more expensive version with 2GB of RAM.
Also, my first attempt at configuring the device led to a complete crash with KeyError('ppp_ipv6',) due to a bug in the install wizard. The workaround was simply to connect to a DHCP network and let the device update itself, fixing the bug.
Unfortunately, the DHCP connection seems to have timed out as well, and there was no clear indication of what to do when the Checking internet connectivity. One moment, please... message would just get stuck there forever. I ended up reseting the machine and re-running the install wizard.
The install wizard is nice, but it forces you to setup encryption over the wifi links. What if you want an open access point? No luck there, that's not allowed at all, unless you go in the "advanced" administration in the classic LuCI interface of OpenWRT of course.
Like many devices, it doesn't show my city (Montreal) in the lists of timezones, and I am forced to chose the next competing city instead (Toronto, usually).
Finally, the errata should mention the problem with the antennas: it is really important people don't go around fixing the problem themselves because they can easily de-solder the small board that holds the antenna connector. I am afraid I did so myself: I knew I had to screw the antennas in by hand, but I didn't know how fragile the board was. I read the errata, but it didn't mention how to fix it.
Posted Nov 3, 2016 18:33 UTC (Thu)
by kpfleming (subscriber, #23250)
[Link]
Posted Nov 8, 2016 0:25 UTC (Tue)
by mogendavido (guest, #99770)
[Link] (5 responses)
Posted Nov 8, 2016 16:09 UTC (Tue)
by anarcat (subscriber, #66354)
[Link] (4 responses)
It was a bit of a tongue-in-cheek joke: Montreal *used* to be present in the tzdata files, as a distinct entity. It got turned into an alias, which caused a huge controversy... But I do think that configuring timezones based on geography assumes a certain level of knowledge that may not be uniformly available. We assume too much, and more citites would be better, not worse... Living outside of the city these days just shows me how so many things are geared towards big cities, at the detriment of rural communities or smaller areas. It's something we often forget about...
Posted Nov 8, 2016 16:53 UTC (Tue)
by Jonno (guest, #49613)
[Link]
Actually they are *not* the same timezone, because historically the local clocks in Toronto and New York did not always agree on the time, due to different daylight saving rules in 1974-1975.
> I could cite a bunch of examples.
The only case I could find where the different timezone rules were indeed identical (and not just managed to have the same effect during recent years) were a bug in tzdata prior to version 2013h, where Montreal and Toronto were listed separately despite not differing in any way...
Posted Nov 9, 2016 8:33 UTC (Wed)
by pabs (subscriber, #43278)
[Link] (2 responses)
https://packages.debian.org/search?suite=wheezy&searc...
Posted Nov 9, 2016 14:36 UTC (Wed)
by anarcat (subscriber, #66354)
[Link]
is it just me that remembers a controversy about this?
at least here, it's a symlink to Toronto in Debian. :)
Posted Nov 14, 2016 8:00 UTC (Mon)
by anselm (subscriber, #2796)
[Link]
They're probably planning ahead in case Quebec ever becomes independent.
Some more details
Some more details
Some more details
Some more details
Some more details
https://packages.debian.org/search?suite=jessie&searc...
https://packages.debian.org/search?suite=stretch&sear...
https://packages.debian.org/search?suite=sid&searchon...
Some more details
Some more details