reynoldsbd

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.

Love it when a band does something weird or interesting with their website. My favorite is The Strokes:

https://www.thestrokes.com/

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.

> 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.

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.

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.

Counterexample: comedy central now has to work to redact all noncompliant programming.

Best practices are funny because context and history are important. Actual regulation is not so forgiving.

This is incredibly false. When you change the law, you can't assume that people who are currently in compliance will continue to be.

"We could have done it this way." doesn't pay the bills (or in this case, doesn't prevent steep fines).

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.

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.)

> then you can't use .Net

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

Finally, USB-C in a Surface product!

Buying a PlayStation or Switch is voluntary, too

Yes indeed

Could somebody explain the difficulties of implementing true ASLR for the kernel?

Lack of a federal law doesn't necessarily make that comparison invalid; perhaps there should even be an analogous law protecting "free speech platforms" that is rooted in the first amendment, similar to how the law you cite it ostensibly rooted in the second.

Not sure if it's already possible, but it would be nice to have nested navigation (like with drop-down sections).

Even without that, though, Min is really exactly what I think of when I need a lightweight framework that gets out of my way.

Maybe some better sea monster repellent? ;-)

At first I got this confused with mincss [1], which is my go-to for quick and dirty sites. This looks like it could be a good option too!

[1] http://mincss.com/

It's specifically a vulnerability in system firmware, and they provide a nice table listing the affected ranges of firmware versions.

Nope, it's conhost.exe

> Tabs are 8 characters...

The madman!

/s

Actually, now that I think about it, he has a point. Having a little more horizontal space seems like it would be easier on the eyes.

Thanks for reaching out! Just plain FireFox on Windows. Automatic updates are on, currently at version 51.0.1.

Let me know if there's anything I can do to help!

I don't even know where to begin debugging. My browser just locks up and has to be killed. Usually before the page with the REPL even starts rendering.

Weird.