I remember seeing some chatter about tunneling over XMPP. Most plane wifi allows chat protocols, and it should be possible to encapsulate your traffic as ascii text in XMPP packets. You "just" need to set up the endpoints to do the bridging.
Of I were to do it, I'd run a a script that sets up a tun/tap interface that everything else on my laptop will communicate through. This script also connects to my xmpp server at home. Any data coming in on the tun/tap is encoded to ascii strings and sent as chat messages to my xmpp server. The same script can also do the reverse. At home a similar script does, mirroring that on my laptop. Make sure prerouting is set up accordingly in both ends.
From what I've seen on planes, it's mostly down to captive portals using mac addresses to track clients. In theory it should also be able to sneak through by spoofing hardware addresses of someone who's paid for the service.
After their last concert they gave away the oil drum they've been using as part of their percussion for all of their concerts. That oil drum now belongs to a friend of a friend of mine.
Maybe. It could be that the damage was already done, as the container spent 6 month being slow shipped around the world. That utility hatch was basically venting in sea breeze continuously during transit.
Most important servers go on top (we can run relatively fine without one of them, but with reduced capacity, as long as the cluster primaries work) and run the AC for longer during mobilization (a full day and overnight) Also, this utility hatch had a broken gasket and loads of bolts missing. This has now been fixed to make sure the container is reasonably air tight.
I've also considered some sort of heater in the bottom of the rack to prevent condensation during the initial AC cycle.
Anecdote time: I'm an IT dude for the offshore industry. I deal with production server clusters on board ships, and I usually show up when we're mobilizing to make sure the system is ready to go. In europe this is mostly smooth sailing, pun only partially intended.
Back in april I showed up in Singapore two weeks before anyone else, because there was some maintenance I needed to do beforehand, mostly down to setting up some huge RAID volumes from scratch, and (luckily) restoring some stuff from a backup. This mostly would involve a lot of waiting at the hotel while routinely checking in via VPN.
These production clusters consist of four servers mounted in an airconditioned rack, which in turn is mounted in an air conditioned shipping container. This way this system can be used all over the world without much adaptation needed.
When preparing to do this maintenance I did what I always do at the start: connect power, but leave the UPS off, just keeping the AC running. I then grabbed a Grab taxi and went to Sim Lim tower for some odds and ends that I needed, with the intention of just letting the AC do its thing for a few hours.
Upon returning after some shopping, geek browsing, and lunch, I checked that the temperature and humidity in the rack was fine. I then proceeded to power up the stuff. Network; fine. Both 10gig and 100gig networks. Various purpose made proprietary hardware was also fine. I then proceeded to power on the servers, and that's when the issues started; the first one didn't power on. "Huh, odd", I thought. Not too alarming as I was doing it remotely over LAN, and this sometimes croaks and can often be resolved by flashing the firmware on the management interface. So I went for the button instead; nothing. "Shit...".
I always keep a spare server with the systems for cases like this, so I started manhandling these 70Kg beasts, getting the fauly one out and the spare in, swapping over all the drives and after powering it and importing the RAID arrays it worked as intended. The most important server was up and running.
2nd server, almost as importantas the first one: same issue. "Shit, that was my one spare". So i started troubleshooting, swapping around CPUs to make sure they weren't the issue (each server has two, and can run with just one, so unlikely).
After spending an entire day checking all combinations I concluded that I had two faulty motherboards on my hands, despite them working fine before it was shipped from europe. I called my vendor and to my luck, they had a motherboard of the right type in store. Only problem was that it was on the other side of the planet.
I then phoned up a coworker of mine. I knew he was flying in the day after, so I offered him free beer on arrrival if he could drive for three hours to the vendor and pick up my motherboard, and then handcarry it around the world to me.
Luckily the 3rd and 4th server powered fine, so thebreraid operation could churn along while I waited for spares. My coworker arrived with the spare a few hours before I needed everything working, and there was a frantic scramble of tools, personnel and hardware to get the last machine operational. Swapping motherboards in these servers is bloody annoying - imagine swapping motherboard in a normal PC, but with 10 times as much hardware populating it.
Finally, an hour before the ship was about to sail, everything was powered and ready to go. Investigation indicated that even though the air measured fine, there were most likely too much humidity inside the two servers at the bottom. Moral of the story: electronics don't like Singaporean climate.
After a stressful week I finally got to properly unwind by overdosing on Burnt Ends and Shiner Bock at Decker BBQ that night.
Kind of related, I found mine myself once while about to fill out the form for lost luggage.
"Hi, I need to report lost lugg.... oh, there it is", I said, as I noticed my very recognizable pelicase behind the luggage agent.
To their defense, the luggage tag had fallen off somewhere in transit, and they were about to enter it into the system. Luckily IAH was the destination airport.
Allows me to interface a PC to a canbus in an efficient manner. I wrote an autopilot in perl using that, but I would like to see the project mature to the point where it is stable enough for production environments.
Christ, that article was hard to read, with 90% of it dedicated to the importance of palm oil, and random ads making you believe the article is finished. So, here's the part that matters:
Food experts at Queen Margaret University (QMU) in Edinburgh say their new 100% plant-based ingredient is 70% better for the environment.
And with 80% less saturated fat and 30% fewer calories, they are also hailing PALM-ALT as a significantly healthier option.
Catriona Liddle, one of the lead developers on the QMU team, said: “It’s the holy grail to replace it and still have exactly the same end result in product – to taste the same and have the texture the same – and we’ve done that.
“We’ve put it through some special sensory testing to see if a panel can tell the difference between our product and traditional palm shortening, and they can’t.”
The new PALM-ALT product is described as having a mayonnaise-style consistency.
It is made from a by-product from the linseed industry, plus natural fibre and rapeseed oil.
I remember seeing some chatter about tunneling over XMPP. Most plane wifi allows chat protocols, and it should be possible to encapsulate your traffic as ascii text in XMPP packets. You "just" need to set up the endpoints to do the bridging.
Of I were to do it, I'd run a a script that sets up a tun/tap interface that everything else on my laptop will communicate through. This script also connects to my xmpp server at home. Any data coming in on the tun/tap is encoded to ascii strings and sent as chat messages to my xmpp server. The same script can also do the reverse. At home a similar script does, mirroring that on my laptop. Make sure prerouting is set up accordingly in both ends.
From what I've seen on planes, it's mostly down to captive portals using mac addresses to track clients. In theory it should also be able to sneak through by spoofing hardware addresses of someone who's paid for the service.