Summer Blooms

Friday, July 24, 2015 

Roses Bird of Paradise Closeup Bird of Paradise Blooms Cactus Blooms

Posted at 13:41:13 UTC

Category: photoweather

Tortuga Stalking the Yard

Thursday, July 23, 2015 

Tortuga Profile

Tortuga quarter

Tortuga facing

Posted at 01:24:04 UTC

Category: catsphoto

A Solution for Mosh Scrollback

Wednesday, July 22, 2015 

Mosh is a pretty good tool, almost indispensable when working in places with crappy internet. While it is designed to help with situations like “LTE on the beach,” it actually works very well in places where internet connectivity is genuinely bad: 1500msec RT, latency, 30% packet loss, and frequent drops in connectivity that last seconds to hours, otherwise known as most of the world. On a good day I lose an SSH connection randomly about every 3-6 hours but I’ve only ever lost a Mosh session when my system went down.

It does a lot of things, but two are key for my use: it syncs user input in the background while local echoing what you type so you can finish your command (and correct a typo) without waiting 1500msec for the remote echo to update; and it creates persistent connections that survive drop off of almost any type except killing the terminal application on one end or the other (anything between can die and when it recovers, you catch up). This means compiles finish and you actually get the output warnings…

…well…

…some of them. Because Mosh’s one giant, glaring, painful, almost debilitating weakness is that it doesn’t support scrollback. So compared to tmux or something else that you can reconnect to after your SSH session drops, you really lose screen content, which is a PITA when ls-ing a directory. I mean, it isn’t that much of an efficiency gain to have to type “ls | less” instead of just “ls” every time you want to see a directory.

I found a solution that works for me. I also use Tmux with Mosh because Tmux will survive a dead client and working with Windows client reboots are a fact of life (I know, sad, but there are some tools I still need on windows, hopefully not for much longer).

Tmux has a facility for creating a local log file, which I then “tail -f” using a separate SSH window. If the SSH client disconnects, no loss, I can pick up the log anytime. It is just mirroring everything that the mosh terminal is doing and the scroll bar scroll back works fine. And it is a raw text file, so you can pipe the output through grep to limit what’s displayed to something of interest and review the log asynchronously as, say, a build is progressing.

Although there are some nice advantages to this, when/if Mosh supports scrollback, it’ll be far more convenient having it in the same window, but for now this is the easiest solution I could come up with.

FreeBSD:

