Streamlining The Toolchain

Sometimes I try to do something magical, and it works. Most of the time this happens because other people have done a good part of the work for me, and shared it. I just cobble a bunch of existing tools into a flow that fits my needs. But the sum of all the parts is often less than the whole, when too many of the steps involve human intervention. Tools made for people simply keep the people in the loop.

For instance, I wanted to take a drawing that my son made into a stamp, by way of a CNC machine and whatever scrap wood we have kicking around in the basement. It’s easy enough, really. Take the photo, maybe use a little tweaking in GIMP to get the levels right, export it into Inkscape for the line detection and maybe even make the GCode right there, or take it off to any convenient SVG-to-GCode tool.

While this works straight out of the box for me, it turns out that’s because I have experience with all of the sub-tools. First, it helps a lot if you get the exposure right in the first place, and that’s not trivial when your camera’s light meter is aiming for grey, but the drawing is on white paper. Knowing this, you could set it up to always overexpose, I guess.

Still, there’s some experience needed in post-processing. If you haven’t played around with both image processing and image editing software, you don’t know how they’re going to interact. And finally, there are more parameters to tweak to get the CNC milling done than a beginner should have to decide.

In short, I had a toolchain up and running in a jiffy, and that’s a success. But in terms of passing it on to my son, it was a failure because he would have to learn way too many sub-tools to make it work for him. Bummer. I’m left wondering if I can streamline all of the parts to work together well enough, or whether I’m simply needed in the loop.

Why Fedora Decided To Give CC0 Licensed Code The Boot

The term “open source” can be tricky. For many people, it’s taken to mean that a particular piece of software is free and that they can do whatever they wish with it. But the reality is far more complex, and the actual rights you’re afforded as the user depend entirely on which license the developers chose to release their code under. Open source code can cost money, open source code can place limits on how you use it, and in some cases, open source code can even get you into trouble down the line.

Which is precisely what the Fedora Project is looking to avoid with their recent decision to reject all code licensed under the Creative Common’s “Public Domain Dedication” CC0 license. It will still be allowed for content such as artwork, and there may even be exceptions made for existing packages on a case-by-case basis, but CC0 will soon be stricken from the list of accepted code licenses for all new submissions.

Fedora turning their nose up at a software license wouldn’t normally be newsworthy. In fact, there’s a fairly long list of licenses that the project deems unacceptable for inclusion. The surprising part here is that CC0 was once an accepted license, and is just now being reclassified due to an evolving mindset within the larger free and open source (FOSS) community.

So what’s the problem with CC0 that’s convinced Fedora to distance themselves from it, and does this mean you shouldn’t be using the license for your own projects?

Continue reading “Why Fedora Decided To Give CC0 Licensed Code The Boot”

OpenJewelry, No Pliers Required

They say that if you want something done right, you gotta do it yourself. Oftentimes, that goes double for getting something done at all. Whereas some people might simply lament the lack of a (stable) Thingiverse-type site for, say, jewelry designs, those people aren’t Hackaday’s own [Adam Zeloof]. With nowhere to share designs among engineering-oriented friends, [Adam] took the initiative and created OpenJewelry, a site for posting open-source jewelry and wearable art designs as well as knowledge about techniques, materials, and processes.

[Adam] has seeded the site with a handful of his own beautiful designs, which run the gamut from traditional silversmithing techniques to 3D printing to fancy PCBs with working blinkenlights. You really should check it out, and definitely consider contributing.

Even if you don’t have any jewelry designs to share, the code is open as well, or you could even edit the wiki. Just be sure to read through the contribution guidelines first. If you don’t have the time for any of that, donations are welcome as well to help maintain the site.

We love wearable art around here, especially when it serves another purpose like this UV-sensing talisman, or this air quality necklace.

Ortur Laser Will Go Open-Source

Well, that was fast! Last week, we wrote about a video by [Norbert Heinz] where he called out the Ortur laser engravers for apparently using the GPL-licensed grbl firmware without providing the source code and their modifications to it, as required by the license. Because open source and grbl are dear to our hearts and CNC machines, we wrote again about Norbert’s efforts over the weekend, speculating that it might just be unfamiliarity with the open source license requirements on Ortur’s part.

Because of [Norbert]’s persistance and publicity around the issue, the support ticket finally reached the right person within Ortur, and within two or three days [Gil Araújo], Support Admin at Ortur, managed to convince the company that going fully open source was the right thing to do. What remains is the question of how to do it, operationally.

So [Gil] asked [Norbert] to ask Hackaday: what do you want from Ortur on this, and how should they proceed? Via e-mail, he asked in particular for best practices on setting up the repository and making the code actually useful to non-programmer types. He said that he looked around at the other laser engraver companies, and didn’t find any good examples of others doing the Right Thing™, so he asked [Norbert] to ask us. And now we’re asking you!

Have you got any good examples of companies using open-source firmware, modifying it, and making it available for their users? Is a simple Github repo with a README enough, or should he spend some time on making it user-friendly for the non-coders out there? Or start with the former and work toward the latter as a goal? I’m sure [Gil] will be reading the comments, so be constructive! You’ll be helping a laser engraver company take its first steps into actually engaging with the open source community.

We said it before, and we’ll say it again. Good job [Norbert] for taking Ortur to task here, but also by doing so in a way that leaves them the option of turning around and doing the right thing. This also highlights that companies aren’t monolithic beasts – sometimes it takes getting your cause heard by just the right person within a company to change the response from a “this is a business secret” to “how should we set up our Github?” And kudos for [Gil] and Ortur for listening to their users!

