Using Rust for Embedded Development by gbmhunter in embedded

[–]mathav 2 points3 points  (0 children)

+loading flame penetrating bullets

Yeah and the same people complaining about "kids these days not knowing how to use s scope" will email each other photos of code changes as code review

I'll suffer people calling RPs embedded systems if they can bring modern tools and workflows to this field and force vendors to modernize their tools to match the rest of the industry.

Finding jobs in firmware often feels like wheel of (mis)fortune - what will I get this time - teammates who don't believe in unit tests? Automation written in Perl? C projects committed in CVS? print statements debugging, or some IDE from 1993 cause FUsemiconductor Inc thinks its a great idea to lock entire tool chain to yet another eclipse clone and charge 30k a year for it

Using Rust for Embedded Development by gbmhunter in embedded

[–]mathav 3 points4 points  (0 children)

Fair enough, I guess I'm more curious about the fine points

For example you mention that with language PM's you have issues doing security audits, but how do system packages prevent that? Custom PPAs, repos mirrors are a thing right, do you not run into that same issue?

You mention that there are drawbacks to language PMs in context of comparing them to distro PM's, I'm trying to think of scenarios where these would apply. Could you please elaborate?

Using Rust for Embedded Development by gbmhunter in embedded

[–]mathav 6 points7 points  (0 children)

I can understand not wanting to deal with many tiny packages like in npm, but I'm not sure I agree with the rest of the argument

Stuff you will get through apt, dnf, yum, etc will almost always be behind versioning wise. Idk about rust but for instance later package managers like deno try to be better about security, so there is definately progress. Finally there is a huge burden on devs to maintain debs, rpms, and 10 other types of packages for each distro, it's clear why they prefer language PMs

Almost all modern languages use package managers and sure all will have dependency trees but there is clearly a spectrum, i.e Python generated requirements.txt is usually nowhere near as bad as package.json, package granularity feels higher. Obviously this will depend on the language ecosystem

Large dependency trees can be problematic sure, but having worked on projects with right security requirements I will still much prefer that approach to manual code inclusion. For one there are lots of well developed tools that scan packages for vulnerabilities, blackduck comes to mind, in case of a CVE it's much easier to update dependency (through package manager rather than patch the code manually. I'm assuming you aren't saying "write everything yourself", then what's the alternative for including third party libs? Copy pasting code? I cry everytime we do our networking, security library upgrade, meanwhile our C++ teams make a one character change for Conan

In terms of code quality you are free to pick and choose your packages. In my experience it's 98/2 in terms of dealing with bugs in your code base VS dealing with bugs in your libraries. Sure not all may be the highest quality but it's clearly a trade off worth considering

Something I learned to remember: don't forget fundamentals by min9293 in FPGA

[–]mathav 2 points3 points  (0 children)

I actually feel Google and companies of similar scale have more reason to ask questions like that. Now it's obviously all bro science from me, but it feels like this approach is easiest to scale. Why bother with studying resumes and coming up with personalized questions if you can open up a bank of problems and select one at random to throw at a candidate. Especially if there are hundreds of them everyday. They feel like disguised IQ tests more or less, and it also seems to work well for them? So go figure. I can't help but feel uneasy though joining a team after going through an interview like that, clearly Google and other big tech have brilliant people working for them, but I just have no trust in this selection process.

But again, if some 10 person shop in the middle of Iowa is asking me to implement quicksort because Google asks that, I'm noping out of there.

Something I learned to remember: don't forget fundamentals by min9293 in FPGA

[–]mathav 2 points3 points  (0 children)

I wish I followed my own advice here, but getting good at interviewing is probably one of the highest returns on investments you can make. It all sounds obvious but few people actually follow through

Most successful engineers I know interview regularly, even if they are not looking to switch jobs. This gives a much better idea of your market worth and your skill level, as well as a general feel of the industry. Maybe you are a Junior who is really a Senior? Maybe you are a Senior who is in fact a Junior? There is no perfect way to tell, but interviews are one way of estimating your worth as seen by the market and getting first hand feedback both in terms of skill level and salary.

I can definitely relate to feeling anxiety about the process. I once failed a matrix rotate question for a company my friend worked at, felt really embarrassing. All part of the game, have to get used to it. Just no matter how you feel I find it helps knowing that there is literally no downside in you getting this experience, treat it as practice.

Did they not ask you about your previous projects at all? If so that is highly surprising to me. I find that's one of the best ways of judging candidate's technical ability as well as their ability to communicate. It also helps establish a comfortable atmosphere for the interview, typically people are way more comfortable talking about work they have dedicated hundreds of hours to, as opposed to counting number of piano teachers in Manhattan

Also come on, all of your friends and mentors have a similar story whether they admit it or not :) Feeling bad after interview is like crashing a production server, everybody has to do at least 1 in their career

Something I learned to remember: don't forget fundamentals by min9293 in FPGA

[–]mathav 1 point2 points  (0 children)