# portmaster sysutils/tmux
# portmaster net/mosh
# ee ~/.tmux.conf
-> bind-key H pipe-pane -o "exec cat >>$HOME/'#W-tmux.log'" \; display-message 'Logging enabled to $HOME/#W-tmux.log'
-> set -g history-limit 30000
Start a Mosh session (for example with Mobaxterm on windows)
# tmux
# [CTRL]-b H
start SSH session (Mobaxterm or Putty on windows)
# tail -f csh-tmux.log
("csh" will be the name of the mosh window - so really "(MoshWindowName)-tmux.log"

You can tmux the ssh session too and still have scrollback and then just reconnect into the same tail command, which preserves the whole scrollback. If you’re on a connection like I’m on, your scrollback logfile will drop off a couple of times a day, but you won’t lose your Mosh session, and it’ll be waiting for you when you’re reminded that you need to see those security warnings from the compile that just scrolled off the Mosh screen forever.

Posted at 00:57:12 UTC

Category: FreeBSDHowToLinuxtechnology

The Avocado Tree is Fruiting

Tuesday, July 21, 2015 

A couple of years back a random sprout appeared in the yard. It looked like a volunteer avocado and grew bizarrely fast. After a few years, it is about 15′ tall and this year it fruited for the first time. It really is an avocado tree.
 

Avacado Tree Fruiting

 

Posted at 23:15:30 UTC

Category: photo

The CA System is Intractably Broken

Tuesday, July 21, 2015 

I’m dealing with the hassle of setting up certs for a new site over the last few days. It means using startcom’s certs because they’re pretty good (only one security breach) and they have a decently low-hassle free certificate that won’t trigger BS warnings in browsers marketing fake cert mafia placebo security products to unwitting users. (And the CTO answers email within minutes well past midnight.)

And in the middle of this, news of another breach to the CA system was announced on the heels of Lenovo’s SuperFish SSL crack, this time a class break that resulted in a Chinese company being able to generate the equivalent of a lawful intercept cert and provided it to a private company. Official lawful intercept certificates are a globally used tool to silently crack SSL so official governments can monitor SSL encrypted traffic in compliance with national laws like the US’s CALEA.

But this time, it went to a private company and they were using it to intercept and crack Google traffic, and Google found out. The absurdity is to presume that this is an infrequent event. Such breaches (and a “breach” isn’t a lawful intercept tool, which are in constant and widespread use globally, but such a tool in the “wrong” hands) happen regularly. There’s no data on the ratio of discovered breaches to undiscovered breaches, of course. While it is possible that they are always found, seemingly accidental discoveries suggest far wider misuse than generally acknowledged.

The cert mafia should be abolished. Certificate authorities work for authoritarian environments in which a single entity is trusted by fiat as in a dictatorship or a company. The public should trust public opinion and a tool like Perspectives would end these problems as well as significantly lower the barrier to a fully encrypted web as those of us trying to protect our traffic wouldn’t need to choose between forking over cash to the cert mafia for fake security or making our users jump through scary security messages and complex work-arounds.

Posted at 00:53:59 UTC

Category: FreeBSDPrivacySecuritytechnology

A sad loss for security

Monday, July 20, 2015 

Whisper systems wrote the very useful TextSecure app for Android. It had a great feature of encrypting text messages, a standard communication modality in much of the world and one I rely on often. I have previously suggested it is a good tool.

The last “update” removed the ability to establish new encrypted chats over SMS and, it appears, the next will remove the function entirely. For me, this change substantially reduces the utility of the app.

Reading their arguments for doing so, I find myself disagreeing with their justifications. I understand there was some complexity in establishing encrypted SMS, but frankly initiating a one-time key exchange was about as easy as encrypted communication gets. That iOS users can’t play along is pretty irrelevant: iOS isn’t exactly the platform for secure communications anyway, you carry iOS devices when you want to impress people with your brand awareness, not get things done. That people occasionally end up with a conversation that is half-encrypted seems annoying but hardly all that problematic. The person that uninstalled the app will try to send messages in the clear, not the person who is still running it and a partial session. I can see the annoyance, but not any security leak.

I think the final result is somewhat dangerous. The first incarnation used SMS as the starting point, and once a secure communications were established, if available, coms moved transparently to the data channel. If not, it stayed with SMS. As I work in a place where data service is frequently disabled, this was the most reliable non-voice communication protocol.

Now SMS is unencrypted and data-mode communication is encrypted. You have to remember which is which and that is dangerous.

If they don’t restore encrypted SMS functionality, I will switch back to the standard SMS app, which is insecure SMS only and so not confusing and use chat secure or xabber for encrypted data communications so the difference is clear. You’re probably going to run a jabber-based chat tool anyway chat secure’s Tor integration makes it a better choice for data-mode chat while text secure no longer does anything particularly useful over the default app for SMS-mode nor anything particularly unique for data mode.

Posted at 00:53:41 UTC

Category: cell phonesSecurity

Low Voltage LED Lighting

Monday, July 13, 2015 

My kitchen has had halogen lighting for 20 years, from back when it was a slightly more efficient choice than incandescent lighting and had a pleasing, cooler (bluer, meaning the filament runs hotter) color temperature.

LEDs Installed

Progress has moved on and while fluorescent lights still have a lead in maximum luminous efficacy (lm/w), for example the GE Ecolux Watt-Miser puts out 111 lm/W, they’re less versatile than LEDs and installation is a hassle while low voltage LEDs are easy to install and look cool.

System Design

The goal of this project was to add dimmable, pleasing light to the kitchen that I found aesthetically interesting.  I wanted a decent color rendering index (CRI), ease of installation, and at reasonable cost.  I’ve always liked the look of cable lighting and the flexibility of the individual, adjustable luminaires.

I couldn’t find much information on how variable output LEDs work and what can be used to drive them.  I have a pretty good collection of high quality power supplies, which I wanted to take advantage of, but wasn’t sure if I’d be able to effectively dim the bulbs from the documentation I found. So I did some tests.

Test Configuration

I bought a few different 12V, Dimmable LEDs and set up a test configuration to verify operation and output with variable voltage and variable current.  The one bit of data I had was that using standard commercial controllers, the lowest output is typically stated to be around 70% of maximum output: that is the dimming range is pretty limited with standard (PWM/Transformer) controllers.  The results I found were much more encouraging, but revealed some quirks.

I used a laboratory-grade HP power supply with voltage and current control to drive the LEDs, decent multimeters to measure voltage and current, and an inexpensive luminance meter to measure LED output.

I measured 3 different LEDs I selected based on price and expected compatibility with the aesthetics of the project and because they looked like they’d have different internal drivers and covered a range of rated wattage.

Test Results

These bulbs have internal LED controllers that do some sort of current regulation for the diodes that results in a weird voltage/current/output response.  Each bulb has a different turn-on voltage, then responds fairly predictably to increasing input voltage with increasing output, reaches the controller stabilizing voltage and runs very inefficiently until voltage gets over the rated voltage and then becomes increasingly efficient until, presumably, at some point the controller burns out.  I find that the bulbs all run more efficiently at 14V than at the rated 12V.

As a side note, to perform the data analysis, I used the excellent xongrid plugin for excel to perform Kriging interpolation (AKA Gaussian process regression) to fit the data sets to the graphing function’s capabilities.  The graphs are generated with WP-Charts and the table with TablePress.

Watts v. Volts

This chart shows the wattage consumed by each of the three LEDs as a function of input voltage, clearly demonstrating both that the power consumption function is non-linear and that power consumption in watts improves when driven over the rated 12V.  Watts are calculated as the product of the measured Volts * Amps.  Because of the current inversion that happens as the controllers come fully on-line, these LEDs can’t be properly controlled near full brightness with a current-controlled power supply, though it works well to provide continuous and fairly linear dimming at low outputs, once the voltage/current function changes slope, the current limiting controller in the power supply freaks out.

4W LED  5W LED  7.5W LED

Lux v. Volts

This chart shows the lux output by each of the three LEDs as a function of input voltage, revealing the effect of the internal LED driver coming on line and regulating output, which complicates controlling brightness but protects the LEDs.  The 5W LEDs have a fairly gentle response slope and start a very low voltage (2V) so are a good choice for a linear power supply.  The 4W LEDs don’t begin to light up until just over 6V, and so are a good match for low-cost switch mode supplies that don’t go to zero.

4W LED  5W LED  7.5W LED

Lux/W v. Volts

This chart shows the luminous efficiency (Lux/Watt, Lumen measurement is quite complicated) by each of the three LEDs as a function of input voltage, showing that overdriving the LEDs past the rated 12V can significantly improve efficiency.  There’s some risk it will overheat the controller at some point and result in failure.  I’ll update this post if my system starts to fry LEDs, but my guess is that 14V, which cuts the power load by 20% over 12V operation with the 7.5W lamps I selected, will not significantly impact operational lifetime.

4W LED  5W LED  7.5W LED

Total System Efficiency

The emitter efficiency is relatively objective, but the total system efficiency includes the power supply.  I used a Daiwa SS-330W switching power supply I happened to have in stock to drive the system, which cost less than a dimmable transformer and matching controller, and should be significantly higher quality.  The Daiwa doesn’t seem to be easily available any more, but something like this would work well for up to 5A total load and something like this would handle as many as 40 7.5W LEDs on a single control, though the minimum 9V output has to be matched to LEDs to get satisfactory dimming. It is important not to oversize the power supply too much as switch mode supplies are only really efficient as you get close to their rated output.  An oversized switchmode power supply can be extremely inefficient.

With the Daiwa, driving 13 7.5W LEDs, I measured 8.46A at 11.94V output or 101 Watts to brightly illuminate the entire kitchen, and providing far more light than 400W of total halogen lights.  I measured the input into the power supply at 0.940A at 121.3V or 114 Watts.  That means the power supply is 88.6% efficient at 12V, which is more or less as expected for a variable output supply.

Increasing the output voltage to 14.63 Volts lowered the output current to 5.35A or 78 Watts without lowering the brightness at the installation; I measured at 168 lux at both 12.0V at 14.6V. The input current at 14.63V dropped to 0.755A or 91.6 Watts, meaning the power supply is slightly less efficient at lower output currents (as is usually the case).

  • Overdriving the 12V rated LEDs to 14.63V improves plug efficiency by 20%.

At the low end, the SS-330W’s minimum output is 4.88V, which yields 12 lux at the counter or a 14x dimming ratio to 7% of maximum illumination, a far better range than is reported for standard dimmer/transformer combinations.

Parts

Raw Data:

LED_power_graph_data

(MS Excel file, you will need the xongrid plugin to update the data as rendered in the graphs)

Posted at 02:45:36 UTC

Category: FabricationphotoPositivereviewstechnology

Making Chrome Less Horrible

Saturday, June 13, 2015 

Google’s Chrome is  a useful tool to have around, but the security features have gotten out of hand and make it increasingly useless for real work without actually improving security.

After a brief rant about SSL, there’s a quick solution at the bottom of this post.


 

Chrome’s Idiotic SSL Handling Model

I don’t like Chrome nearly as much as Firefox,  but it does do some things better (I have a persistent annoyance with pfSense certificates that cause slow loading of the pfSense management page in FF, for example). Lately I’ve found that the Google+ script seems to kill firefox, so I use Chrome for logged-in Google activities.

But Chrome’s handling of certificates is abhorrent.  I’ve never seen anything so resolutely destructive to security and utility.  It is the most ill-considered, poorly implemented, counter-productive failure in UI design and security policy I’ve ever encountered.  It is hateful and obscene.  A disaster.  An abomination. The ill-conceived excrement of ignorant twits.  I’d be happy to share my unrestrained feelings privately.

It is a private network, you idiots

I’ve discussed the problem before, but the basic issues are that:

  • The certificate authority is NOT INVALID, Chrome just doesn’t recognize it because it is self-signed.  There is a difference, dimwits.
  • This is a private network (10.x.x.x or 192.168.x.x) and if you pulled your head out for a second and thought about it, white-listing private networks is obvious.  Why on earth would anyone pay the cert mafia for a private cert?  Every web-interfaced appliance in existence automatically generates a self-signed cert, and Chrome flags every one of them as a security risk INCORRECTLY.
  • A “valid” certificate merely means that one of the zillions of cert mafia organizations ripping people off by pretending to offer security has “verified” the “ownership” of a site before taking their money and issuing a certificate that placates browsers
  • Or a compromised certificate is being used.
  • Or a law enforcement certificate is being used.
  • Or the site has been hacked by criminals or some country’s law enforcement.
  • etc.

A “valid” certificate doesn’t mean nothing at all, but close to it.

So one might think it is harmless security theater, like a TSA checkpoint: it does no real harm and may have some deterrent value.  It is a necessary fiction to ensure people feel safe doing commerce on the internet.  If a few percent of people are reassured by firm warnings and are thus seduced into consummating their shopping carts, improving ad traffic quality and thus ensuring Google’s ad revenue continues to flow, ensuring their servers continue sucking up our data, what’s the harm?

The harm is that it makes it hard to secure a website.  SSL does two things: it pretends to verify that the website you connect to is the one you intended to connect to (but it does not do this) and it does actually serve to encrypt data between the browser and the server, making eavesdropping very difficult.  The latter useful function does not require verifying who owns the server, which can only be done with a web of trust model like perspectives or with centralized, authoritarian certificate management.

How to fix Chrome:

The damage is done. Millions of websites that could be encrypted are not because idiots writing browsers have made it very difficult for users to override inane, inaccurate, misleading browser warnings.  However, if you’re reading this, you can reduce the headache with a simple step (Thanks!):

Right click on the shortcut you use to launch Chrome and modify the launch command by adding the following “--ignore-certificate-errors

Unfuck chrome a bit.

Once you’ve done this, chrome will open with a warning:

zomg: ignore certificate errors?  who doesn't anyway?

YAY.  Suffer my ass.

Java?  What happened to Java?

Bonus rant

Java sucks so bad.  It is the second worst abomination loosed on the internet, yet lots of systems use it for useful features, or try to.  There’s endless compatibility problems with JVM versions and there’s the absolutely idiotic horror of the recent security requirement that disables setting “medium” security completely no matter how hard you want to override it, which means you can’t ever update past JVM 7.  Ever.  Because 8 is utterly useless because they broke it completely thinking they’d protect you from man in the middle attacks on your own LAN.

However, even if you have frozen with the last moderately usable version of Java, you’ll find that since Chrome 42 (yeah, the 42nd major release of chrome. That numbering scheme is another frustratingly stupid move, but anyway, get off my lawn) Java just doesn’t run in chrome.  WTF?

Turns out Google, happy enough to push their own crappy products like Google+, won’t support Oracle’s crappy product any more.  As of 42 Java is disabled by default.  Apparently, after 45 it won’t ever work again.  I’d be happy to see Java die, but I have a lot of infrastructure that requires Java for KVM connections, camera management, and other equipment that foolishly embraced that horrible standard.  Anyhow, you can fix it until 45 comes along…

To enable Java in Chrome for a little while longer, you can follow these instructions to enable NPAPI (which enables Java).  Type “chrome://flags/#enable-npapi” in the browser bar and click “enable.”

Enable NAPI

Posted at 13:24:37 UTC

Category: HowToSecuritytechnology

Undoing the Job Justifying Efforts of UX Kids

Saturday, June 6, 2015 

If you’re a UX designer on a mature project, you have to justify your pay somehow – design refreshes become a requirement.  If tool companies had UX designers on staff, hammers would look like porcupines.

One of the most annoying features of FireFox V34 was the pop-down search menu.  Nice concept, but if your mouse drifts, you end up searching on twitter or amazon or some other useless thing, or just calling up the idiotic “add search options” dialog.  Srsly.  The search bar is a nice thing, thank you, leave it be.

Fortunately, FF offers a way to undo most of the horrible changes visited on the UI and you can keep it functional and efficient by undoing the damage that treating a program like a fashion plate rather than a tool has wrought.  Classic Theme Restorer is a good example.

Fixing the drop down search menu barf is easy: enter “about:config” in the URL bar and search for “browser.search.showOneOffButtons”  Set the value to “False” and stop being delayed by random search destinations.

Posted at 11:37:13 UTC

Category: technology

Lufthansa Business Class

Friday, February 27, 2015 

I’ve occasionally had to buy business on poorly planned Lufthansa intra-Europe flights. While Lufthansa long-haul premium seats are possibly the best in the business, on short-haul/intra-Europe flights, LH business class seats would seam a little mean in most carrier’s coach sections.

There is no difference between coach seats and business class, none at all. In business all middle seats are blocked out, but that isn’t that hard to find in coach. It is efficient to scale business, it involves only moving a rack-mounted divider that is the only obvious differentiation in the classes.

In both the seats are substandard to the amenities one usually expects, especially on a long haul flight:

– little padding on the seats
– cramped seat pitch (worse than econ +)
– typical economy seat width
– no in seat power (not even a usb port)
– no personalized IFE

Such limitations would be cheap in economy, but in business they are, perhaps we should say “disappointing.” Neither the economy nor the business class zone is going to leave the passenger well-rested (IST-FRA is a long enough flight that rest matters); such a flight is a grim endurance test for everyone. But it is very egalitarian in shared suffering, though not particularly egalitarian in pricing.  And were LH business not priced competitively with other carrier’s business, the disparity in services wouldn’t seem quite so jarring.

LH is, of course, efficient and well organized, but every other airline I’ve flown that has a business class has far, far better business class, even those that can’t really manage the basics.

20140328_014237.jpg
Posted at 17:01:05 UTC

Category: planestravel