Python is an absolutely fantastic language for tossing bits of data around and gluing different software components together. But eventually you may find yourself looking to make a program with an output a bit more advanced than the print() statement. Once you’ve crossed into the land of graphical Python programming, you’ll quickly find that the PyGame library is often recommended as a great way to start pushing pixels even if you’re not strictly making a game.
Today, the project is celebrating an incredible milestone: 20 years of helping Python developers turn their ideas into reality. Started by [Pete Shinners] in 2000 as a way to interface with Simple DirectMedia Layer (SDL), the project was quickly picked up by the community and morphed into a portable 2D/3D graphics library that lets developers deploy their code on everything from Android phones to desktop computers.
Things haven’t always gone smoothly for the open source library, and for awhile development had stalled out. But the current team has been making great progress, and decided today’s anniversary was the perfect time to officially roll out PyGame 2.0. With more than 3,300 changes committed since the team started working on their 2.0 branch in July of 2018, it’s a bit tough to summarize what’s new. Suffice to say, the library is more capable than ever and is ready to tackle everything from simple 2D art up to 4K GPU-accelerated applications.
If you haven’t given PyGame a try in awhile, don’t worry. The team has put special effort into making the library as backwards compatible as possible, so if you’ve got an old project kicking around that you haven’t touched in a decade, it should still run against the latest and greatest version. If you’ve never used it before, the team says they’ll soon be releasing new tutorials that show you how to get the most out of this new release.
Since the release of the original Raspberry Pi single board computer, the WiringPi library by [Gordon] has been the easy way to interface with the GPIO and peripherals – such as I2C and SPI – on the Broadcom SoCs which power these platforms. Unfortunately, [Gordon] is now deprecating the library, choosing to move on rather than deal with a community which he no longer recognizes.
As this secondary use is what’s draining the fun out of the project, he has decided to put out one final release, before making it a closed-source project, for use by himself and presumably paying clients. What the impact of this will be has to be seen. Perhaps a new fork will become the new ‘WiringPi’?
Suffice it to say, none of this is a good thing. The illegal use of open source code and the support nightmare that gets poured on the authors of said code by less than informed users is enough to drive anyone away from putting their projects out there. Fighting abuse and junking the ‘spam’ is one way to deal with it, but who has the time and energy (and money) for this?
What are your thoughts on this news, and this issue in general? How should an open source developer deal with it?
Thanks to [Dirk-Jan Faber] for sending this one in.
PCI pass through is the ability of a virtualized guest system to directly access PCI hardware. Pass through for dedicated GPUs has just recently been added to the Linux kernel-based virtual machine. Soon afterward, users began to find that switching on nested page tables (NPT), a technology intended to provide hardware acceleration for virtual machines, had the opposite effect on AMD platforms and slowed frame rate down to a crawl.
Annoyed by this [gnif] set out to to fix the problem. His first step was to run graphics benchmarks to isolate the source of the problem. Having identified the culprit in the GPU, [gnif] began to read up on the involved technology stack. Three days of wrapping his head around technical docs allowed [gnif] to find the single line of code that resulted in a faulty memory set up and to implement a basic fix. He then passed the work on to [Paolo Bonzini] at patchwork.kernel.org, who released a more refined patch.
The bug affecting PCI pass through had been around for ten years and had received little attention from the manufacturer. It gained prominence when graphics cards were affected. In the end it took one very dedicated user three days to fix it, and then another day to roll out a patch for Open Source operating systems. In his notes [gnif] points out how helpful AMDs documentation was. With the right to repair in debate, DRMed technical docs and standards locked behind paywalls, [gnif]’s story is a reminder of the importance of accessible quality documentation.
It is with great sadness that Hackaday learns of the passing of Steve Evans. He was one of the creators of Eyedrivomatic, the eye-controlled wheelchair project which was awarded the Grand Prize during the 2015 Hackaday Prize.
News of Steve’s passing was shared by his teammate Cody Barnes in a project update on Monday. For more than a decade Steve had been living with Motor Neurone Disease (MND). He slowly lost the function of his body, but his mind remained intact throughout. We are inspired that despite his struggles he chose to spend his time creating a better world. Above you can see him test-driving an Eyedrivomatic prototype which is the blue 3D printed attachment seen on the arm of his chair.
The Eyedrivomatic is a hardware adapter for electric wheelchairs which bridges the physical controls of the chair with the eye-controlled computer used by people living with ALS/MND and in many other situations. The project is Open Hardware and Open Source Software and the team continues to work on making Eyedriveomatic more widely available by continuing to refine the design for ease of fabrication, and has even begun to sell kits so those who cannot build it themselves still have access.
The team will continue with the Eyedrivomatic project. If you are inspired by Steve’s story, now is a great time to look into helping out. Contact Cody Barnes if you would like to contribute to the project. Love and appreciation for Steve and his family may be left as comments on the project log.
Programmatic CAD, in particular the OpenSCAD language and IDE, has accompanied the maker movement for a while now. After its introduction in 2009, it quickly found its way into the 3D printing toolbox of many makers and eventually became what could be called an Industry Standard among open hardware labs, makerspaces and tinkerers. The Prusa i3, one of the most popular DIY 3D printers, was designed in OpenSCAD, and even Makerbot, the company that sold 100.000 3D printers, uses the language for its “Customizer” – an online tool that allows users to customize 3D printable models with minimal effort.
OpenSCAD is indeed a wonderful tool, and we have been using it a lot. We have become used to its quirks and accepted working with polygon mesh approximations of the models we are trying to design. We have made our peace with excessive rendering times, scripting workarounds and the pain of creating fillets, and we have learned to keep our aesthetic expectations low. We are happy with the fact that there is a way to programmatically create and share virtually any object, but sometimes we wish there was a better way in the open source world. Hint: there is.
Six months ago we challenged you to realize the future of open, connected devices. Today we see the five finalists vying for The Hackaday Prize.
These five were chosen by our panel of Launch Judges from a pool of fifty semifinalists. All of them are tools which leverage Open Design in order to break down the barriers of entry for a wide range of interests. They will have a few more weeks to polish and refine their devices before [Chris Anderson] joins the judging panel to name the winner.
Starting on the top left and moving clockwise:
ChipWhisperer, an embedded hardware security research device goes deep into the world of hardware penetration testing. The versatile tool occupies an area in which all-in-one, wide-ranging test gear had been previously non-existant or was prohibitively expensive to small-shop hardware development which is so common today.
SatNOGS, a global network of satellite ground stations. The design demonstrates an affordable node which can be built and linked into a public network to leverage the benefits of satellites (even amateur ones) to a greater extent and for a wider portion of humanity.
PortableSDR, is a compact Software Defined Radio module that was originally designed for Ham Radio operators. The very nature of SDR makes this project a universal solution for long-range communications and data transfer especially where more ubiquitous forms of connectivity (Cell or WiFi) are not available.
ramanPi, a 3D printed Raman Spectrometer built around a RaspberryPi with some 3D printed and some off-the-shelf parts. The design even manages to account for variances in the type of optics used by anyone building their own version.
Open Source Science Tricorder, a realization of science fiction technology made possible by today’s electronics hardware advances. The handheld is a collection of sensor modules paired with a full-featured user interface all in one handheld package.
From Many, Five
The nature of a contest like the Hackaday Prize means narrowing down a set of entries to just a few, and finally to one. But this is a function of the contest and not of the initiative itself.
The Hackaday Prize stands for Open Design, a virtue that runs far and deep in the Hackaday community. The 50 semifinalists, and over 800 quarterfinalists shared their work openly and by doing so provide a learning platform, an idea engine, and are indeed the giants on whose shoulders the next evolution of hackers, designers, and engineers will stand.
Whether you submitted an entry or not, make your designs open source, interact with the growing community of hardware engineers and enthusiasts, and help spread the idea and benefits of Open Design.
It seems like I’m constantly having the same discussions with different people about the Open Design aspect of The Hackaday Prize. I get arguments from both sides; some attest that there should be no “openness” requirement, and others think we didn’t set the bar nearly high enough. Time to climb onto my soap box and throe down some sense on this argument.
Open Design is Important
When you talk about hardware there is almost always some software that goes into making a finished product work. Making the information about how a product works and how it is manufactured available to everyone is called Open Design; it encompasses both Open Hardware and Open Source Software. Open Design matters!
First of all, sharing how something is designed and built goes much further than just allowing others to build their own. It becomes an educational tool and an innovation accelerator (others don’t need to solve the same problems over and over again). When using a new chip, protocol, or mechanical part you can learn a lot by seeing how someone else already did it. This means faster prototyping, and improvements on the design that weren’t apparent to the original creator. And if it breaks, you have a far easier time trying to diagnose and repair the darn thing! We all benefit from this whether we’re creating something or just using an end product because it will work better, last longer, and has the potential to be less buggy or to have the bugs squashed after the fact.
There is also peace-of-mind that comes with using Open Design products. The entries in The Hackaday Prize need to be “connected devices”. With open design you can look at the code and see what is being done with your information. Can you say that about Nest? They won’t even allow you to use the thermostat in a country that hasn’t been pre-approved by decree from on high (we saw it hacked to work in Europe a few years back). Now it has been rooted so that you can do with it what you please.
But I contest that it would have been better to have shipped with options like this in the first place. Don’t want to use Nest’s online platform? Fine, let the consumer own the hardware they pay for! My wager since the day they announced Google’s acquisition of Nest is that this will become the “router” for all the connected devices in your home. I don’t want the data from my appliances, entertainment devices, exercise equipment, etc., being harvested, aggregated, and broadcast without having the ability to look at how the data is collected, packaged, and where it is being sent. Open Design would allow for this and still leave plenty of room for the big G’s business model.
I find it ironic that I rant about Google yet it would be pretty hard to deny that I’m a fanboy.
Decentralize the Gatekeeper
I’m going to beat up on Google/Nest a bit more. This is just an easy example since the hardware has the highest profile in the field right now.
If Nest controls the interface and they retain the power to decide whose devices can participate the users lose. Imagine if every WiFi device had to be blessed by a single company before it would be allowed to connect to any access points? I’m not talking about licensing technology or registering a MAC address for a chip. I’m talking about the power, whether abused or not, to shut any item out of the ecosystem based on one entity’s decisions.
If connected devices use a known standard that isn’t property of one corporation it unlocks so many good things. The barrier for new companies to put hardware in the hands of users is very low.
Let’s consider one altruistic part of this; Open Design would make small run and single unit design a possibility. Think about connected devices specialized for the physically challenged; the controller project makes specialized controls for your Xbox, what about the same for your oven, dishwasher, the clock on your wall, or your smart thermostat?
The benefits really show themselves when a “gatekeeper” goes out of business or decides to discontinue the product line. This happened when the Boxee servers were shut down. If the source code and schematics are available, you can alter the code to use a different service, build up your own procotol-compliant home server, or even manufacture new devices that work with the system for years to come. There are already pleas for belly-up manufacturers to open-source as the last death throw. Hacking this stuff back into existence is fun, but isn’t it ridiculous that you have to go to those lengths to make sure equipment you purchased isn’t turned into a doorstop when they shut the company lights off?
To drive the point home, consider this Home Automation System from 1985 [via Reddit]. It’s awesome, outdated, and totally impossible to maintain into the future. I’m not saying we should keep 30-year-old hardware in use indefinitely. But your choices with this are to source equally old components when it breaks, or trash everything for a new system. Open Design could allow you to develop new interfaces to replace the most used parts of the system while still allowing the rest of the hardware to remain.
Why not disqualify entries that aren’t Open Hardware and Open Source Software?
Openness isn’t a digital value
Judging preferences are much better than disqualifying requirements. This is because ‘openness’ isn’t really a digital value. If you publish your schematic but not your board artwork is that open? What if you’re using parts from a manufacturer that requires a Non-Disclosure Agreement to view the datasheet and other pertinent info about the hardware?
In addition to deciding exactly where the threshold of Open or Not-Open lies, we want to encourage hackers and companies to try Open Design if they never have before. I believe that 1% open is better than 0% open, and I believe that there is a “try it, you’ll like it” experience with openness. If this is the case, The Hackaday Prize can help pollinate the virtue of Open Hardware far and wide. But only if we act inclusively and let people work their way toward open at their own pace.
There are more benefits to Open than there are drawbacks.
The biggest worry I hear about open sourcing a product is that it’ll get picked up, manufactured, and sold at a cut-throat rate.
If you build something worth using this is going to happen either way. The goal should be to make a connection with your target users and to act ethically. Open Design allows the user to see how your product works, and to add their own features to it. Most of the time these features will appeal to a very small subset of users, but once in a while the community will develop an awesome addition to your original idea. You can always work out a way to include that in the next revision. That right there is community; the true power of open.