Read the article. It was a >local< event at one of the magnets which caused the whole magnet to freeze over. The "consequences" are, that the whole accelerator needs to halt operations to repair the element. That takes quite a while and will postpone the schedule..
In most cases players were using a smartphones on the toilet.
Generally there are some more options:
- using a small bluetooth headphone with external person telling you the moves
- a vibrating device on the body that vibrates you the moves
Yes it's possible ( https://www.ha-obsession.net/2017/05/u2f-sudo-fedora-25.html... and some other guides exists ) and I used it for about a year. I stopped using it. I was so annoyed to plugin the key every couple of hours that I simply kept the yubi key plugged in all the time - free to be picked by anyone and def. not increasing security.
RYSTA | Berlin, Germany | Partially Remote (EU time zones) | Part- & Full Time
RYSTA is a startup in Berlin changing the way we live and work in our buildings. We are a team on a mission to shake up a traditional industry with a new way of operating.
At RYSTA, we build cutting edge IoT sensors, collect massive amounts of data and deliver mission critical insights to our customers. For construction sites and buildings our platform offers multiple applications including air quality monitoring, reducing virus transmission and construction site monitoring.
If you are the sort of person who loves building solutions then we are looking for you. You love a challenge, are motivated by solving problems and are excited to implement your own ideas in software and hardware products.
We're hiring for two roles:
(Senior) Backend Engineer | Remote
Be responsible for sensor data processing and abstraction for product development.
Javascript, Node.js, PostgreSQL, Microservices,
https://en.rysta.de/jobs-backend-data-processing
Embedded Product Engineer | Onsite Berlin preferred
Build tools to ensure the perfect quality of our sensor hardware
Python, C / C++, experience with embedded hardware
https://en.rysta.de/jobs-embedded-product-engineer
It failed because building an efficient solar panel is already hard enough without thousands of cars running over them. Just build a solar-roof instead.
Make him understand that he is actually the customer and not an employee / entrepreneur. As long as he gets that and is not betting his career on it - let him play.
I'm deeply sorry, that you have to read those disgusting words in your mailbox. To be honest, it even hurts me.
There are tons of people like this, I observe this behavior more and more these days. Go and talk to a random youtuber/twitch streamer how much hate they have to deal with for their "free" content.
I once thought its the German culture (doing business and earning money is almost a nono-thing in Germany and makes you an easy target), but I guess some humans are just like that...
I can confirm this - I got similar information from several employees. The market is extremely hard and doesn't scale well. They did a great job solely by surviving and I'm really happy, that their hard work is rewarded now.
I used -Os as for any embedded code where I don't care too much about the performance and rather need a compact binary.
I would love to post my code snippets from back then, but Im not home currently and the time Im back home I guess nobody will care about this anymore :D. Maybe I put it into an article.
I have to admit, that C++ is still not the industry "Go-To" language for embedded. But if you apply modern C++ correctly, there is very few overhead compared to C and the software is much easier to maintain.
The performance of embedded MCU's are continuously rising over the years and that little overhead is buying development speed.
Not to mention smart pointers, templates and constexpr making my life easier.
The only real issue with C++ is, that as soon as you get into serious embedded applications, you have restrictions when it comes to heap usage e.g. in medical devices using the heap is forbidden. So you cant use the STL.
There is a promising embedded STL project, but it's not there yet: https://www.etlcpp.com
1. Do you see the bloat even if you don't use post C++11 features but compile using the C++17 standard?
Yes, actually I tried using various C++ snippets and even reported that to the GCC compiler team. It happens with simple stuff like std::string and std::vector. The response was something like, that there really seems to be a bloat, but no performance impact and I guess most users outside of embedded don't care too much about the size of the compiled binary.
2. Do you think it is mostly the compiler that is causing the bloat alone? Or is it stuff from the standard library header files that some how gets linked in (and are not used or needed by your software)?
That's actually a very good question I cant give an answer to - meaning I haven't looked specifically into that.
As C++17 came to GCC I played with the compiler explorer and observed this by just switching gcc/clang version and -std flag. Actually, you can try it yourself: https://godbolt.org/
C++17 is definitely going in the right direction for most applications.
But I have the feeling, that the compiler implementations cannot catch up with the modernization speed.
We are using C++ for embedded devices and recognize a steady code bloat with every release since C++11 (especially with C++17) without using any of the new features (with gcc/clang). This is a trust-killer and actually the reason we stay on C++11 for embedded development.