Nothing’s really occured to me to post in a while, so here’s something kind of random. I’m actually posting this from GNU/HURD (specifically, the Debian distribution). I played around with it, installed some software, and eventually got Xorg and Mate running, and then Midori:
So how is it? Slow, for one thing. Not terribly while just using the terminal, but the install process took hours. The installer is the basic Debian installer, but things like copying files to the hard drive took longer than it seems like they would under GNU/Linux. The same is true of just installing packages. The desktop is of course noticeably sluggish as well, although using something like Openbox might improve things here. This machine is an old Dell Optiplex, with a 1.6 GHz P4 and 2 GB of RAM (only 768 MB were picked up according to htop). The graphics are Intel, which I think requires a kernel module on Linux, which of course isn’t supported here. This probably explains the X slowness, but otherwise while this machine is old it’s felt faster on other OSes.
As far as applications, there are quite a few Debian packages ported over, and while not everything works very smoothly (I tried getting Apache and PHP going, only to have mod-php give an error about allocating shared memory) a lot of familiar programs are available and do run. I dare say that there’s enough here to run an almost-functional desktop, although there is no sound or USB support (although keyboards/mice may work due to BIOS emulation).
So what’s the point of it then? The concept of HURD, as in how it runs on top of a microkernel, is interesting. Basically, this means that most of the services provided are run as a set of servers in userspace on top of a very minimal kernel (Mach in this case). This is in contrast to Linux, in which these are all part of the kernel. So, a fault in one of these servers doesn’t necessarily bring down the entire operating system. In fact, these programs don’t even have to run as root. This modularity may not be that much of a big deal on a normal desktop or server, considering how mature monolithic kernels like Linux are these days, but one could imagine an embedded or remote system where this could be desirable. (Think some diagnostic that restarts one of the servers should it crash, so your entire space probe doesn’t have to reboot.) Some other interesting features in GNU/HURD are the ability for a process to have more than one UID associated with it, as well as translators, which can expose things as part of the filesystem. (For example, they can be used to mount an FTP share on a directory, similar to Fuse.)
I’m probably not going to be installing a GNU/HURD desktop on my main computer anytime soon. In fact, I would guess that most people won’t be. (There are probably exceptions, like people who work on GNU/HURD.) For day-to-day use, it’s similar enough to a normal Debian (in this case, there are other HURD distributions) system that it’s not really worth the effort compared to the ease of the mainstream alternatives. However, I’ll be keeping an eye on this project now and then. Of course, there aren’t many people working on it compared to say Linux, so development isn’t exactly snappy. But, depending on how it matures it could hold promise in some applications. (Again I’m thinking of embedded systems.)
It’s also nice to have alternatives. This is part of the reason I use GNU/Linux, and experiment with other OSes. Even if HURD really isn’t ready now, it can actually be somewhat useable. So, I consider it worth checking out, if only as an educational experience. (And hopefully not as a cuationary tale.)
Easytether is a nice application you can use to tether your Android phone regardless of restrictions put in place by your carrier. It consists of an app for the phone, as well as a program you run on your computer. The two then talk to each other using the phone’s USB debugging abilities (ie, through ADB, which is integrated). On the computer-side, Linux, Windows, and OS X are supported, and you can even use it with a Raspberry Pi.
I use this to occasionally tether my laptop, which runs Xubuntu. On GNU/Linux, the PC-side application works by creating a tun (virtual) interface. You start it from the command line like this ($ indicating the command prompt):
$ sudo easytether-usb
When I first did this (must have been a few years ago), Networkmanager would immediately detect the interface and manage it, so I didn’t really have to do anything else. As soon as I started the program, I’d have a network connection. This does not work with Xubuntu 16.04, however – the interface comes up, but I have to configure it manually. No big deal, but now after running the above I have to do this:
$ sudo dhclient easytether-tap
Or this instead of dhclient, to do it manually:
$ sudo ifconfig easytether-tap 192.168.117.2
$ sudo route add default gw 192.168.117.1$ sudo sh -c ‘echo “nameserver 126.96.36.199” >> /etc/resolv.conf’
That works fine, but it’s kind of a pain. Networkmanager is fairly capable these days, and it would be nice to make it do some of this for us again. The reason it doesn’t is that, with the current version (1.2.0-0ubuntu0.16.04.2 on this machine), virtual interfaces that it didn’t create itself are ignored by default. Luckily, there is a way we can make a new connection and automate things. Unfortunately, this doesn’t seem to be possible with the panel applet in Xubuntu, but we can do it from the command line using nmcli.
In the above lines, easytether-tap is the default name of the virtual interface that the PC application creates. First, let’s create a new connection named ‘phone’ that uses this interface. Then, we’ll add a DNS server. (Note that the below lines can be done as a normal user, no sudo needed.)
$ nmcli connection add ifname easytether-tap con-name phone type tun mode tap ip4 192.168.117.2 gw4 192.168.117.1
$ nmcli con mod phone +ipv4.dns 188.8.131.52
You could of course name it something other than phone. Note that that configures the interface manually, which I just did for simplicity. Also, 184.108.40.206 is Google’s public DNS, and you could substitute a different server IP. Now, assuming you have easytether-usb started like in the first command in this post, you can bring the interface up like this:
$ nmcli connection up phone
And then bring it down like this:
$ nmcli connection down phone
And that’s it! But, we still have to start easytether-usb when we plug the phone in. It’s possible to automate that, too, using Networkmanager’s dispatcher scripts. I created the following script, and saved it as 90easytether.sh:
if [ “$IFACE” == “easytether-tap” ]
case “$STATUS” in
logger -s “Starting easytether-usb daemon”
logger -s “Stopping easytether-usb daemon”
Now, move the script into the dispatcher.d directory, then change the ownership and permissions, and create a symlink to the script in the pre-up directory:
$ sudo mv 90easytether.sh /etc/NetworkManager/dispatcher.d/
$ cd /etc/NetworkManager/dispatcher.d
$ sudo chown root:root 90easytether.sh$ sudo chmod 755 90easytether.sh
$ cd pre-up.d/
$ sudo ln -s /etc/NetworkManager/dispatcher.d/90easytether.sh ./
Now, we need to start the dispatcher service, an enable it on boot:
$ sudo systemctl start NetworkManager-dispatcher.service
$ sudo systemctl enable NetworkManager-dispatcher.service
I also found I needed to restart Networkmanager itself:
$ sudo systemctl restart network-manager.service
Basically, that script is triggered by the pre-up and down actions, and starts and kills easytether-usb for us. The symlink was necessary because Networkmanager needs anything that acts on this to be in the pre-up.d directory. Now, you plug in your phone, then use the nmcli commands from above to bring the interface up and down, and that’s it!
One caveat: You need to be able to use USB debugging on your phone. Also, you may have to confirm on your phone that you want to be able to connect from your PC or laptop first. I also find that I have to mount my phone (IE, click on the icon on the desktop and browse to it in the file manager) before easytether-usb will connect. Make sure you get Easytether working manually like at the beginning of this post, and you should be fine. Have fun!
I use ownCloud on a few of my machines for keeping some folders synced via the desktop syncing client. I’m fairly happy with it, at least for smaller files like documents and pictures. (Part of this is because I’m running the server on a Raspberry Pi, which is a little slow, but for my purposes works fine.) Recently, however, I ran into a problem with version 1.8.1 of the desktop client, running on a laptop with Xubuntu 15.10. Basically, every time I started the client it would ask me for my username, password, and folder list, as if I were configuring it for the first time. This happened when just logging in (when I have it set to start automatically), or if I killed it and restarted it.
The fix turned out to be relatively simple. First, the desktop client stores its configuration files (on Linux) here:
In that directory I found the following:
cookies.db folders owncloud.cfg socket
But when I tried to display the file owncloud.cfg, I got an Input/Output error. I could list the folders directory; this just contained a file with conf info for each of the folder I sync. On a hunch I deleted owncloud.cfg, and restarted the client. It asked for my login information again, and then I told it to skip the folder configuration. It worked, and even picked up the folders I had set up to sync (as those configuration files were readable). I’m not sure what caused this, but after doing this I can view the new owncloud.cfg file that was created.
Hopefully this save someone some time. It’s a little aggrivating that I did have to poke around in the terminal, but not too bad – at least it’s possible. I’m not sure if this could be a bug in the client, but if this happens again I’ll reevaluate.
Take a look at the picture blow, of a 400 watt inverter I garbage picked a while ago:
The inverter is running off a 12 volt battery, and is switched on. Notice anything interesting, particularly with how the meter is connected and what it’s reading? (You may have to click to embiggen, so you can see the display.)
The meter is connected between the negative (black) battery post, and one of the legs of the 120 volt output, and is reading about 67 volts AC. This works between that post and either leg of the output, as well. Going between the two legs gives 117 volts, which is the output we want.
So what’s going on here? The problem has to do with grounding and isolation. Inside the inverter, there’s a circuit that looks something like this:
That’s an H-bridge, a switching arrangement that lets you supply a load (on what I have labeled here as the AC out wires) with either normal or reversed polarity, or none at all. This is very simplified; you’d want to drive the switches (MOSFETs in this case, could be something else like an IGBT) with some sort of switching scheme of some sort. However, this is the basic mechanism by which the inverter makes alternating current. (There are other ways to do this, including one with just two switches, but this is the basic idea.)
Notice the ground symbol on the low-side of the H-bridge? That’s our problem – imagine that the MOSFET just above it (the lower left-hand one) is on, as is the one diagonal from it in the upper-right. The other two are off. If we measured between the AC out leg from the left-hand side of the bridge to the ground node, we’d see 0 volts, because it’s the same node – the transistor shorted that leg to ground. But, milliseconds later (about 8.3 if we’re at the beginning of the cycle) the transistors switch – now, that same leg of the AC out is at the voltage of the DC source (could be battery voltage, or could be from a DC-DC converter), and that’s what we’d read on the meter. It would be in this state half the time, and with the meter set to AC voltage we’d read something like the 67 volts in the first picture. The AC output is floating with respect to the ground point.
The problem, then, is if at any point in your AC wiring the ‘neutral’ conductor is tied to ground, and that ground is also tied to Battery-, you have a short-circuit path! This depends on the design of the inverter as far as whether or not it’s a pure short circuit (the DC source would have some impedance to it, so it might not necessarily be like a dead short on the battery), but it could still damage your inverter. Not to mention that having a voltage between Battery- and the AC neutral or ground would be a safety hazard.
So, how much of a problem is this, really? Well, in the picture the inverter is running a laptop charger, which is encased in plastic and I think actually provides isolation between its input and the laptop. So, here I’m not worried about it. However, say you wanted to provide some backup power to your house in a power failure. It’s not uncommon for people with a generator to backfeed their circuit breaker panel (either with into a normal outlet with an aptly-named suicide cable or with a proper receptacle and transfer switch). So what if we did this with this inverter instead?
In the US homes typically have the neutral and ground bonded together in the circuit breaker panel. Now, say you have a little system with some solar panels and a big battery to run the inverter, and you happen to have the negative side of the battery grounded on a watter pipe in your basement, or maybe even the ground wire in your house wiring… Even if you drive in a separate ground rod for the DC side, you’ll wind up with a current path, and a potential safety issue.
Now, a 400 watt inverter is a little small for backing up your whole house, but there are larger, cheapy inverters like this one that probably have a similar design. If you find a 2000-3000 watt inverter at your local hardware store for a few hundred dollars, this is probably the case.
So, how can this be fixed? Take a look at this update to the schematic from above:
Notice that there’s a transformer on the output of the bridge – now the AC output is isolated from the DC side! So you can use the same ground on the DC and AC sides. There isn’t an electrical connection, there’s a magnetic one, so we just transfer the energy across. There is a small section where the AC is floating, but it can be safely enclosed in the inverter chassis, and insulated appropriately. Of course, there are other solutions; the DC source could be fully isolated itself, and the low-side of the H-bridge could remain ungrounded. This way you could still reference the output to the inverter’s DC input safely.
You could also get an isolation transformer and put it between the inverter and your loads. This would solve the problem, but would give you a little drop in efficiency – it’s not the same as if the transformer is designed into the inverter. Also, the cheap inverters that don’t isolate input from output tend to be modified sine wave (really modified square wave), and so could cause an off-the-shelf isolation transformer to run with even less efficiency. (A true sine wave inverter could also have this problem; the difference is in how the switching is done. But, a lot of high-end sine wave inverters tend to take the isolation problem into account, it seems.)
On another note, those working with renewable energy will tell you that building a solar power system just for the off chance your grid power is out for a few hours a few times a year isn’t very economical. This is true, but I imagine that there are people out there who will think of attaching a big, cheap inverter to their home’s wiring, which is why I threw this together. The moral of the story is, if you’re going to distribute the AC from your inverter in a more complex fashion than an extension cord and power strip, check for voltage between each AC leg and the negative DC input. If you’re looking at buying an inverter, see if you can go to the store and try this with a multimeter. Or, call the manufacturer, and see what they say about hardwiring it. If it’s designed to be wired into an electrical system, there’s a good chance they’ve thought of this problem.
Somehow, I had expected to post here a few more times this year, not sure what I was thinking. But, better late than ever. Now for something Halloween-related:
And here’s a picture in the light:
Basically, you pick the seeds out of the pumpkin guts and rinse them out well. Then you can let them dry for about a week, and save them in an envelope. I’ve got the ones above from the big pumpkin, as well as some from a smaller one. I’m not sure I’ll have the space to plan them in the spring, as they do kind of take over, but I’ll see.
Anyways, I mentioned an homebrew inverter project before. I’m still tossing this around, but I think I’ve thought of a way to simplify part of it. More information will come, sometime.
In the mean time, Happy Halloween!
Alright, New Year’s is over, and it’s 2013. I didn’t put a whole lot of thought into resolutions, but here are a few things I’ve been thinking of regarding this site:
- Projects. I mentioned the inverter, and that and some other things have been kicking around in my head. Now I want to start work on them and share.
- Wiki. This goes with the above, as I think it will be a better format for some things. It won’t be for everyone to edit, but I think it will present certain bits of information in a better fashion than this blog. It’ll also be a little easier to maintain.
- Housekeeping. I’ve been meaning to update the theme here, and also take a look at some backend stuff.
- Feverdreams Update? I’ve been thinking of trying to modernize the Fever Dreams mirror, if for no other reason than to play with some Web development stuff. This would mainly be backend, as I wouldn’t want to disturb the pristine late-90s look. 🙂 I sometimes wonder about updating with new content, but that will remain to be seen as I really don’t have any.
Anyway, that’s about it. Have a good remainder of Christmas or whatever.