Navy SEALs and other highly trained special forces operators all know a simple, basic fact – you’ve got to breathe to live. That seems self-evident, but breathing control is immensely important to being able to perform at a high level in stressful situations. But even if you never anticipate being under fire, you can learn the SEAL way of breathing with this visual aid.
Lest you think that Box Breathing, also known as the four-square breathing technique, is some sort of New Age nonsense, recent research has uncovered the neurological basis for the feeling of calm that can come over someone taking slow, deep, even breaths. But in the heat of the moment, remembering to square your breaths can be a little difficult. [Lim Han Yang] decided that a portable visual cue could help, so he put an ATTiny85, an LED, and a coin cell battery on a tiny circular PCB and spun up a simple translucent dome out of PLA. The blue LED has a soothing appearance behind the diffuser as it goes through a 16-second cycle, ramping up in brightness for four seconds, holding steady for four, then dimming and finally staying dark. The idea is to breathe in sync with the light to get relief from stress.
No build files are posted yet, but we hope to see them soon – we can think of a few people this would benefit greatly. In the meantime, if you’re still looking for that New Age breathing experience, you can always breathe with the psychedelic flowers.
Python is the Arduino of software projects. It has a critical mass of libraries for anything from facial recognition and neural networks to robotics and remote sensing. And just like Arduino, I have yet to find the killer IDE for Python. Perhaps I just haven’t tried the right one yet, but it could be that I’m just doing Python wrong.
For Years I’ve Been IDLE
IDLE with interactive shell that has highlighting and code completion
I’m a Linux-only type of a guy so using IDLE for Python is a natural fit. It’s in the repositories for super quick and easy install and there’s basically zero configuration to be done. Generally speaking my preferred development environment is text editor and command line compiler. IDLE is just one step above that. You get a separate window for the shell and each Python file you’re working on. Have IDLE run your code and it saves the file, then launches it in the shell window.
For me, there are two important features of IDLE’s shell. The first is that it keeps an interactive session open after you run your Python code. This means that any globals that your script uses are still available, and that you can experiment with your code by calling functions (and classes, etc) in real time. The second desirable feature is that while using this interactive shell, IDLE supports code completion and docstring support (it gives you hints for what parameters a function accepts/requires).
But simplicity has a tough time scaling. I’m working on larger and larger projects spread over many files and the individual nature of IDLE editor windows and lack of robust navigation has me looking to move forward.
The Contenders
I’ve tried perhaps a half-dozen different Python IDEs now, spending the most time on two of them: Geany and Atom. Both are easy to install on Linux and provide the more advanced features I want for larger projects: better navigation, cross-file code completion (and warnings), variable type and scope indication.
The look of Geany brings to mind an “IDE 1.0” layout style and theme. It’s the familiar three-pane layout that places symbols to the left, code to the right, and status along the bottom. When you run your program it launches in an interactive terminal, which I like, but you lose all IDE features at this point, which I despise. There is no code completion, and no syntax highlighting.
I have been using Atom much more than Geany and have grown to like it enough to stick with it for now. I’d call Atom the “IDE 2.0” layout. It launches with a dark theme and everything is a tab.
Atom has symbol view that isn’t shown all the time. CTRL-R brings it up and it uses a search style but you can also scroll through all symbols
Atom depends heavily on packages (plugins that anyone may write). The package management is good, and the packages I’ve tried have been superb. I’m using autocomplete-python and tabs-to-spaces, but again I come up short when it comes to running Python files. I’ve tried platformio-ide-terminal, script, and runner plugins. The first brings up a terminal as a bottom pane but doesn’t automatically run the file in that terminal. Script also uses a bottom pane but I can’t get it to run interactively. I’m currently using runner which has an okay display but is not interactive. I’ve resorted to using a “fake” python file in my projects as a workaround for commands and tests I would normally run in the interactive shell.
Tell Us How You Python
It’s entirely possible I’ve just been using Python wrong all these years and that tinkering with your code in an interactive shell is a poor choose of development processes.
What do you prefer for your Python development? Does an interactive shell matter to you? Did you start with IDLE and move to a more mature IDE. Which IDE did you end up with and what kind of compromises did you make during that change. Let us know in the comments below.
Researchers from the Argus Research Team found a way to hack into the Bosch Drivelog ODB-II dongle and inject any kind of malicious packets into the CAN bus. This allowed them to, among other things, stop the engine of a moving vehicle by connecting to the dongle via Bluetooth.
Drivelog is Bosch’s smart device for collecting and managing your vehicle’s operating data. It allows a user to connect via Bluetooth to track fuel consumption and to be alerted when service is necessary. It was compromised in a two stage attack. The first vulnerability, an information leak in the authentication process, between the dongle and the smart phone application allowed them to quickly brute-force the secret PIN offline and connect to the dongle via Bluetooth. After being connected, security holes in the message filter of the dongle allowed them to inject malicious messages into the CAN bus.
The Bluetooth pairing mechanism, called “Just Works”, has been fixed by Bosh by activating a two-step verification for additional users to be registered to a device. The second issue, the ability for a maliciously modified mobile application to possibly send unwanted CAN messages, will be mitigated with an update to the dongle firmware to further limit the allowed commands that the dongle is able to place on the CAN bus.
Bosch downplays the issue a bit in their statement:
It is important to note that scalability of a potential malicious attack is limited by the fact that such an attack requires physical proximity to the dongle. This means that the attacking device needs to be within Bluetooth range of the vehicle.
The problem is that physical proximity does not equal Bluetooth range. Standard Bluetooth range is about 10m, which is very arguable physical proximity, but it is pretty easy to buy or even modify a Bluetooth dongle with 10x and 100x more range. When adding a wireless connection to the CAN bus of an automobile, the manufacturer has an obligation to ensure the data system is not compromised. This near-proximity example is still technically a remote hack, and it’s an example of the worst kind of vulnerability.
More than one member of the Hackaday team has significant involvement in a hackspace, as member, director, or even founder. We talk about hackspaces quite rarely on these pages though, not because we don’t have anything to say on the matter but because even when we write in general terms our fellow members invariably think it’s all about them rather than the hackspace world at large.
For once I’m going to break the silence, and not only talk about hackspaces, but talk about my own hackspace in specific terms. Because, fellow Oxford Hackspace members, this isn’t about you personally though I’m using our home to illustrate a point. The topic is a thorny issue that must affect all spaces, that of donations of physical items. People want to help their hackspace, they have a pile of what they consider to be good stuff, and when they’re having a clear-out they make a donation. But, as we all know, “one man’s trash is another man’s treasure” and vice-versa. Continue reading “The Complex Issue Of Hackspace Donations”→
Advertisers are always trying to stuff more content into a 15 or 30 second TV spot. Burger King seems to have pulled it off with a series of ads that take advantage of the Google Home device sitting in many viewers living rooms. It works like this: The friendly Burger King employee ends the ad by saying “Ok Google, what is the Whopper burger?” Google home then springs into action reading the product description from Burger King’s Wikipedia page.
Trolls across the internet jumped into the fray. The Whopper’s ingredient list soon included such items as toenail clippings, rat, cyanide, and a small child. Wikipedia has since reverted the changes and locked down the page.
Google apparently wasn’t involved in this, as they quickly updated their voice recognition algorithms to specifically ignore the commercial. Burger King responded by re-dubbing the audio of the commercial with a different voice actor, which defeated Google’s block. Where this game of cat and mouse will end is anyone’s guess.
This event marks the second time in only a few months that a broadcast has caused a voice-activated device to go rogue. Back in January a disk jockey reporting a story about Amazon’s Echo managed to order doll houses for many residents of San Diego.
With devices like Alexa and Google home always ready to accept a command, stories like this are going to become the new normal. The only way to avoid it completely is to not allow it in your home. For those who do have a voice-activated device, be very careful what devices and services you connect it to. Internet of things “smart” door locks are already providing ways to unlock one’s door with a voice command. Burglarizing a home or apartment couldn’t be easier if you just have to ask Siri to unlock the door for you. And while some complained about the lack of security in the Zelda hack, we’d rate that as a thousand times more secure than a voice recognition system with no password.
There are exactly two types of personal computers available today. If you need a lot of horsepower, a powerful GPU, or a full-power CPU, you’re going to end up with a desktop. If you need something portable, you’re getting a laptop with a wimpy CPU and an underpowered GPU. Historically, there has been a third type of PC, the luggable. The luggable is a desktop PC crammed into a case that makes it slightly more portable than a desktop and a monitor. You cannot buy a luggable PC case right now. They simply do not exist as a commercial product you can shove your own hardware into. This is a form factor an entire industry forgot.
Now there’s a DIY luggable PC. This project from [Roger] packs a standard ATX motherboard, a full-size GPU, a full-size power supply, and everything else that makes a desktop PC powerful into a case that can be stored in an overhead bin.
[Roger] has been working on this project for a while, and it was featured on Hackaday back when it looked like a RepRap Mendel. There have been some significant improvements over the earlier iterations of this project, including a very, very cool hinge mechanism that allows the display to fold in when the computer isn’t being used. It’s a mechanical wonder that prevents scratches. Neat. The rest of the case is constructed out of 2020 aluminum extrusion, and about a one kilogram spool of filament.
Since this is a portable case, there are a few compromises. There are no 5.25″ bays, no 3.5″ bays, and few 2.5″ bays. M.2 SSDs and USB-powered CD drives exist, so this isn’t a big deal.
This is a truly fantastic case in a form factor you can’t buy anywhere else. If you have a spare monitor and a bit of extrusion sitting around, this is one to build yourself.
The Linux kernel recently added support for loading firmware into an FPGA via the FPGA Manager Framework. [OpenTechLab] has built a driver for the Lattice iCE40 FPGA (same chip used on the iCEStick and other development boards). One attraction to the iCE40 is there is an open source toolchain called iCEStorm.
Even if you aren’t specifically interested in FPGAs, the discussion about Linux device drivers is good background. The principles would apply to other drivers, and would definitely apply if you want to write another FPGA loader.
