I’ve found that good logging/tracing discipline can play an important role here. For example, my team has a guideline to put a debug! message before blocks of code that are likely to fail. Then if something goes wrong, we can dial up the logging level and zero in on the problem fairly efficiently. With this model, we don’t find the need to use any third party error framework at all.
In the abstract, we are basically treating the error as a “separate thing” from the context in which it occurred. Both are of course strongly related, however the way some of these error libraries try to squash the concepts together can be quite opinionated and doesn’t always facilitate smooth interop.
Not saying this is the only way to deal with errors, but it’s just one way of thinking of the problem that I’ve had pretty good success with.
Current MS employee here. For a time this was true, but FF recently added this integration. No about:config needed, there’s simply a checkbox under the FF security settings. Since this was added, I have gone back to using FF as my daily driver, and I haven’t really encountered any other friction.
I'm fortunate enough to have just landed on a new team working with embedded Rust. Here are some of my takes, in no particular order.
The language and ecosystem have come a long way in a very short time. It's easy to use safe `no_std` Rust on the stable toolchain for 98% of your code, and there are crates available for all kinds of things like memory management, register access, or even async runtimes.
Compared with C, Rust is absolutely a game changer in terms of reliability/safety/productivity. Every line of C code is a potential liability, because humans make mistakes. Having a compiler that smacks me down is invaluable; it results in a safer and more reliable program, and it helps me get it right the first time. Like many others, my experience with Rust is nearly always "if it compiles, it works". This is _especially_ valuable for embedded programming, because debugging is often way harder when working with hardware.
One major drawback is lack of support/engagement from hardware vendors. They pretty much assume you are using C, and all of their IDEs/SDKs/codegen tools/whatever are written with that assumption. This probably isn't going to change any time soon (ever?). What this means is that if you want to use Rust, you'll be on the hook for figuring out a lot of low-level things like linker scripts, boot sequence, or memory/clock initialization. Often this means reading or reverse-engineering the vendor's SDK to figure out how these work. If you're working at a big company on a serious product, you might have done this anyways. But for a hobbyist, this can be a huge barrier.
> One major drawback is lack of support/engagement from hardware vendors. They pretty much assume you are using C, and all of their IDEs/SDKs/codegen tools/whatever are written with that assumption. This probably isn't going to change any time soon (ever?).
My assumption is that with the advent of rust getting into gcc, you will see at least some of these changes starting to make their way into toolchains. Probably not for the MSP430, but possibly for the next generation of embedded chips.
Is rust interoperable with C and ASM? I would think it'd have to be. Some of those things (all of them?) are considerations the system designer needs to worry about regardless.
It seems like you should be able to still use most of the stuff provided by the toolchain in a similar fashion. That said, trying to do a native implementation by porting the code, or just using a C/ASM bootloader could prove tricky for newcomers.
Bootloaders are often black boxes. It could be flashing something written in COBAL, and it would be none the wiser. It seems like rust would need to provide a mechanism for entry pointing. I don't know how to handle memory mapping and linker scripting in rust.
I'm not disagreeing that it could be a huge barrier, but theoretically it doesn't have to be that much, or at least most of it is stuff you'll often be dealing with anyway.
so what you are saying, is that rust solves the issue of finding competent engineers. you can use a language like rust such that engineers don’t need to be any good. it reminds me of microsoft frontpage and all the other scripting languages and tools that have been created to solve this issue. but here we are in 2022 and nothing has changed. people still hand code css and html to get what they want.
embedded software engineering is about understanding the hardware and leveraging its power through good architecture and smart thinking and understanding what the code you write will do. you can’t shortcut this by using a new programming language that does the work for you. you will still need to understand the low level details. so, learn C++ and familiarize yourself with the related embedded standards for reliability and safety.
adding rust into the mix will now require you to maintain code in not one but multiple languages as you cannot get around C or C++ and possibly assembly. it’s already complicated enough as it is, and you should focus on understanding the principles instead of learning another set of syntax and implicit logic.
Nice gatekeeping. Perhaps you could provide some concrete examples of how Rust is worse than C++ for embedded programming, when it comes to "understanding the hardware and leveraging its power through good architecture and smart thinking and understanding what the code you write will do"?
To me it is very strange that you would act as if Rust is some dumbed down toy language (not your literal words, but I conclude this from your MS frontpage example), while it is considered (not entirely deserved, in my opinion) difficult to learn with a very steep learning curve.
Personally I find programming in C quite annoying because of all the sharp edges (e.g. implicit integer promotion, the various types of UB) that you have to keep in mind. To me this distracts from thinking about good architecture, rather than promoting it.
I take something very different from the grand-parent post: the language requires you to get the design mostly correct to even compile. Unexperienced developers won't be able to come up any non-trivial new designs of their own, but can reuse existing code and even experienced developers have to fight the language to get a prototype stood up, but once they've working code it's more reliable. Not every line of code could accidentally reconfigure your PLL or voltage regulator just enough to drive you insane debugging a glitching chip.
> rust solves the issue of finding competent engineers
That's a very cynical take, but I think there's a kernel of truth in there somewhere. Rust does indeed make it much harder for less experienced programmers to make certain classes of mistakes. Why on earth would that be a bad thing?
> you can't shortcut this by...
"Using Rust" and "understanding the hardware"/"good architecture" are not mutually exclusive, and Rust is not a shortcut. Embedded programming is still very hard. In some ways, Rust can make it even more difficult by forcing your code and architecture to follow additional rules.
> cannot get around C or C++
Speaking from experience, this is false. It's perfectly possible to write embedded applications using only Rust and assembly, without a single line of C/C++. I do it every day.
> so what you are saying, is that rust solves the issue of finding competent engineers.
It’ll be a depressing time when the demand for engineering is lower than supply. Until then people with needs larger than resources will find alternatives to “finding competent engineers.”
That said, Espressif seems to be moving past pure embedded and positioning themselves in IoT, for example the latter part of ESP-IDF stands for IoT Dev Framework. This allows them to provide a single way of doing things regardless of implementation within the broad ESP32 family.
Will the results be the equivalent of Frontpage websites? Sure, and as any of those start getting the resources to need and use “competent engineers” they will unlike the efforts that would never have gotten off the ground.
The issue they bring up in more that hardware manufactures will have things like
#define BLINKY_LIGHT_ADDR 0xDEADBEEF
in a standard set of headers distributed with their toolkit. That magic address is where you write to turn a light on or off.
Now, they will almost certainly also define that sort of thing in a datasheet, somewhere, but for the average embedded dev it's far simpler to pull in the SDK and use that.
This isn't some sort of "good programmer bad programmer" filter. This is a "I don't want to read a 40 page pdf of a datasheet to find out what you named light 1 and where that address is"
Something like your Bluetooth communication is dependent upon a C-based "communications stack" that demands to control the event loop and all the registers aren't even documented.
"Where is the LED?" is easy to work around. "How do I put my BLE system into low power advertising mode?" may not even be possible without accessing the C library.
That’s a fun example, because while you’re right, that may also be changing. Android’s new Bluetooth stack is in Rust, in my understanding. We’ll see if more vendors provide even more stuff in Rust in the future!
My experience in a big metro area has been that almost every Uber driver does this full-time, and their vehicle is for the sole purpose of Uber. I guess it depends on where you are.
Absolutely! Anybody who does business in Europe or even has users in Europe is subject to this law.
The amount of effort being put into GDPR compliance within my organization is just staggering. It really makes me think about these kind of laws from a new perspective, because they cost businesses so much to implement.
(I'm not saying whether GDPR is right or wrong! Just that it's expensive.)
I would (maybe naively) think that the cost of GDPR compliance would be small if your company is already safeguarding user data and respecting user privacy. If a company’s cost is “staggering“ doesn’t that say a lot about its existing privacy practices?
I'm not sure. I think this is a very absolutist and probably naive way to look at it, frankly.
For a simple example, let's say you use an immutable data store. What do you do if a customer wants every info about them redacted, but you did something like store their IP, name, or email. All common things. Now you must build mutability into your store and all assumptions that used to be made can be removed.
This is just a very small piece of something that even a small or medium company may be using or doing.
Will this satisfy GDPR requirements fully? What if that key had somehow been involved in an unknown leak in the past (of just the keys) and then the data is exposed somehow in the future?
Leaks are punished, as they probably should be, under gdpr anyways. But now do we have to account for all of the keys over time and have it be probably gone? What if we take backups of the systems that stores the keys? Do we have to purge those backups as part of the deletion request? What if they're terabytes in size?
Right, but you had assumptions built into your data store before, namely that you could keep all info about someone for eternity, and that you'd never have to correct it.
I presume you're talking about things like informing users how their data might be used, storing user data securely, and not selling it to third parties. That sort of stuff is relatively easy.
The GDPR imposes some new requirements that were not previously part of any privacy best-practices that I'm aware of, and that create some system complexity. Chief among these is the right for users to retract consent after it has previously been granted. This effectively requires processors to be able to delete individuals' data from their records, something that was not a design requirement of many systems. This becomes increasingly more difficult as user data has often been aggregated, and joined with other data sources.
Another key differentiation of the GDPR compared to previous legislation is that it applies not only to data that identifies a person (such as by containing a name or social), but to data that could in theory be linked back to the user through a common identifier. Previous best practices have considered the user's privacy protected if they were identified through a hashed email or an opaque database identifier, but the GDPR does not consider this sufficient anymore.
Thanks for the details! I can see how this could get costly for complex systems. As a user though I would think all those things you listed would be existing privacy best practices but I guess that’s being way too optimistic. Scary what companies are currently getting away with, too but not surprising.
I think you're right in that those things would be (or should be) considered "privacy best practices", but, unfortunately, most companies don't have "following privacy best practices" all that high on their list of priorities.
It's not even malicious; in the absence of regulation to the contrary, companies -- especially companies still in search of a revenue model -- have an incentive to collect as much information as possible.
Definitely not true. GDPR significantly broadens the types of data subject to legal requirements. Whereas yesterday I only had to protect PII and content, now even telemetry and performance data becomes subject to new rules.
This is a huge problem for an org that relies on huge amounts of such data to keep our product running and uses systems which were never built with these new rules and classifications in mind.
Furthermore, there are huge complications surrounding "data processor" scenarios (in other words, Enterprise SaaS products). For example, what takes precedence, GDPR deletion or our contractual security/auditing obligations?
Again, I'm not saying that any of this isn't worth while, just that when you get down into the weeds things look a little different.
I think the main issue that I see is that whilst GDPR doesn't massively expand the scope of what is personal data beyond that under existing data protection law, it does expand the territorial reach of data protection law.
US companies who previously had the narrow scope of PII to handle, now have to consider the much broader scope of 'personal data'. I am sure that for lots of US companies providing services to EU citizens/residents that will definitely represent a substantial burden.
Even for EU companies, the reality is that many will have previously taken a view that the size of potential fines was not high enough to warrant giving certain matters that much attention or at least spend money on areas they considered more important. For example, if I have a choice between implementing additional security measures to protect my network versus building functionality to delete on command, many companies will have gone with the former.
On retention, my view is that if you consider it necessary to retain information for purposes of auditing/security, and have made that clear in your contract with the client (who would then should make that clear in their privacy notice if they don't already have a general caveat around that), then the right to delete under Art 17 does not kick in because Art 17(1)(a) is not engaged. Also, dependent on the grounds on which you are looking to retain Art 17(3) gives a controller a clear ground to retain.
Also the right to erasure is one that will generally be directed at the controller. The controller would then flow down that request to a processor but that is where the contractual protections would come in, which in my experience, most clients are generally willing to accept.
From the article, the thing that jumped out at me was documenting it all. Sure, your processes may be perfectly pristine. Where's your document that shows that you considered everything? Don't forget to include development processes. And don't forget to update your documentation when your processes change.
Changing the processes may not be hard, if you're doing things close to right to begin with. Complying with the documentation requirements? That's going to be painful.
Just for starters, you will need to decide which data you have to process and which is optional. Some data will need to be kept for compliance purposes. How much anonymization will be applied. What data is in every single internal db in your org? Do you even know of all the internal dbs? Each data will have to be tagged with the collection basis, either legitimate interest or consent.
The GDPR is also -- as I've complained on here before -- less of a regulation and more of a framework for 30-odd individual country privacy regulators. Some parts of the GDPR, eg on consent, are laid out in black and white. Other parts aren't at all. And the EU wankers have declined to issue final guidance on the latter even by this date, less than 3 months from the compliance deadline.
There's also cute stuff in there like if you have more than 250 employees or engage in "widespread processing of personal data" (widespread processing left, of course, undefined) you will have to hire a Data Protection Officer. Said DPO must be in the EU and report to the ceo. This will be quite a nice cottage industry for EU lawyers.
American companies are probably unable to pick a lead regulator and hence will be subject to the individual regulators of each EU country. What happens when some french person (France has a very aggressive privacy regulator) complains to the regulator, and you are dealing with a regulator in a language you don't speak? I hope you enjoy paying legal $600/hour.
The GDPR does specify enough around consent (ie all consent-basis contacts must be default opt-out) to make it highly unlikely that any of your email or newsletter opt-ins are compliant. You will have to re-consent all of your marketing emails, and this may come with significant attrition. This will be painful for outbound sales, even outbound sales that currently is very respectful of opt-outs.
Data subjects can also do things like request a copy of all data (a so-called Subject Access Request or SAR), request deletion, and even freeze processing, which is supposed to stop processing without deletion. This must percolate through all third party systems, of which most companies will have a lot. Just start with your two mailing systems (transactional + marketing), logs, analytics, billing, salesforce, billing, etc. And as mentioned above, it is required to percolate through internal systems.
You will have to have an ugly discussion about backups. Are you going to roll backups at 30 days? That's probably not ideal. But what should happen when a data deletion request is received and that data is, of course, sitting in backups?
The short story is this is expensive and painful enough that, if I only had incidental European customers, I'd probably ignore it and close their accounts if they complain. This is very much not GDPR compliant, but as an American company, I'd do it anyway because of the expense of dealing with the above.
It says a lot about the cost of privacy, period. The cost would be staggering whether they're modifying existing things, or creating new things, just in terms of ensuring "Yes, we're doing this correctly".
I just find it hard to believe that the law is a significant cost to companies already doing the right thing. Sure, there is a non zero cost to ensuring your existing practices are lawful, which everyone must pay. But companies already in compliance shouldnt have to modify or create anything.
The companies that have to spend significant coin are the ones who are not already complying.
Part of the cost is -documenting- what you're doing. Ensuring the right stakeholders are involved and signed off on it. Etc. When there's a regulation to do it, suddenly you have to involve legal, and the business stakeholders want to better understand it, whereas before it may have just been the developers.
> Anybody who does business in Europe or even has users in Europe is subject to this law.
Anybody? Sure technically in the same way that going 58 in a 55mph zone is speeding and could get you a ticket. So the question remains assessing the probability of enforcement of a hypothetically a small US based organization who has European customers. As I read the replies on this page it seems to be a mix of people who have a great deal of theory and not a large amount of practical experience assessing the probability of something actually happening given breaking a European law.
Yeah, but is it expensive because of how you were set up before? In other words, if you weren't set up to be so cavalier with user's data before, would it be as expensive now?
That's just plain wrong. Not only might .NET be a good option for a backend system (which can, of course, communicate with any platform), but people have been using .NET on non-windows systems via Mono for many years
I'm actually really glad they have up until now left USB-C out. We're at a point in USB-C's life I'd consider it an anti-feature, and the Surface Book 2's no exception: This particular USB-C port is really only useful for adding a second display. It's more or less fine as an extra port, but anywhere it takes away a Type A port, or even the Mini-DP it replaced is a little sad.
For a mobile device one big plus of USB-C is USB-PD and the ecosystem of fast chargers and power banks it brings/will-bring. You can also use one charger for both your phone and laptop, which is useful even if you can’t charge both at the same time.
Ignore everything else and it’s a nice upgrade just for this.
My Surface Pro charger (the same one that comes with the Surface Book IIRC) has a USB port for charging phones as well, and unlike a USB-C charger, charges both at the same time.
While I lament non-standard implementations, much like Apple's old MagSafe adapter and the Surface connector, sometimes the non-standard version is vastly superior.
In the abstract, we are basically treating the error as a “separate thing” from the context in which it occurred. Both are of course strongly related, however the way some of these error libraries try to squash the concepts together can be quite opinionated and doesn’t always facilitate smooth interop.
Not saying this is the only way to deal with errors, but it’s just one way of thinking of the problem that I’ve had pretty good success with.