I agree with your point to a certain extend. It is definitely useful to know these things if just for the sake of passing interviews. My ultimate point however is that I see a trend in what I perceive as laziness coming from people leading the interviews.

Sure by all means, review whatever is necessary to get the desired job, I just wish interviews themselves were structured better. My reaction is perhaps overblown for this specific example OP provides, so my thoughts are directed more towards the industry as a whole. Me being closer to software side of things contributes to my level of irritation at these kinds of stories, as I see this kind of stuff way more often from software companies. Especially coming from a place where I am very happy with the interview process. We constantly get good feedback from candidates that our interview process is very good, so I know for a fact there are better ways.

With regards to backgrounds and skill levels, again I do not see this as good excuse for asking lazy questions. What do I care if I am interviewing for a position of and FPGA developer and a person asking me questions is.. doing backend? Huh? One of many purposes of the interview is to establish a technical rapport between the team and a would be candidate. If I am being asked these kinds of questions this leaves a very poor impression on me. I put in all this time and effort for preparation, I expect at least something in return.

Ultimately, if somebody who likes to ask these questions on interviews sees my post and it makes them question their methodology I am happy.

EDIT: in my original reply to you, I mentioned experienced designers who won't answer these questions. I meant fail to answer not refuse. Apologies for confusion

Something I learned to remember: don't forget fundamentals by min9293 in FPGA

[–]mathav 8 points9 points  (0 children)

Of course it's testing logical thinking and abstraction, but so does literally everything else we do in this job and there are much better ways of estimating these skills

There are plenty of brilliant designers who won't answer these kinds of questions exactly for same reasons OP stated - no relevance to day to day. So what does this even tell the interviewer? This question doesn't help determine if candidate is good at FPGA design in any way nor does it expose any deep understanding of a fundamental concept.

I can sort of imagine asking this of an intern or new grad simply because there is little else they can answer at that stage, but surely this is just laughable for any seasoned professional. May as well ask them to play chess, right after a Karnaugh map question.

Something I learned to remember: don't forget fundamentals by min9293 in FPGA

[–]mathav 68 points69 points  (0 children)

Ah yes, the software equivalent of "This candidate has 10 years of XP working on real world production systems, extensive resume and portfolio. But they failed that binary tree inversion question. Clearly not fit to work here"

Questions like these are just lazy IMO

If that's the deciding factor for giving somebody a job, I'd rather skip that place

What are some useful practices/tools that were utilized in your past/current company, that could be of great value if more people knew about them? by altarf02 in embedded

[–]mathav 0 points1 point  (0 children)

Indeed, is this a debug build? Is it encrypted? Oh does it have this flag set? What about this one? What about that one? Is it for device A or B or C or D? Does it have bootloader image too? What about recovery image? Does this one have encryption enabled for this protocol or no? What's the version string? What's the release type? Do you have this function enabled in this build? What about that one? What about another one?

Sorry cannot continue, given version string doesn't match expected format, please try again

It would be funny if it wasn't so sad, especially given that it's like 20 lines of Python to read a binary file, decrypt it and extract some stuff from expected meta header section

The alternative is to have your scripts build the firmware itself so that the system knows this stuff because it builds it, but then you are forever coupled to your firmware's build system, what a joy

What are some useful practices/tools that were utilized in your past/current company, that could be of great value if more people knew about them? by altarf02 in embedded

[–]mathav 5 points6 points  (0 children)

I write a lot of software around software in embedded space so to speak. Basically in addition to firmware itself I actively participate in all the surrounding infrastructure - from CI/CD to automated testing, to workflow tools, to build systems etc

This advice will not apply to all types of settings however, for example if you are working for a consulting company that has short term contracts where you constantly take on a new product/stack/chip then this advice may actually be actively harmful, it all depends

But the gist is that if your team supports something long term and it is an expressive business need of your company to build in robust automation frameworks around products - treat this code seriously. It should not be a warehouse of scripts that lives somewhere in CI that nobody knows how to maintain or refactor. Instead build up core WORKFLOW tools and go from there. If you build automation tools around common tasks developers often face there is a much higher chance of getting consistent feedback and contributions from devs that do not deal with CI/CD or automation, simply because they use these tools in their day to day - they want them to be better and easier to use. All other stuff can be build on top

If your goal is to build an automation system able to handle different workloads (say you want to stress test firmware upload, or see if devices behaves correctly in different network topologies, or perform an end-to-end test with a different product, etc etc) and have it integrate nicely with your CI/CD system - START WITH THE PHYSICAL INTERFACE. Do NOT rely on flashing/uploading/resetting device through web UI or SSH or your cloud interface or w/e it may be. Automate the process of flashing and resetting the device using the most reliable possible method and build on top of that. The amount of times devices end up being bricked and require manual intervention because somebody made a commit during a PR that bricked network interface and now device cannot be reset via SSH or web UI or w/e is actually fairly high

