While many of us Linux and open source nerds share the sentiment you described, I seriously doubt waiters see him and remember how they murdered the competition by bundling software with Windows OS in the 90s and 2000s.
You could always buy a Linux laptop or an android tablet. Tablets and smartphones is where windows lost. Those devices far outnumber PCs. Your complaint about windows is old. You have options to not use it today.
Now he did lose my trust and that’s because of two things:
1. His association with Epstein. It is documented and quite possibly the reason for his divorce.
2. His trust made controversial deals during Covid. The poorer countries wanted the formula so that they could scale up production themselves. However, the gates foundation supported the patent on the vaccines instead and had themselves and middlemen to arbitrate price on the supply
This is an open source project in a technical sense (source is open and the license is open), but not in a social sense (no free as in beer available source code, no public support for everyone). Source code, as well as firmware updates and support, are provided only to the customers.
When I sell the print server, I ask the buyer for the printer model, check its compatibility, and sell the device + guarantee that it would work for the buyer's printer. If it doesn't work properly, I'm first trying to debug remotely, and I could not fix it, I'm buying the same printer on flea market and debugging and fixing it until it works, and contribute the fix to CUPS/SANE/printer driver package.
In other words, I sell tech support in a package, and I just don't sell the print server if it's incompatible with the printer.
The goal of this project is to provide *ready-to-use, no-DIY device*, to improve the underlying software by directly contributing to it, for anyone to benefit from the fix. If you want to contribute to the printing stack and already know where to start, you should improve relevant projects, such as CUPS, SANE, printer and scanner drivers.
> Many people believe that the spirit of the GNU Project is that you should not charge money for distributing copies of software, or that you should charge as little as possible—just enough to cover the cost. This is a misunderstanding.
> Actually, we encourage people who redistribute free software to charge as much as they wish or can. If a license does not permit users to make copies and sell them, it is a nonfree license. If this seems surprising to you, please read on.
You can buy only the firmware package as well, without the device. I'll send you the instruction on how to configure everything and which hardware modifications are required.
Selling non-free software under a GNU license != open source. The title will be misleading to most people. Nothing wrong with charging for your software, but you shouldn't call it open source.
If you're implying something, then please get your thoughts across more clearly. The title says "profit goes to open-source", meaning CUPS, SANE, AirSane projects, which are FOSS (free and open-source), if the publicly available code and collaborative development is what you're referring to.
Additional software (web interface, scripts, utilities) is free, the source code is included in the source package.
The customer is provided with the source code of the firmware components, and with the build system based on mkosi[1] to build the complete firmware: starting from bootstrapping Debian 12 builder image which cross-compiles the packages with additional patches and builds additional software, to ARM Debian 12 image with everything compiled in the previous stage, to the final squashfs OS file and MicroSD image.
Yeah sorry, I misread the title. I used Debian with CUPS on an SBC for something similar, but yours looks way more elegant. This concept is not just for old printers, BTW; a lot of new ones have buggy implementations or can't be trusted on WAN (looking at you HP). Thanks for the reply, wishing you success!
No prob! Hope we'll all get great 2D printer some day, from Framework or other user-facing company!
It's not that impossible than you may think: several Chinese companies have their own domestic laser printers, claiming of in-house components and development (Cumtenn, ZoneWin), and one company does inkjet printers in addition to lasers (Deli Printer).
Is there any method possibility to purchase the software install on my own hardware and/or other payment methods? It is impossibility for self to send money to Russia without «consequences» and crypto is unpleasant KYC to access, much less importation of shipment from RU.
Yep, you'll need an OrangePi Zero 3 board, MicroSD, a button, and some soldering skills. Several options for non-KYC cryptocurrency exchanges exist[1], I also accept PayPal (non-RU account). Mail me!
I think the nuance is that OP is charging for hardware , software, and service (firmware customization and support).
With regards to the software, it is open source but OP is only providing the code to customers who receive the end product. In part, OP is acting as a distributor of the software and is charging a fee for that distribution.
If anyone else gets their hands on that software, they can choose to become a distributor and make it publicly available. It’s their freedom to do so.
A overly simple way to look at is is that OP is choosing (as a small part of their business) to charge for the distribution of the source code but not the source itself.
In reality, it’s unlikely that OP will have a customer who only wants the source code and is willing to pay a fee for the distribution of it. Their customers are coming to them for the service and support.
The GPL is an open source license. It does not require that the source be public, just that people who receive the software also are granted the source with the GPL license.
I try to apply Hanlon's Razor to this administration, but it's hard not to occasionally entertain other explanations with the sheer volume of incompetence.
His power and authority prior to getting put in charge of the largest military in the world was being a talking head making bad calls on television, which is roughly a step above being a 'social media influencer'.
The same reason teenagers might use Instagram DMs to communicate about school projects - It's just the platform he's familiar with.
Or the same reason I have Whatsapp - communication in my social groups happens there, and if I don't have it I get left out.
Your explanations assume there is some deeper meaning, looking at the tradeoffs for each communication platform, and then coming to some rational conclusion. I don't think there's much evidence for that.
The people around trump just happen to be used to using signal to communicate, and if Pete doesn't get on board he gets left out.
The big anti-feature is that developers can block users from flashing the chips.
Yes, there's a security angle, but if I have the chip in my hands, I should be able to flip some pin to reprogram the chip and prevent all the e-waste.
A major worry I have is: the EU is bringing forth some serious cybersecurity regulations (affecting equipment with radios (WiFi, Bluetooth, ...) as part of the Radio Equipment Directive later this year, soon to affect everything as part of the Cyber Resiliency Act). This enforces some good security practice, but also has a lot of stuff in it that's way easier to comply with if you just say, "the device is locked down with hardware-protected write protection (or Secure Boot)".
To my understanding, there's nothing specifically preventing companies from giving the user the ability to disable write protection or load their own signing keys, but it means that the default will be to have locked-down devices and companies will have to invest extra resources and take extra risks with regard to certification into enabling users to do what they want with the hardware. I predict that the vast majority of companies making random IoT crap won't bother, so it's e-waste.
I am afraid this is a very narrow reading of the CRA. Did you read the act yourself or some qualified opinion by a European lawyer? Security updates are the default demand of CRA and not having them is an exception that requires an assessment of risk (which I would assume mean that it's only viable for devices not directly connected to Internet).
An (equally narrow ;)) quote:
"ensure that vulnerabilities can be addressed through security updates, including, where applicable, through automatic security updates that are installed within an appropriate timeframe enabled as a default setting, with a clear and easy-to-use opt-out mechanism, through the notification of available updates to users, and the option to temporarily postpone them;"
Thus, I expect RED to stipulate only radio firmware to be locked down to prevent you from unlocking any frequencies but the CRA to require all other software to be updatable to patch vulns.
I have not read the RED or the CRA, nor discussed what they specifically say with a lawyer who has read them. However, I have gone through a recent product R&D process in Europe where the product has WiFi and LTE connectivity, so it falls under the RED (even though WiFi and 4G are handled by off-the-shelf modules). I have read parts of the EN-18031 standards (mostly using their decision trees and descriptions of decision nodes as reference), I've been on a seminar with a Notified Body about what the practical implications of the RED are, I've filled out a huge document going through all the decision trees in 18031 and giving justifications for the specific path through the decision tree applies to our product. I've also discussed the implications of the RED and 18031 with consultants.
I don't doubt you with regard to what the RED and the CRA actually says. However I'm afraid that my understanding of it better reflects the practical real-world implications of companies who just need to go through the certification process.
18031 requires an update mechanism for most products, yes, however it some very stringent requirements for it to be considered a Secure Update Mechanism. I sadly don't have the 18031 standard anymore so I can't look up the specific decision nodes, but I know for sure that allowing anyone with physical access to just flash the product with new unsigned firmware would not count as a Secure Update Mechanism (I think unless you can justify that the operational environment of the product ensures that no unauthorized person has physical access to the device, or something like that).
EDIT: And I wanted to add, in one common use case for microcontrollers, namely as one part of a larger product with some SoC running Linux being the main application processor and with MCUs handling specific tasks, you can easily get a PASS in all the EN-18031 decision trees without an upgrade mechanism for the MCUs themselves. In such products, I can imagine a company deciding that it's easier to just permanently lock down the MCU with a write protect than to justify leaving it writeable.
Thank you, an interesting (and somewhat sad) perspective. Would be unfortunate if these two regulations combined result in less firmware update capabilities not more.
Yeah, it's sad. I can say with certainty that there are products whose developers would have decided to leave MCUs and/or SoMs writeable based on analysing the threat model, but where the rigid decision trees in EN-18031 around secure storage mechanisms and secure update mechanisms makes that too difficult to justify.
>> The big anti-feature is that developers can block users from flashing the chips.
There's a liability angle too. If a company (or person) makes a product that has any potential for harm and you reprogram it prior to an accident, YOU must take responsibility but will probably not.
Another angle is that the hardware may be cloneable and there's no reason anyone should be able to read out the code and put it into a clone device. There is a valid use case in making a replacement chip for yourself.
Companies will buy far more chips than hobbyists, so this feature caters to them and for valid reasons.
>> Yes, there's a security angle, but if I have the chip in my hands, I should be able to flip some pin to reprogram the chip and prevent all the e-waste.
What if the chip used masked ROM? Your desire is not always feasible. You can always replace the chip with another one - and go write your own software for it </sarcasm>.
BTW I'm a big fan of Free Software and the GPL, but there are places where non-free makes sense too.
Seriously now, where is that? The only scenarios I can think of are devices that could put others at risk. Large vehicles. But even, many countries allow modified vehicles on the road.
But everything else should be game. If it's my device and only me at risk, why should anyone else get a say.
At least the European countries I am aware of, the owners will have a hard time on a police control if the modifications aren't part of the allowed ones by law, and depending on the modification, it is missing from the car documentation.
I think that's what I was saying. Vehicle control software is the only place I think where certified code makes sense. When others' safety can be put at risk by your crappy coding. That's not a copyright/licencing issue, or even something solved by making chips harder to flash, it's a vehicle law.
TFA makes it sound like there are many others. What else is there?
How much chip re-flashing / re-use is being done at the moment? I'm not convinced e-waste is repurposed in any kind at any scale... although it's an interesting premise if electronics are more modular and can easily be disassembled, and e.g. millions of esp32 based chips end up on the secondhand market.
From what I've seen very little. I _think_ it's something to do with the kind of people who work on embedded systems generally wanting the freedom that comes with making things from scratch resulting in not that much interest in repurposing old things outside of making them work with their overall IoT network.
a. to salvage the microcontroller and other relevant parts (probably worth $4 off a board that would cost $100+ to replicate)
b. a weirdly hostile attitude about the ethics of reverse engineering regardless of the motives (guessing people have been burned a lot with people stealing their designs)
I've mostly worked on the frontend and don't have much knowledge of embedded systems at all but it wasn't anywhere near as hard as I expected. Keen to find some other ESP32 devices to tweak (suggestions welcome!). I guess even if making them unflashable becomes the norm it won't be too hard to just swap the ESP32 off the board with a new one.
Quite a bit in IoT market, especially in the low-mid tier and Chinese imports. There’s an entire ecosystem of custom OS’s for home automation that runs on these ESPs, ESPHome for example. I have flashed quite a few smart sockets to run Matt/kafka messaging client rather than unknown vendors software that has an open socket to offshore ips.
The ESP32 (and other ESP chips) are somewhat common in smart home/IoT gear, particularly for devices that are dependent on a cloud service to function. There's a growing trend in the smart home community of re-flashing cloud-dependent ESP32 based hardware with ESPHome, which makes the device fully local controlled, eliminating the risk of the cloud service being discontinued/enshitified.
It's not a particularly common thing yet, but smart home enthusiasts are becoming increasingly concerned about the expense and effort required to replace cloud-dependent hardware because the manufacturer decided the cloud service isn't worth maintaining anymore.
How is this different in practice to the regular ESP32's secure boot, where you can technically flash the chip with whatever you like but unless you have the signing key the bootloader will refuse to load it?
You can generate the keys on-device during the initial provisioning and have it encrypt the flash with that key, so every device generates its own unique key and there isn't any practical way to extract it; even the developer can't flash it directly, and OTAs are required to update the firmware. This effectively means nobody can flash the chip anyway since you can't know the keys. Is there some sort of attack vector here I'm missing that gets mitigated by preventing flashing entirely?
If the developers really wanted to you have the key, they could just write the per device unique key in the box or on the pcb. What you’re suggesting is more or less possible, the problem is you represent a very niche case. 99.9% of consumers don’t want to reprogram a chip already soldered to a board and it’s not worth the time catering to them. Also some IOT devices are left in physically insecure places like on the exterior of the home, you’d never want some to be able to extract the firmware key or re-flash those devices.
This is explicitly for IoT manufacturers that want to lock out people easily modifying a device (or bringing it back to life after it receives an "update of death") or the kinds of industrial customers that need to check a box for a cybersecurity audit.
These IoT manufacturers keep making all of these new products but the thing is, an ESP32 from several years ago is not that much different than one from today. They don't need much compute, anything difficult can take place on the cloud. So how do you sell someone new hardware if the first gen device is still perfectly capable? How do you sell a premium version if it's just the same parts inside? For the former, you can EoL a product by blocking it from cloud services (like Nest this week). If the firmware is locked, a hobbyist can't just flash modified gen 2 firmware and have the device functioning like normal. For the latter, you can lock the bootloader firmware so that it will only load the firmware that you want it to run (i.e. the basic or premium version).
When you say “this is explicitly for iot manufacturers…” are you referring to secure boot? That’s what I was referring to. I’ve done embedded development for about a decade, 6 at an IOT company, and our main motivation for using secure boot was to keep our firmware secure. The last thing we want is someone writing an article on the internet about how with this one easy trick you can break the security of the device and do whatever you want ( the devices are related to access control). If the company went out of business we’d have the option of publishing the signing key but it’d render all the devices vulnerable to malicious OTAs. Point is we’re not trying to lock folks out of tinkering, we’re trying to keep the devices secure. I understand as a side effect it means you can’t flash the device to whatever you want.
Also for what it’s worth these ESP chips are unbelievably cheap when bought at scale. The box the product comes in is probably more expensive
You obviously apply to the latter of my first paragraph. There are certainly applications where a device absolutely cannot be modified because then it defeats the purpose (i.e. security systems). What I'm talking about is something like a zigbee widget where it's job is non-critical. Not allowing user OTA updates is probably a good idea but preventing any changes to firmware for a non-critical device seems questionable.
E-waste prevention is hella important. It's a tough situation though. I think for a board that goes out in the public, even at a prototyping level, it's important to know the chip you have is not tampered with. I once wanted to make a little people counter at a university campus with an ESP8266. I simply couldn't make sure it's resilient against some CS students poking at it.
It takes little skill, 15USD soldering iron to solder 4-5 through holes wires, connect 10 usd programmer and flash a new firmware.
Investing in a (de)soldering station, with the risk of pulling all the neighboring components, breadboard/something to plugin your new controller or memory into for programming and what not? I’m not sure if I’d go through that trouble
Yes, but this I think is a bit sad. Once you have proper hard to crack security a smart kid from CS won't find it hidden decide to hack it and write blog post about it how he has done it. As long as it is not something dangerous sometimes having less security is better
Not really, if the evil maid is sophisticated enough to bring their own firmware to reflash your devices, they could also just swap the PCB containing the controller or solder in a new chip
I chose the word counters rather than eliminate for the reason you outlined.
If you're the vendor, you can add a tamper-resistant or tamper-evident design to raise the cost of ,component-replacement attacks. Which can be countered by whole-device replacement, which in turn is countered by device identity attestation, amd so on, in an endless arms-race.
Tamper-evident stuff and device attestation solve all these problems even without preventing reflashing. If you can't check if the device has been tampered with or replaced, preventing flashing won't help. If you can, you don't need to.
Most IoT devices implement security and integrity using one time burnable registers (more importantly for keys).
It's sad but yes, those devices are permanently bound to the vendor.
There is no real alternative though, a TPM based approach makes it more complex and is another closed system.
De-soldering an MCU and soldering on a new oneis typically far from trivial. We're typically not talking about dedicated big through-hole flash chips here. We're often talking about MCUs with integrated flash memory which are surface-mounted and often with pins on the underside.
In general, I find it easier to desolder and replace surface mounted parts. With those, you just have to hit it with some hot air, it melts all the solder at once, and lifts right away. The chips are small, so it's not too bad to heat the whole thing evenly with a small air gun.
Through hole parts need a lot more heat across a bigger area, or you have to go pin by pin. I've scorched many a through hole board trying to desolder something, cursing at those who didn't socket the chip in the first place.
Want to annoy a repair person? Pot the whole thing in epoxy.
The saving grace here is that ESPs have radios and require certification which is expensive. As a result it is common for vendors to use pre-certified modules that are provided on a modular PCB with castellated half-holes. These are relatively easy to desolder.
Ask any mainstream U.S. model anything remotely sexual and they all abort. Musk et al. claim they want free speech and no censorship, yet the U.S. evangelicals have their teeth so deep into the tech, that they block it or debank anyone who even remotely suggests women should have a pleasurable sexual experience.
Speaking of, I don't mind that in principle, but why does it linger so long on the "Success" page? It adds a handful of milliseconds of page loading and 30ms of computation, and an eternity (~seconds) of just an unnecessary delay before even starting to load the site I actually wanna go to, whys that?
Makes the page entirely unreachable from within the Harmonic hacker news client on android... Good idea in practice but defeats the purpose if it blocks legitimate users.
It's not a good idea in practice precisely because it blocks legitimate users. As it always will. It's not possible to do this sort of thing without blocking legitimate users.
Only looking for work involving mgmt config automation projects right now. If you're interested, feel free to let me know. I can build you something very impressive.
reply