The APRS digipeater MB7VX has been offline for quite a while now. I’m not going to bring it back any time soon and I have applied for a second NoV to release the frequency and callsign.
Over time, a number of people have contributed to the running of this station. It has been a really fun project and I am sad that it is coming to an end. Thanks go to all the people that have contributed to the construction, installation, configuration, testing and software development that was required to get this station going.
The primary reason for this shutdown is that I do not have the time to deal with all the arguments. The Radio Society of Great Britain (RSGB) has not made it easy to run this station. The Amateur Radio Observer Service (AROS) have also caused unnecessary problems.
For those that may be unaware, RSGB assist licensed radio amateurs in applying for NoVs. This means getting the relevant paperwork from Ofcom to run the station 24⁄7 without me being there. It is also required to allow other amateurs to use the repeater.
The first complaints came from an AROS member who also happened to operate an APRS “IGate” in Aberdeen. To enhance the fun you might have with APRS, it is possible to copy the packets you see to an Internet service. You can then see position reports and messaging at the aprs.fi website, to give one example.
The path that a packet took is interesting. Maybe you were repeated before you get to an Internet-connected station or maybe you’ve got a direct communication with one. As far as I can tell, the AROS member was upset because MB7VX was showing as being the first station to report some mobile stations’ packets and not his.
Here followed a ridiculous debate in which RSGB/AROS were arguing with Ofcom, the regulator, that my license was actually more restrictive than it was. Ofcom (who were the nice people in all this, and I am thankful to those who were dealing with this case) cleared this up and while I didn’t feel that RSGB/AROS had accepted Ofcom’s answer they did somewhat let the matter go.
In a sensible world, this should have been the other way round. RSGB/AROS are meant to be making it easier for radio amateurs to experiment and learn, not harder! At the time, I wrote this blog post which goes in to more detail on the issue.
Later, this AROS member would also jump into conversations we were having and start “educating” us on what we can and can’t do with packet radio. There was talk of moving to another frequency and just having our APRS activity their instead. In the end the usage dropped off and the digipeater mostly sat silent.
At the last renewal of the NoV I was told that the output power would need to be reduced below the point that it would be a useful station. It would still receive packets but the repeated packets wouldn’t be heard. It was RSGB’s view that the goal of APRS was to get your packets to the Internet whereas our group were really more interested in RF to RF communication.
RSGB told me that they were looking to prevent interference that could occur with nearby voice gateways. The fact is that in the whole time the station was operating, I never once received a complaint about interference. I’m also not aware of any voice gateways around the Aberdeen area that even interference would affect. If there were some, I would use them.
So anyway, for now at least, MB7VX is shutdown and I will soon no longer hold the NoV for it.
Note: I wrote this post in the departures lounge at BUD, but it was not posted online until the 25th when I was back home.
I’m really not liking air travel. It makes me ridiculously uncomfortable. Really only one part of it though: security.
Since the introduction of the body scanners in airports, as I have something of an understanding of how they operate, going through security is a pretty terrifying prospect for me. I think that over time it’s got worse too.
My primary objection to them is that in order to function, they necessarily use radio waves that penetrate clothing (what would be the point of them otherwise?) and develop a 3D model of your naked body. Of course, try and put this point of view to the staff and you may get called a liar.
Two airports that have been consistently excellent at dealing with my wish to opt-out of this humiliating and degrading process: AMS and FRA. If you are flying in Europe and you need to go through an airport on the way, then these are my best experiences.
Airports that have been the worst are the London airports. They were so bad that I actually haven’t flown through a London airport since 32c3. Maybe they have improved now, but I’m not holding out much hope.
Despite the fact that you can opt-out of the process there have been two disturbing developments that worry me. One is computer vision. You might notice that in security you are checked without linkage to your identity documents or boarding pass (although depending on the time of day your anonymity set size may vary) and so even if these machines were storing these nude models of everyone going through they are not immediately linkable.
There are assumptions that only hold as long as we also assume that technology will never advance. Policy needs to consider likely futures where things are possible that are not possible today.
Facebook and other companies have been working on face recognition and have large databases of user photos. They even convinced users to tag the photos to provide training data for their facial recognition systems. If one of these machines is accidentally left in debug mode and a large set of these models gets leaked then we’re not that far away technically from identifying each and every person in that set. This could be used for blackmail or just to publicly embarrass someone.
The second development is what has prompted me to write this blog post today. It’s about the layout of the security area. I would have taken a photo but when an ordinary person tries to document such a thing it is considered “hostile reconnaissance” and I didn’t want to have any trouble there. Instead, here is a rough diagram:
|x| v |x| |r| v |r| |a| v |a| |y|-|v|-|y| Metal Detector | | v | | |b| v |b| |e||>v<||e| Body Scanner |l| v |l| |t| v |t|
You’ll notice that whether you opt-out or not you still have to walk through the scanner. All you have to go on is that the light is yellow and not green meaning the scanner is off probably maybe unless I’ve not worked out how the lights work.
I hunched over and ran through it. It was a horrifying experience for me and probably I won’t be coming to this airport again. This is a reminder though that this technology isn’t going away and all the time we are getting closer to just having standoff millimeter wave cameras (which already exist by the way - they just need to be made a bit smaller) with clothes penetrating vision ubiquitously deployed anywhere we currently have CCTV. It will be the new “high definition” or “night vision”.
While TSA and airlines may use the “Automated Threat Detection” (ATD) software there is nothing that technically prevents others from not using it, and that data with the nude image still exists for the ATD software to process.
For more horrifying thoughts about what might happen in the future when the technology catches up, I recommend watching Charles Stross’ talk from 34c3: Dude, you broke the future!.
I’m writing this weekly report early this week as I won’t be around tomorrow to post it. I will be mostly offline next week as I will be at ACM SIGCOMM 2018 in Budapest, Hungary.
Here’s what I’ve been up to:
Lots of Onionoo and Debian packaging this week.
On Monday, we released Onionoo 1.16.1 and deployed this to the official Onionoo instances. This fixed the issue with the serialization of Graph History documents that was breaking history graphs on Relay Search.
On Thursday, we released Onionoo 1.17.0 which contained a fix for the missing reverse DNS names in the details documents. We didn’t deploy this though as a patch was almost ready to fix another issue that had arisen…
When we implemented support for searching for relays in any of a list of AS numbers, we broke support for searching for relays that did not have a known AS number. On Friday we released Onionoo 1.17.1 which contained a fix for this issue and deployed it to the official instances.
I also attended the UX team meeting on Tuesday and the Metrics team meeting on Thursday afternoon.
All my Debian packaging this week was related to Tor. I updated the packaging for:
Additionally, I have reviewed and sponsored an initial upload for sbws, a tool to be used by directory authorities (in the public Tor network, or in test networks) for measuring the bandwidth of Tor relays.
Here’s what I’ve been up to:
Lots of Relay Search and Onionoo this week.
Fixes to the aggregated map and top relays views were made to complete changes that had happened elsewhere in the codebase but not been kept in sync here. Unfortunately there is a little too much logic in Relay Search that really should be handled by the backend which has lead to code duplication in places.
There are now experimental and outdated additional flags for relays as more specific versions of the “Not Recommended” additional flag. While the “Not Recommended” flag is based on an assertion by the directory authorities, there is logic in Onionoo to perform version number comparisons to decide if a relay is experimental or outdated. A recent CollecTor error meant that Onionoo had not been specifying recommended versions, which led all relays to be deemed as “Not Recommended”. It is now assumed that all relays run recommended versions unless specifically asserted that they do not.
Finally, Relay Search views will display the Onionoo protocol version and build revision in the footer of the page which can be useful when reporting errors or bugs.
In order to implement the new experimental and obsolete flags, those icons needed to be finished. They are finalised for now as:
Experimental and Outdated Icons
we changed the way we configure Jackson (a JSON library for Java) in Onionoo.
This change was made to the
Document base class but what we had missed is
GraphHistory documents don’t inherit from this base class. As a
result, they were incorrectly configured.
The Onionoo protocol specifies the format for timestamps in graph history documents (for example: bandwidth, weights or clients documents) but Onionoo stopped formatting these correctly and instead starting writing integer timestamps. (See #27039)
In order to fix this, it will be necessary to rewrite the data that is currently stored on the Onionoo servers. In order to get this right the first time, I have set up a local Onionoo instance with the data directory stored in a ZFS dataset. This allows me to easily roll back changes to match the state that the actual Onionoo servers will be in in an almost zero-cost operation.
I’m still playing with using ZFS snapshots for testing like this, but I think it may become a very useful tool for checking potentially dangerous changes before we deploy.
I also attended the Metrics team meeting on Thursday afternoon.
Looking at my blog today, I noticed that Netlify now warns you if you link to non-HTTPS URLs in your site:
2:37:56 PM: Starting post processing 2:37:56 PM: Mixed content detected in: /blog/index.html 2:37:56 PM: --> insecure link urls: 2:37:56 PM: - http://w6d6vblb6vhuqxt6.onion/blog/ 2:37:56 PM: - http://tvin5bvfwew3ldttg5t6ynlif4t53y3mbmb7sgbyud7h5q6gblrpsnyd.onion/blog/ 2:37:56 PM: - http://creativecommons.org/licenses/by-nd/4.0/
This is really handy in catching those URLs you’ve forgotten to make into HTTPS URLs, but Tor Project exempts .onion hostnames from mixed content warnings (see Tor ticket #23439) and this is even applied upstream by Mozilla in Firefox (see Mozilla ticket #1382359).
I’ve fixed the link for the Creative Commons license in my template, but those .onion links are correct and I generate them for every page in my website. I hope Netlify will update this new feature to treat .onion hostnames as secure regardless of the use of HTTPS as Tor Project and Mozilla do. There’s just too much output for me to go through and ignore for this to reach it’s full potential for me.
Here’s what I’ve been up to:
This week has been more reviews than writing code.
To simplify the Onionoo codebase and remove redundant data from the documents, the 3-month graphs will now become 6-month graphs and the 1-month graphs will be dropped. I have been reviewing changes for this in Onionoo and ensuring that Relay Search is prepared for the changes.
I need to extend the icons used by Relay Search (also part of the styleguide) to add new icons for “Experimental” and “Obsolete” relays. I’ve had a first run at this and will be refining the ideas next week.
I reviewed changes to the statistics CSV files that are made available through Tor Metrics. There are some big changes coming up, see #25383 for details.
I also attended a catch up meeting with Open Rights Group to discuss local activities on Thursday morning, and the Metrics team meeting on Thursday afternoon.
Here’s what I’ve been up to:
This week has been more reviews than writing code.
The plan for implementation of this has now been solidified following discussion at the Metrics team meeting.
I have begun working on packaging vanguards for Debian, including looking at issues in its dependencies in Debian.
I reviewed a number of Onionoo tickets and made a triage pass over new Relay Search tickets.
I also attended the Metrics team meeting on Thursday.
Most of my Debian activities this week have been related to the packaging of vanguards as mentioned above.
I hosted the monthly Cryptonoise event at 57North Hacklab which had taken a break, but should now return as a regular event. Unfortunately I should be at EMF for the next scheduled date, so either I need to find someone to cover or the next event will have to be a virtual one.
Here’s what I’ve been up to:
In order to ensure metrics-bot remains maintainable, I have now increased the JavaDoc coverage for metrics-bot to 100% of the non-trivial public interfaces.
On Monday 16th, the Metrics Team released Onionoo 1.15.0 which implements Onionoo protocol version 6.1 (a minor bump from the previous release).
I’ve been reading through the metrics-web codebase to better understand how the different parts fit together.
I’ve been working on including OONI’s vanilla Tor reachability data in Tor Metrics, and have a good idea of how to implement this now but haven’t yet implemented anything.
I also attended the UX team meeting on Tuesday and the Metrics team meeting on Thursday.
Here’s what I’ve been up to:
A few fixes for Relay Search. These were all small fixes but hopefully should also be quite high impact for usability.
The improvements to Onionoo’s reverse DNS resolver have now been finalised and merged. The plan is that this will be deployed next week.
I have added support to Onionoo to search for relays that do not have known countries or autonomous system numbers.
The old bridge authority has been retired, and a new bridge authority set up: Serge. I produced a tiny patch for CollecTor to allow it to recognise this new bridge authority and reviewed the pre-release tarball for CollecTor 1.7.0. This is now released and deployed.
I’ve been improving the JavaDoc coverage, and have also increased the maximum length of tweets to match Twitter’s new 280 charachter limit (some autonomous systems have long names).
I reviewed patches for metrics-lib, CollecTor and Onionoo.
I also attended the Metrics team meeting on Thursday.
Since my last weekly update, I have uploaded new Debian packages for:
I reviewed and merged improvements to the installation instructions for hellfire. I also reviewed and merged a rate limiter for hellfire, and made it configurable via a command-line option.
Last week when I found myself with my Internet connection down, I tried to use
my EE LTE connection to work instead. This plan fell apart
quite quickly when I discovered that
*.torproject.org was blocked as 18+
I found using the Open Rights Group’s tool, blocked.org.uk, that in fact a large number of UK ISPs have these wildcard blocks in place. This tool also provides a means to report misclassification and so I submitted requests to unblock the following domains:
It is important to note that none of these domains host copies of Tor clients, Tor Browser or anything that would enable to use Tor. They only host data about the public Tor network.
Sky Broadband were the first to respond to say that they had passed on the queries to Symantec, but I’ve not heard anything back from them yet.
Then EE responded today and it seems they also use Symantec to provide their block lists:
I have checked the classification of http://collector.torproject.org with Symantec who classify websites on EE’s behalf and they say that the site is correctly classed as a ‘Technology and Anonymizer’ website which means it can only be seen by adult EE users who have turned their parental controls off.
I’m not sure about the classification here, does this include all “Technology” websites?! They go on to say:
Symantec says the website offers Tech solutions and mainly the download of Tor browser. From their website: “Tor is an effective censorship circumvention tool, allowing its users to reach otherwise blocked destinations or content.” There will be no change at this point.
I hope this helps clarify the situation and that you understand that EE does not decide what sites are behind parental controls but follows guidelines drawn up by the BBFC.
This is nonsense. These sites provide recent and historical data relating to the public Tor network and do not provide access to circumvention software.
Symantec has not checked the domains that I have reported. While there may be a case for blocking the homepage, blocking all subdomains is a case of overblocking and general laziness.
I was interested to see the guidelines from the BBFC, so I looked up their website. I noticed that I could participate in a survey to influence the guidelines for the future, so I thought I’d have a go at that:
So that’s not a great start. I click next and then:
Thanks for answering those questions, unfortunately based on the answers provided you do not qualify for this survey. We appreciate the time taken to provide us with your opinions.
I guess that a secure connection wasn’t required after all.
Taken during a lunchtime walk; Garthdee along the river path, sometime over May 2018.
On yet another Dee walk, I was forced to skip over a cheeky alloy snek as he clackered across my arid path. This species's young has developed a bad name in industry as it is often found inside jammed shopping trolly wheels, being attracted to the maternal anti-theft magnets installed therein.
Its also been a while that I last blogged, so I thought I would kill two birds with one diamond laser and post an update. See graph.
It has been up and down with the generation rate but it has surpassed the conservative expectation that the installer gave me. Quite pleasing. The generation estimate was made against the avg Aberdeen sunlight hours, direction of panels, angles etc and the performance tracks the avergate sunlight hours/day nicely - below, yellow line.
The sunlight hours highs are May followed by August, which appears odd at first (July being the hottest month) until you realise heat and sunlight are not the same thing. It does make me want to investigate all this talk on micro heat-powered Sterling engines I hear so much about. These are dinky blacker-than-black heat traps that expand and contract gasses to drive turbines that generate UnLiMeD POWER!!@%@45£!
At a 60% to 70% efficancy rating, Sterling engines kick solarpanels and their 20% max efficancy off the ballpark. They are more complicated I am given to understand, however the clever dicks are working on the problem and hope to have something investors can overspeculate on soon . When done, we can call China and ask actual ballparks of them - hurrah.
As Warren Ellis recently mentioned: once upon a time if your kink was one in a million you needed to be in a fairly big city to find a single digit number of people who might be on the same page.
Finding them was a non-trivial exercise.
Those days are past (but recent enough that I can remember them).
The internet now connects 3.something billion people. A one in a million kink lumps you in with a few thousand people. And they're only a Google search away.
You need to be a couple orders of magnitude further off the beaten track if you want to stand out these days.
There are a load of sort of generic tv boxes on ebay with an Intel x5-z8350 processor.
The x5 SOC (formerly Cherry Tree, formerly Cherry View) is the same family as the SOC in my beloved GPD Pocket. I was really having trouble with the i2c hardware in the GPD Pocket and wanted something I could take apart and poke with an oscilloscope. I looked first at the UP Board, an x5-z8350 in a raspberry pi form factor, but not only was it much more expensive than this tv box, but it has a CPLD between the SOC io and the pin header.
First I needed to get the board to boot from USB, the listing I bought came with both android and windows 10 (I guess that is what dual os means). In both android and windows 10 there was a handy reboot to other os application.
From installing on the GPD Pocket I suspected that the bios boot menu key would be F7 so I used that. Windows 10 also includes a handy reboot to uefi config option which makes it easy to get into a bios menu. I used it to disable quiet boot and set the boot delay to a more sensible number.
With those changes I rebooted and got a familiar AMI bios boot screen hit F7
and choose your usb stick from the menu. The FreeBSD loader menu came up and
continued into a boot from the usb stick, but it hung probing
I found a solution on the freebsd forum post about the upboard which suggested running:
OK unset hint.uart.1.at
at the loader prompt. With that you I could boot and do an install.
Before you reboot make sure to make that change permanent, by removing this
... hint.sc.0.flags="0x100" #hint.uart.0.at="isa" # comment this line out hint.uart.0.port="0x3F8 hint.uart.0.flags="0x10 ...
I setup the the
drm-next-kmod driver, but the machine froze during boot.
Next I tried using a frame buffer driver, which required the collowing config
in /usr/local/etc/X11/xorg.conf.d/driver-scfb.conf :
Section "Device" Identifier "Generic FB" Driver "scfb" EndSection Section "Device" Identifier "Card0" Driver "scfb" EndSection
The box has:
The x5 box also has bluetooth and wifi, but neither currently have FreeBSD drivers.
Internally there are a whole bunch of unpopulated things that might be interesting.
On the top left there is an unpopulated 2.54mm pin header slot next to the led, silkscreen on the board has 1 and a 7 on either end. Probing around with a multimeter suggested that P7 was ground.
I spent quite a while poking the board with a multimeter and osclloscope to see if any gpio or buses were exposed on the headers or the board. I did find that if you connect pin 1 to gnd (or pin 7) the red led comes on and the board goes off.
I did not find any useful or even really interesting signals.
On the bottom right there is an unpopulate 15 pin header, all but two of these were connect to ground.
Some more gory insides:
Copyright (c) 1992-2018 The FreeBSD Project. Copyright (c) 1979, 1980, 1983, 1986, 1988, 1989, 1991, 1992, 1993, 1994 The Regents of the University of California. All rights reserved. FreeBSD is a registered trademark of The FreeBSD Foundation. FreeBSD 12.0-CURRENT #0 r328126: Thu Jan 18 15:25:44 UTC 2018 firstname.lastname@example.org:/usr/obj/usr/src/amd64.amd64/sys/GENERIC amd64 FreeBSD clang version 6.0.0 (branches/release_60 321788) (based on LLVM 6.0.0) WARNING: WITNESS option enabled, expect reduced performance. VT(efifb): resolution 1920x1080 CPU: Intel(R) Atom(TM) x5-Z8350 CPU @ 1.44GHz (1440.00-MHz K8-class CPU) Origin="GenuineIntel" Id=0x406c4 Family=0x6 Model=0x4c Stepping=4 Features=0xbfebfbff<FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CLFLUSH,DTS,ACPI,MMX,FXSR,SSE,SSE2,SS,HTT,TM,PBE> Features2=0x43d8e3bf<SSE3,PCLMULQDQ,DTES64,MON,DS_CPL,VMX,EST,TM2,SSSE3,CX16,xTPR,PDCM,SSE4.1,SSE4.2,MOVBE,POPCNT,TSCDLT,AESNI,RDRAND> AMD Features=0x28100800<SYSCALL,NX,RDTSCP,LM> AMD Features2=0x101<LAHF,Prefetch> Structured Extended Features=0x2282<TSCADJ,SMEP,ERMS,NFPUSG> VT-x: PAT,HLT,MTF,PAUSE,EPT,UG,VPID TSC: P-state invariant, performance statistics real memory = 2147483648 (2048 MB) avail memory = 1946144768 (1855 MB) Event timer "LAPIC" quality 600 ACPI APIC Table: <ALASKA A M I > WARNING: L1 data cache covers fewer APIC IDs than a core (0 < 1) FreeBSD/SMP: Multiprocessor System Detected: 4 CPUs FreeBSD/SMP: 1 package(s) x 4 core(s) random: unblocking device. ioapic0 <Version 2.0> irqs 0-114 on motherboard SMP: AP CPU #2 Launched! SMP: AP CPU #1 Launched! SMP: AP CPU #3 Launched! Timecounter "TSC" frequency 1440001458 Hz quality 1000 random: entropy device external interface netmap: loaded module [ath_hal] loaded module_register_init: MOD_LOAD (vesa, 0xffffffff80ff8620, 0) error 19 random: registering fast source Intel Secure Key RNG random: fast provider: "Intel Secure Key RNG" kbd1 at kbdmux0 nexus0 cryptosoft0: <software crypto> on motherboard acpi0: <ALASKA A M I > on motherboard Firmware Error (ACPI): Failure creating [BDLI], AE_ALREADY_EXISTS (20180105/dswload-498) ACPI Error: AE_ALREADY_EXISTS, During name lookup/catalog (20180105/psobject-371) ACPI Error: AE_ALREADY_EXISTS, (SSDT: DptfTab) while loading table (20180105/tbxfload-355) ACPI Error: 1 table load failures, 8 successful (20180105/tbxfload-378) acpi0: Power Button (fixed) unknown: I/O range not supported cpu0: <ACPI CPU> on acpi0 cpu1: <ACPI CPU> on acpi0 cpu2: <ACPI CPU> on acpi0 cpu3: <ACPI CPU> on acpi0 attimer0: <AT timer> port 0x40-0x43,0x50-0x53 irq 0 on acpi0 Timecounter "i8254" frequency 1193182 Hz quality 0 Event timer "i8254" frequency 1193182 Hz quality 100 atrtc0: <AT realtime clock> port 0x70-0x77 on acpi0 atrtc0: Warning: Couldn't map I/O. atrtc0: registered as a time-of-day clock, resolution 1.000000s Event timer "RTC" frequency 32768 Hz quality 0 hpet0: <High Precision Event Timer> iomem 0xfed00000-0xfed003ff irq 8 on acpi0 Timecounter "HPET" frequency 14318180 Hz quality 950 Event timer "HPET" frequency 14318180 Hz quality 450 Event timer "HPET1" frequency 14318180 Hz quality 440 Event timer "HPET2" frequency 14318180 Hz quality 440 Timecounter "ACPI-safe" frequency 3579545 Hz quality 850 acpi_timer0: <24-bit timer at 3.579545MHz> port 0x408-0x40b on acpi0 pcib0: <ACPI Host-PCI bridge> port 0xcf8-0xcff on acpi0 pci0: <ACPI PCI bus> on pcib0 vgapci0: <VGA-compatible display> port 0xf000-0xf03f mem 0x90000000-0x90ffffff,0x80000000-0x8fffffff at device 2.0 on pci0 vgapci0: Boot video device xhci0: <Intel Braswell USB 3.0 controller> mem 0x91700000-0x9170ffff at device 20.0 on pci0 xhci0: 32 bytes context size, 64-bit DMA usbus0 on xhci0 usbus0: 5.0Gbps Super Speed USB v3.0 pci0: <serial bus, USB> at device 22.0 (no driver attached) pci0: <encrypt/decrypt> at device 26.0 (no driver attached) pcib1: <ACPI PCI-PCI bridge> at device 28.0 on pci0 pci1: <ACPI PCI bus> on pcib1 re0: <RealTek 8168/8111 B/C/CP/D/DP/E/F/G PCIe Gigabit Ethernet> port 0xe000-0xe0ff mem 0x91604000-0x91604fff,0x91600000-0x91603fff at device 0.0 on pci1 re0: Using 1 MSI-X message re0: turning off MSI enable bit. re0: Chip rev. 0x4c000000 re0: MAC rev. 0x00000000 miibus0: <MII bus> on re0 rgephy0: <RTL8251/8153 1000BASE-T media interface> PHY 1 on miibus0 rgephy0: none, 10baseT, 10baseT-FDX, 10baseT-FDX-flow, 100baseTX, 100baseTX-FDX, 100baseTX-FDX-flow, 1000baseT-FDX, 1000baseT-FDX-master, 1000baseT-FDX-flow, 1000baseT-FDX-flow-master, auto, auto-flow re0: Using defaults for TSO: 65518/35/2048 re0: Ethernet address: 84:39:be:65:0d:60 re0: netmap queues/slots: TX 1/256, RX 1/256 isab0: <PCI-ISA bridge> at device 31.0 on pci0 isa0: <ISA bus> on isab0 acpi_button0: <Power Button> on acpi0 acpi_tz0: <Thermal Zone> on acpi0 sdhci_acpi0: <Intel Bay Trail/Braswell eMMC 4.5/4.5.1 Controller> iomem 0x9173c000-0x9173cfff irq 45 on acpi0 mmc0: <MMC/SD bus> on sdhci_acpi0 sdhci_acpi1: <Intel Bay Trail/Braswell SDXC Controller> iomem 0x91738000-0x91738fff irq 47 on acpi0 mmc1: <MMC/SD bus> on sdhci_acpi1 uart0: <16550 or compatible> port 0x3f8-0x3ff irq 4 flags 0x10 on acpi0 atkbdc0: <Keyboard controller (i8042)> at port 0x60,0x64 on isa0 atkbd0: <AT Keyboard> irq 1 on atkbdc0 kbd0 at atkbd0 atkbd0: [GIANT-LOCKED] atkbdc0: non-PNP ISA device will be removed from GENERIC in FreeBSD 12. est0: <Enhanced SpeedStep Frequency Control> on cpu0 est1: <Enhanced SpeedStep Frequency Control> on cpu1 est2: <Enhanced SpeedStep Frequency Control> on cpu2 est3: <Enhanced SpeedStep Frequency Control> on cpu3 Timecounters tick every 1.000 msec ugen0.1: <0x8086 XHCI root HUB> at usbus0 uhub0: <0x8086 XHCI root HUB, class 9/0, rev 3.00/1.00, addr 1> on usbus0 mmcsd0: 31GB <MMCHC NCard 4.5 SN 6E7E9160 MFG 06/2017 by 136 0x0003> at mmc0 200.0MHz/8bit/8192-block mmcsd0boot0: 4MB partion 1 at mmcsd0 mmcsd0boot1: 4MB partion 2 at mmcsd0 mmcsd0rpmb: 4MB partion 3 at mmcsd0 mmc1: No compatible cards found on bus WARNING: WITNESS option enabled, expect reduced performance. Trying to mount root from ufs:/dev/mmcsd0p2 [rw]... uhub0: 13 ports with 13 removable, self powered lock order reversal: 1st 0xfffff8000417e240 ufs (ufs) @ /usr/src/sys/kern/vfs_subr.c:2607 2nd 0xfffffe0000e46500 bufwait (bufwait) @ /usr/src/sys/ufs/ffs/ffs_vnops.c:282 3rd 0xfffff800042a09a0 ufs (ufs) @ /usr/src/sys/kern/vfs_subr.c:2607 stack backtrace: #0 0xffffffff80b2bba3 at witness_debugger+0x73 #1 0xffffffff80b2ba24 at witness_checkorder+0xe34 #2 0xffffffff80a9cbeb at __lockmgr_args+0x88b #3 0xffffffff80dc2565 at ffs_lock+0xa5 #4 0xffffffff810f7af9 at VOP_LOCK1_APV+0xd9 #5 0xffffffff80ba7006 at _vn_lock+0x66 #6 0xffffffff80b9599f at vget+0x7f #7 0xffffffff80b87891 at vfs_hash_get+0xd1 #8 0xffffffff80dbe25f at ffs_vgetf+0x3f #9 0xffffffff80db4886 at softdep_sync_buf+0xd16 #10 0xffffffff80dc3354 at ffs_syncvnode+0x294 #11 0xffffffff80d999ff at ffs_truncate+0x6df #12 0xffffffff80dca7f1 at ufs_direnter+0x641 #13 0xffffffff80dd393c at ufs_makeinode+0x61c #14 0xffffffff80dcf5b4 at ufs_create+0x34 #15 0xffffffff810f51d3 at VOP_CREATE_APV+0xd3 #16 0xffffffff80ba6908 at vn_open_cred+0x2a8 #17 0xffffffff80b9f14c at kern_openat+0x20c ugen0.2: <Dell Dell USB Entry Keyboard> at usbus0 ukbd0 on uhub0 ukbd0: <Dell Dell USB Entry Keyboard, class 0/0, rev 1.10/1.15, addr 1> on usbus0 kbd2 at ukbd0 ugen0.3: <SanDisk Cruzer Fit> at usbus0 umass0 on uhub0 umass0: <SanDisk Cruzer Fit, class 0/0, rev 2.00/2.01, addr 2> on usbus0 umass0: SCSI over Bulk-Only; quirks = 0x8100 umass0:0:0: Attached to scbus0 da0 at umass-sim0 bus 0 scbus0 target 0 lun 0 da0: <SanDisk Cruzer Fit 2.01> Fixed Direct Access SPC-4 SCSI device da0: Serial Number 4C530302741216116074 da0: 40.000MB/s transfers da0: 3819MB (7821312 512 byte sectors) da0: quirks=0x2<NO_6_BYTE> re0: link state changed to DOWN GEOM_PART: integrity check failed (da0s4, BSD) GEOM_PART: integrity check failed (ufsid/5a1180062a826673, BSD) GEOM_PART: integrity check failed (diskid/DISK-4C530302741216116074s4, BSD)
I seem to collect chrome tabs. I usually have a few dozen open, often many more if I haven't cleaned them out for a while. Once upon a time reboots would clear them out but these days I reopen the previous session when I boot so tabs don't go away unless I actually tell them to. Lots of them do stuff in the background so chrome ends up using a decent chunk of CPU time. It is almost always at the top of the list in powertop.
Most of the time I don't care about this. If my computer is plugged in then it's fine. When I'm running on battery though I care a lot more. Then when I'm doing something that I don't need the web I put chrome to sleep with
killall -STOP chrome and then when I want it back:
killall -CONT chrome. Bind those two commands to keys and I can stop and start chrome as needed, and when I don't need it it doesn't get to eat my precious battery life.
I think it's about time I got a new camera. I've thought this for a while, but keep baulking at the price of getting something that would be a decent improvement over what I currently have.
I have a Sony A55 at the moment. The internet tells me it was released in 2010, and I think I got mine between Christmas and New Year that year. On the lens side I've a Sigma 18-250 super zoom and a 50mm prime that cover most of what I do and I still have the 18-70 kit zoom from my A200 that I sometimes use as I have close focus filters that fit it and let it get really up close to stuff.
I'd like better performance - noise levels at higher ISOs look much better on more modern cameras, higher res video and not overheating when shooting video would be nice and, though 16 megapixels is usually plenty for what I do more would allow a bit more cropping.
But, the overriding consideration for me getting a new camera is to get something smaller.
My current setup is big enough and heavy enough that I mostly leave it at home - I want something small enough that it would live in my laptop bag (since that comes most places with me), and not be something that I have to think about if it comes or not when I'm travelling.
I definitely want a viewfinder on a camera. I much prefer that to only having a screen - I think it helps to have the picture you're taking be all that you see when composing it. This apparently makes me a bit weird as it seems to be only a small subset of cameras that still have viewfinders.
For the most part the micro 4/3 bodies are a lot smaller than my current camera. The lenses are definitely smaller from targeting the smaller sensor - which has the nice effect of them also being quite a bit cheaper than equivalents for APS-C or 35mm. I really like the Panasonic rangefinder style GX cameras.
APS-C 24 megapixel sensor in quite a compact body. But quite expensive, doesn't do 4K and a disappointing and expensive selection of native lenses.
Seems to be quite expensive for the specs. Again the native lenses have a disappointing selection and look expensive. And they're a pain to find as search results are swamped by "normal" Nikon lenses - "1" is a stupid name for a lens type.
Maybe switch over to Sony E-mount? A6000 looks like it would be a decent step up from the A55. There's a decent amount of E-mount lenses available (though a bit more expensive than micro 4/3) and adaptors to let you use just about anything else. A bit higher res than the best of the micro 4/3 cameras. I was pretty tempted by the A6500 when it came out, but I don't think I want to spend that much and the jelly from the rolling shutter seems particularly bad with it.
If I really want to go all out on small: get something like a Sony Rx100 or Panasonic LX100. These are small enough to put in a pocket or clip onto my belt so could definitely come everywhere with me. I'm not really sold on giving up on interchangeable lenses though.
I think a small normal crossing zoom would be the best bet for usually living on the camera lens. That should give a nice small package for always carrying around and still be reasonably flexible.
I've seen a few reviews of the Olympus 40-150 that say it's quite good and very good for the price: from ~£50 on eBay. If I get a micro 4/3 camera I'll probably get one of these to have something for the longer end. Might not get that right away.
The Panasonic 12-35 f2.8, or Olympus 12-40 f2.8 "premium"/"professional" zooms look really nice, but they start at ~£500 on eBay so would eat pretty much all of my budget without getting a camera to put them on.
Micro 4/3 or Sony E-mount have a pretty small flange to sensor distance and with the sensors being quite small (especially micro 4/3) you can get adaptors to use most other types of lenses. There are a lot of really cheap and fast C-mount lenses out there, and some old M42 lenses look quite nice. C-mount extension tubes look fun for some macro stuff.
Metabones Speed Booster gives a 0.71x focal length multiplier (on the ultra, 0.64 on XL variants) to allow full frame lenses to be used while kind of counteracting the crop from the small sensor and making the lens about a stop faster. The metabones version is quite expensive (and not widely available - I haven't yet found any for sale in Europe), there are a couple of cheaper alternatives, but reviews I've seen have been fairly negative for them. Since, to me, the whole point of this kind of adaptor would be to use some of the nice older lenses the adaptor adding issues would kind of spoil that. If I can live with distortion and vignetting C-mount lenses at about equivalent speeds are a couple of orders of magnitude cheaper. Some nice older lenses on a Speed Booster is fun to fantasise about but is probably still more expensive than I'm likely to spend in the near future.
A Speed Booster would let me get some fast older manual primes and make them even faster. Or there are versions that support modern AF lenses but those adaptors are more expensive and the lenses tend to be lots more expensive.
I was a bit worried about the crop factor taking away some of the wide end. My current widest lens is 18mm on the wide end of my kit and super zooms - adn I have often wanted something a bit wider than that. On my APS-C camera that comes in at about 29mm full frame equivalent. Need about 14mm to match that so the cheap standard zooms are about what I currently have and the premium/pro/bloody expensive standard zooms would be a bit wider. EBay has some cheap C-mount lenses out to 7mm without being listed as fisheye but they might have enough distortion that they actually would be fisheye in my book.
I'm still havering. I have bid on a couple of GX7s on eBay but other people seem to think they're worth more than I do, so haven't won them. I'm really surprised how much they go for, only £50-100 less than a GX80 (and second hand GX80s are surprising close to new ones - the higher end of the range are listing them above the new price on Amazon). I think the improved detail from the GX80 not having the low-pass filter makes it worth the extra over the GX7.
So, I'm currently leaning towards a Panasonic GX80 with the kit zoom and a couple of C-mount manual primes. Can maybe upgrade to native, or M42 primes later. I think I'll spend a while watching them on eBay but it is very tempting to push the button on Amazon to get one tomorrow...
In the distant past before smart phones became identical black rectangles there was a category of devices called palmtops. Palmtops were a class of PDA PC thing that fit in the palm of your hand. Today the Psion 5 series of devices most often capture peoples attention. Not only are they small and awesome, but they have something like a real keyboard.
This form factor is so popular that there are projects trying to update Psion 5 devices with new internals. The Psion 5 is the sort of device I have complained isn't made for a long time, at some point I picked one up on ebay with the intention of running the NetBSD port on it.
Earlier this year the world caught up and two big crowd funding projects appeared for modern Psion like palmtop devices. Neither the Gemini or the GPD Pocket campaigns convinced me that real hardware would ever appear. In May reviews of the GPD Pocket started to appear and I became aware of people that had backed and received their earlier campaign for the GPD WIN.
With a quirk in indiegogo allowing me to still back the campaign I jumped on board and ordered a tiny little laptop computer.
FreeBSD is the only choice of OS for a pc computer. Support is good enough that I could boot and install without any real issues, but there was enough hardware support missing that I wanted to fix things before writing a blog post about it.
Somethings don't work out of the box others will need drivers before they will work:
The most obvious issue is the display panel, the panel it self reports as being a high resolution portrait device. This problem exists in the bios menus and the windows boot splash is rotated for most of the time.
Of course the FreeBSD bootsplash and framebuffer are also rotated, but a little neck turning makes the installer usable. Once installed we can address the rotated panel in X, accelerated graphics are probably in the future for this device, but the X framebuffer drive is good enough for FreeBSD hacking.
With X we can sort of the rotation problem.
xf86-video-scfb is required to
use the framebuffer.
# pkg install xf86-video-scfb
And the following lines have to be added to
Section "Device" Identifier "Generic FB" Driver "scfb" Option "Rotate" "CW" EndSection Section "Device" Identifier "Card0" Driver "scfb" EndSection
The screen resolution is still super high, there doesn't seem to be anyway to do DPI hinting with the framebuffer driver (or in i3 at all), but I can make terminals usable by cranking up the font size.
A Keyboard is vital for a usable computer, out of the box the keyboard works, but the touch point does not. Worse, touching the touch point caused the built in USB keyboard to die.
Some faffing trying to debug the problem with gavin@ at BSDCam and we got both keyboard and mouse working. For some reason my planck keyboard presents as a mouse among other things, pluggin in a mouse and power cycling the USB device caused ums(4) to correctly probe and attach.
ums(4) at boot got the touch point working correctly. In
ig4(4) also attaches when manually loaded.
Add these lines to
The dmesg shows some problems with ACPI probing, this is probably the source of some of the device problems.
Wifi, bluetooth and graphics are bigger problems that will hopefully be caught up in others work and made to work soon. The touchscreen controller is adding a driver and support for Cherry View GPIO, there are datasheets for these and I am working on them.
No battery level indicator makes it annoying to use the GPD Pocket out and about. Without a driver the charge controller is using a really low current to recharge the battery. Datasheets are quite readily available for these devices and I am writing drivers now.
The Pocket is a great little device, I think its 'cuteness' makes everyone fall in love with it on first sight. I am really looking forward to getting the final things working and using this as a daily device.