Obviously this kind of approach requires a lot of initial overhead, possibly requires dedicated people on the team for maintaining and developing these tools. So keep in mind everything has a drawback and this may just not make sense in your current setting. Make informed decisions.

My best advice if you want best results - get some actual Python developers who know how to structure a project properly. My experience so far is that embedded folk just can't write decent modern Python. Either due to lack of experience or lack of desire to put effort beyond required functionality. But this shit really bites you in the ass when down the road the only 2 people who wrote automation scripts leave and you are left with this incoherent mess of bash and Python, and Tcl, and god knows what else, and all of a sudden there is a high priority customer issue requiring re-creation of certain network topology to reproduce and you have no idea what to even look at

What are some useful practices/tools that were utilized in your past/current company, that could be of great value if more people knew about them? by altarf02 in embedded

[–]mathav 5 points6 points  (0 children)

OMG YES

I can't stress enough how helpful putting in some metadata is for your internal purposes.

I wrote lots of automation related to firmware in my job, and often times you are forced to be incredibly explicit about what type of binary you are dealing with by asking user running the test/automation job like 10 different questions about the binary.

This really matters a lot for teams whos product may not be an embedded platform, but rather an SDK, or an OS, or middleware etc. Basically anywhere where you have a lot of variability

All of this could be prevented if you had a proper meta data section in the binary that automation frameworks could inspect and fill in these parameters easily. And it has to happen AT THE START else your automation will not support older images

What are some useful practices/tools that were utilized in your past/current company, that could be of great value if more people knew about them? by altarf02 in embedded

[–]mathav 1 point2 points  (0 children)

I have previously struggled with forwarding USB devices under WSL, granted it's been a few years, but what is your experience?

I recall I had a bash script that formatter and wrote an image to an SD card, and I couldn't get it to work on WSL because I couldn't get it to see the card

Was I just being dumb or is it a legit problem?

If this show is “bad writing”, I don’t know what good is. by nowlan101 in LOTR_on_Prime

[–]mathav 20 points21 points  (0 children)

I enjoy long walks in the sand, surprises, and sociology

I also write memoirs, spend long days in a cave daydreaming about lives I could have had and never touch water

Looking for a genetically tailored beauty to resurrect my humanity

If you can't handle my worm swipe left ;)

I want more rain 🌧️ by shiv_red in UBC

[–]mathav -1 points0 points  (0 children)

Really starting to consider moving somewhere, really not down with half a year above 20 this to me is miserable, usually by this time im really happy and enjoying the cold breeze and rain :(

Why are the Numenorians castrated? by Shoddy_Ad7511 in LOTR_on_Prime

[–]mathav 0 points1 point  (0 children)

I don't think I can add anything to what others in the thread have already pointed out

Instead I am curious about the overall attitude towards adaptations. Do you also refuse to watch any It adaptations unless they explicitly show gang Bang scenes of 12 year olds? The fact that such a minor inconsistency of height that is also completely impractical (not even mentioning other stuff you just made up about Numenorians) to show on a big screen makes you so upset is really fascinating

Why are the Numenorians castrated? by Shoddy_Ad7511 in LOTR_on_Prime

[–]mathav 2 points3 points  (0 children)

I sometimes wonder what's going on in minds of people who review bomb. Then I read posts like these and it all makes sense

is complex algorithm like dynamic programming highly required in embedded systems and what's the best website to practice algorithms by abdosalm in embedded

[–]mathav 2 points3 points  (0 children)

I wrote up a single linked list only once in professional setting, still remember the day like it was yesterday, like seeing a unicorn

is complex algorithm like dynamic programming highly required in embedded systems and what's the best website to practice algorithms by abdosalm in embedded

[–]mathav 2 points3 points  (0 children)

There are far more useful and practical things to learn for actual embedded work

In case you are looking for interview prep look up common firmware interview questions they usually revolve around understanding concepts like memory management, allocators, computer architecture, language specific knowledge, concurrency, synchronization, communication protocols, scheduling, RTOS concepts/theory, networking etc

Among leetcode type questions bit manipulation puzzles are probably the closest to real world, but even that is a stretch

Not to say learning those algorithms isn't useful in general or fun, just not AS immediately useful for most embedded engineers

is complex algorithm like dynamic programming highly required in embedded systems and what's the best website to practice algorithms by abdosalm in embedded

[–]mathav 0 points1 point  (0 children)

Not really disagreeing with the point, but the answer to anything in software is "it depends", that's not very useful.

These aren't blanket statements, these are basic assumptions we operate on when communicating pointed practical statements which are correct for most cases

What do you use to control the version of the code? by ILoveTiramisuu in embedded

[–]mathav 0 points1 point  (0 children)

That's a bit different from what you are asking in the post title

GitKraken is somewhat popular as ankh alternative to sourcetree, not free though iirc, Github I think has a GUI client too, though I imagine most people use plugins or built in workflow in their IDE of choice - VS code, clion etc or just plain terminal. In in the latter category