CP/M Is Now Freer Than It Was

It’s easy to think of the earlier history of desktop computing operating systems in terms of DOS, Windows, and Mac OS with maybe a bit of AmigaOS, TOS, or RiscOS thrown in. But the daddy of desktop computing, the OS that put word-processors and spreadsheets in 1970s offices and had a huge influence on what followed, isn’t among that list. Digital Research’s CP/M ran initially on Intel 8080-based machines before losing out to MS-DOS as IBM’s choice for their PC, and then gradually faded away over the 1980s. Its source has been available in some form with a few strings for a long time now, but now we have confirmation from Digital Research’s successor company that it’s now available without restrictions on where it can be distributed.

For years it was something an operating system that had been bypassed by the hardware and hacker communities, as the allure of GNU/Linux was stronger and most available CP/M capable machines were also 1980s 8-bit gaming platforms. But with the more recent increased popularity of dedicated retrocomputing platforms such as the RC2014 it’s become a more common sight in our community. Brush up your command line skills, and give it a go!

Header: Michael Specht, CC BY-SA 3.0.

Who Is Thinking About Open Source Firmware?

Yesterday, we ran a post on NVIDIA’s announcement of open-source drivers for some of its most recent video cards. And Hackaday being huge proponents of open-source software and hardware, you’d think we’d be pouring the champagne. But it’s trickier than that.

Part of the reason that they are able to publish a completely new, open-source driver is that the secrets that they’d like to keep have moved into the firmware. So is the system as a whole more or less open? Yeah, maybe both.

With a more open interface between the hardware and the operating system, the jobs of people porting the drivers to different architectures are going to be easier. Bugs that are in what is now the driver layer should get found and fixed faster. All of the usual open-source arguments apply. But at the same time, the system as a whole isn’t all that much more transparent. The irony about the new NVIDIA drivers is that we’ve been pushing them to be more open for decades, and they’ve responded by pushing their secrets off into firmware.

Secrets that move from software to firmware are still secrets, and even those among us who are the most staunch proponents of open source have closed hardware and firmware paths in our computers. Take the Intel Management Engine, a small computer inside your computer that’s running all the time — even while the computer is “off”. You’d like to audit the code for that? Sorry. And it’s not like it hasn’t had its fair share of security relevant bugs.

And the rabbit hole goes deeper, of course. No modern X86 chips actually run the X86 machine language instructions — instead they have a microcode interpreter that reads the machine language and interprets it to what the chip really speaks. This is tremendously handy because it means that chip vendors can work around silicon bugs by simple pushing out a firmware update. But this also means that your CPU is running a secret firmware layer at core. This layer is of course not without bugs, some of which can have security relevant implications.

This goes double for your smartphone, which is chock-full of multiple processors that work more or less together to get the job done. So while Android users live in a more open environment than their iOS brethren, when you start to look down at the firmware layer, everything is the same. The top layer of the OS is open, but it’s swimming on top of an ocean of binary blobs.

How relevant any of this is to you might depend on what you intend to do with the device. If you’re into open source because you like to hack on software, having open drivers is a fantastic resource. If you’re looking toward openness for the security guarantees it offers, well, you’re out of luck because you still have to trust the firmware blindly. And if you’re into open source because the bugs tend to be found quicker, it’s a mix — while the top level drivers are made more inspectable, other parts of the code are pushed deeper into obscurity. Maybe it’s time to start paying attention to open source firmware?

Gridfinity: 3D Printed Super Quick Tool Storage And Retrieval

Our favourite cyborg [Zack Freedman] has been stumbling over a common problem many of us will be all too familiar with — that of tool storage and the optimal retrieval thereof. His solution is the Gridfinity: A modular workshop organisation system.

Never chase your pen around on the desk again

In [Zack]’s words, the perfect workshop has tools and materials arranged in the following way: (a) every item has a dedicated home within reach of where you’ll use it. (b) items are exposed and in position for instant grabification. (c) the storage system shields you from accidents like spills and injuries. (d) it is effortless to setup and easy to put back and rearrange. An instant-access storage solution such as the Gridfinity is designed not to help you store more stuff, but finish more projects. The idea is very simple — display your stuff so that you can quickly find what you need and get back to the project as quickly as possible. We think these aims are pretty spot on!

From an implementation perspective, the system consists of a 3D printed base plate with a grid structure. It is angled internally so storage bins drop in, but are not easy to knock out. Storage units drop into the grid in various sizes and orientations, such that everything is contained within the grid’s outer boundary, so the whole assembly will fit inside a drawer with ease. Small part storage bins have a curved inner surface enabling one to easily scoop out a part when required.  A partial lid on the top allows them to be stacked vertically if required.

Super-quick access to fully sorted stock – no more searching

Whilst the system is work in progress, there are still about a hundred different storage units, for anything from 3D printer nozzles to racks for tweezers. Implemented as parameterised models in Fusion360, it is easy to tweak existing models for your stuff, or create totally new ones, from the supplied templates.

No discussion of tool organisation would be complete without first considering the king of tool organisation [Adam Savage], the principle of first order retrieval is a strong one. For a more in-your-face solution, you could go down the pegboard-on-wheels route, or perhaps if you’re less mobile and in a tight squeeze, then get comfortable with the French cleat and build something full custom right into the walls. Whatever solution you come up with, do share it with us!

Continue reading “Gridfinity: 3D Printed Super Quick Tool Storage And Retrieval”