|
|
FWIW the only good one I've seen is EWARM, but I've not built anything big enough for build times to be an issue. Also its been a while since I used it.
There's a trial and free code-size and functionality limited version.
The full license costs $$$ but their support has been good IIRC.
STM32cube above was good for generating drivers and HAL code, but it had no compiler then (probably was added later but I may be mistaken)
IAR Embedded Workbench for Arm | IAR Systems
|
|
|
|
|
Do you really have to build every new Linux release ? And if you do, why not do the rebuild, at the end of day, overnight?
And have you tried Yocto? I have not. But reputation I hear says: quite cumbersome one-time-setup, but Highly, customizable, regarding what to include/omit.
"If we don't change direction, we'll end up where we're going"
|
|
|
|
|
This isn't about linux.
This is about incremental compilation of ARM firmware.
It takes a long time to compile ARM firmware.
Real programmers use butterflies
|
|
|
|
|
I used to sell computer spares – but then I lost my drive.
"I have no idea what I did, but I'm taking full credit for it." - ThisOldTony
"Common sense is so rare these days, it should be classified as a super power" - Random T-shirt
AntiTwitter: @DalekDave is now a follower!
|
|
|
|
|
Wow - that really bytes. I have an IDE that sector of your career is through.
| Ravings en masse^ |
|---|
| "The difference between genius and stupidity is that genius has its limits." - Albert Einstein | | "If you are searching for perfection in others, then you seek disappointment. If you seek perfection in yourself, then you will find failure." - Balboos HaGadol Mar 2010 |
|
|
|
|
|
Was the business in a solid state when you crashed? That must have been hard!
If you can't laugh at yourself - ask me and I will do it for you.
|
|
|
|
|
SCuSI, but you SATA craziest things!
"the debugger doesn't tell me anything because this code compiles just fine" - random QA comment
"Facebook is where you tell lies to your friends. Twitter is where you tell the truth to strangers." - chriselst
"I don't drink any more... then again, I don't drink any less." - Mike Mullikins uncle
modified 11-Jun-21 13:59pm.
|
|
|
|
|
So two years ago, I created a service for a client, with which their suppliers could connect.
It's based on a "standard" (which turned out to be standard-ish) that even pre-dates XML.
So anyway, there isn't a GUI that the supplier can use to manage their account.
An account is created by the IT department, who creates a username and password and communicates that to the supplier.
Communicating passwords is a bit sketchy, but doesn't have to be a problem.
Turns out the IT department is using an ascending number (starting at 1) as a password and stores that in an Excel sheet 
Apparently, the only check I have is that a password should be at least 8 characters.
I didn't think I needed more than that as we're talking about an IT department here.
They simply tell their suppliers "your password to log in is 00000001." and not a single supplier has complained yet.
Now, I just had a discussion about storing those passwords.
"It would be nice if we could send the users their password in case they forget."
Out of the question because I hash passwords before I store them.
"But we're not storing user data and it would be more practical if we knew these passwords... We won't be hacked and even if we were it wouldn't be a problem since the data is not very important..."
Why the ![Elephant | [mastadon]](https://codeproject.global.ssl.fastly.net/script/Forums/Images/elephant.gif) am I even having this discussion in 2021 with a fellow IT professional!? 
Still better than their current system which does not run on HTTPS and actually shows your password on screen
No one can fix it either because no one knows who made it or where/how it's hosted and it's not even that old yet 
In case you're thinking this must be some small local shop, it's actually a pretty large multinational 
|
|
|
|
|
Sander Rossel wrote: We won't be hacked and even if we were it wouldn't be a problem since the data is not very important...
So why bother having a username and password in the first place? 
"These people looked deep within my soul and assigned me a number based on the order in which I joined."
- Homer
|
|
|
|
|
Because the standard(-ish) requires it?
There are actually two usernames and passwords, one to get access to the service (basic authentication) and then one to get specific data (a token in each message).
Now get this, the basic authentication is the same for each user because some third-party app hard-coded it!!!
Really, this project is the gift that keeps on giving 
|
|
|
|
|
Not surprised a bit!
"When the going gets weird, the weird turn pro." - Hunter S. Thompson
|
|
|
|
|
Sander Rossel wrote: Now, I just had a discussion about storing those passwords.
"It would be nice if we could send the users their password in case they forget."
Out of the question because I hash passwords before I store them.
"But we're not storing user data and it would be more practical if we knew these passwords... We won't be hacked and even if we were it wouldn't be a problem since the data is not very important..."
Why the [mastadon] am I even having this discussion in 2021 with a fellow IT professional!?
Still better than "It would be nice if we could see their passwords to login as them when they're reporting a problem to try reproduction to see if it's a real problem or user error". Not a multinational sized customer but still... 😭😭
Did you ever see history portrayed as an old man with a wise brow and pulseless heart, weighing all things in the balance of reason?
Is not rather the genius of history like an eternal, imploring maiden, full of fire, with a burning heart and flaming soul, humanly warm and humanly beautiful?
--Zachris Topelius
|
|
|
|
|
I worked at a company that had an impersonate button in one of their apps.
It had to be a secret as it violated about every privacy law imaginable
Not as bad as your case as we couldn't see their password, but besides that it's pretty much the same.
|
|
|
|
|
For what they want to do, and considering that the people using it would be the same people who would be running/using reports dumping everything the users entered into the system (so they can fold, spindle, and mutilate it into an conclusion of "our system works, give us another grant to run it next year"), if they would give us a chance to breathe on the flood of new features an impersonate - for everything but saving as the other user - feature is what I wish we had time to give them.
As far as privacy rules go when we pushed on needing to do various GDRP related things if they wanted to expand into the EU "our research ethics commission is already so strict on what we're allowed to do that there's no way we'd need to change anything" (no one at my company has ever seen these rules ), and separately "we asked our universities legal dept and they said 'GDRP means we can do whatever we want'"   . But all talk of doing stuff overseas stopped around that point in time. 🤔
Did you ever see history portrayed as an old man with a wise brow and pulseless heart, weighing all things in the balance of reason?
Is not rather the genius of history like an eternal, imploring maiden, full of fire, with a burning heart and flaming soul, humanly warm and humanly beautiful?
--Zachris Topelius
|
|
|
|
|
I used to build in an impersonate option, completely bypassed the logon function and set the dev up as the user. Mind you they were desktop applications on a local network.
Never underestimate the power of human stupidity -
RAH
I'm old. I know stuff - JSOP
|
|
|
|
|
This brings up an interesting debate I have had with some management members of a corp I do software development for.
If the software belongs to the corp, and the person using it is an employee of said corp, and the software is only used for business related data... is it really an invasion of privacy to
1) know their password? or
2) impersonate their user for debugging purposes?
I honestly don't have an opinion on this. I have seen both sides of the argument... a case where the problem ONLY came up for that one single user and couldn't be duplicated in any other way... and a case where somebody maliciously used their ability to impersonate a user to get said user into trouble.
I guess as with many things in life, good judgement on need and urgency are better than absolute policy.
modified 14-Jun-21 5:52am.
|
|
|
|
|
HuntrCkr wrote: is it really an invasion of privacy to
1) know their password? or
Yes always, there's a very good chance that user uses this password everywhere.
If you know their password you could probably login to their Facebook, Google, Instagram and bank accounts.
If someone hacks your database and the passwords are not sufficiently secured (and personally I think anything less than a strong hash is not sufficient), those hackers can now login to those accounts too.
And if those hackers post everything online, everyone can login to those accounts.
It doesn't matter what data a password secures, the password in itself is private and VERY SENSITIVE data.
In a perfect world it would be some "unhackable" randomly generated string of at least 24 characters, but we're living in a world where 123456 is still the most used password.
HuntrCkr wrote: 2) impersonate their user for debugging purposes?
Depends what the system does.
In our case, the application had data on where users went, when they went and how they went.
It kept train tickets, parking tickets, locations, times, everything.
Now that's pretty sensitive information and the entire team had access to it because of some impersonation feature.
But let's assume it's all business data and not linked to any one person... Right now.
What if that data is added in the future?HuntrCkr wrote: a case where the problem ONLY came up for that one single user and couldn't be duplicated in any other way
Been there, done that.
Schedule a call with the user, add boatloads of logging, get only that part what you need from the production database (preferably from a "privileged" individual who has rights to that database).
I've never actually needed impersonation to solve a problem.HuntrCkr wrote: a case where somebody maliciously used their ability to impersonate a user to get said user into trouble
And that invalidates all reasons why you should have an impersonation button or make passwords recoverable 
|
|
|
|
|
Sander Rossel wrote: Yes always, there's a very good chance that user uses this password everywhere.
If you know their password you could probably login to their Facebook, Google, Instagram and bank accounts.
If someone hacks your database and the passwords are not sufficiently secured (and personally I think anything less than a strong hash is not sufficient), those hackers can now login to those accounts too.
And if those hackers post everything online, everyone can login to those accounts.
It doesn't matter what data a password secures, the password in itself is private and VERY SENSITIVE data.
In a perfect world it would be some "unhackable" randomly generated string of at least 24 characters, but we're living in a world where 123456 is still the most used password.
It's actually far worse than that... the users don't even get to choose their own passwords. They are assigned by IT (Not a policy I approve of or had any hand in), so the chances of that password being reused elsewhere is very slim, unless this might be the first password they ever use and they then decide to use it everywhere. But honestly, what's the chances.
Edit: Forgot to add that surprisingly enough, these password are quite strong passwords with no pattern on how they are created... not 24 char random strings, but at least decent enough to keep most at bay I would say. For example, Ap@rtmentDataC0nnect10n was one memorable one I saw (relax...no longer in use   )
Sander Rossel wrote: Schedule a call with the user, add boatloads of logging, get only that part what you need from the production database (preferably from a "privileged" individual who has rights to that database).
Did that before too when working with a client where impersonation was not possible. Sometimes the effort and time involved in getting multiple cycles of changes deployed to a production environment just to debug a problem is not realistic or in the client's best interests.
BTW, when I say impersonation, I am by no means advocating something like a button allowing ordinary or even support staff to impersonate someone. I mean impersonation by somebody that in any case has full access to the entire production database(s) and code base. Typically the most senior 2 or 3 devs/architects/whatever on the team would be my exception here, and as you say, only when the system does not store sensitive personal information.
Sander Rossel wrote: And that invalidates all reasons why you should have an impersonation button or make passwords recoverable
Agreed... Passwords should never be stored readable, and impersonating someone should never be as simple as a button. I'm just saying that impersonation as a method for solving a serious problem should be a last resort, but not an absolute hard limit.
modified 14-Jun-21 6:30am.
|
|
|
|
|
By default I'd make impersonate read-only. If impersonate and save/update needs to be done, I'd make some explicit logging of every save made during impersonation mode.
Did you ever see history portrayed as an old man with a wise brow and pulseless heart, weighing all things in the balance of reason?
Is not rather the genius of history like an eternal, imploring maiden, full of fire, with a burning heart and flaming soul, humanly warm and humanly beautiful?
--Zachris Topelius
|
|
|
|
|
As a button I think it's a bad idea, but I do have in my code (an include file) a mechanism for me to impersonate any user. I don't see the same things as individual users - and the privilege scheme often means only a few users are affected by a problem. It's the way I avoid telling a user "it's fixed" because I did what I needed to do only to find out it wasn't fixed in their view.
Note that this only affects our internal (non-public-facing) website/applications. Not their email or anything like that. With myself, and so many others, working remote and the company personnel in more than one location, this is really pretty essential a feature. Available only to those with admin access to server files and only if they know where to look.
Considering I could modify data in the tables, anyway, there's no particular reason for anyone to get upset (if they knew).
| Ravings en masse^ |
|---|
| "The difference between genius and stupidity is that genius has its limits." - Albert Einstein | | "If you are searching for perfection in others, then you seek disappointment. If you seek perfection in yourself, then you will find failure." - Balboos HaGadol Mar 2010 |
|
|
|
|
|
That reads like a story from TheDailyWTF
|
|
|
|
|
Did I post on the wrong forum again?
|
|
|
|
|
It certainly is a good story to read while relaxing in a lounge chair to lounge music B)
|
|
|
|
|
I'm not gonna hint at the sector, but I know of a vendor that sells pretty darn critical software packages, and they get secured by a physical hardware key.
Under the hood, it uses decentralized DB shards that connect to a central authentication DB, and only when the entire network is properly meshed, does the hardware key authenticate.
And if you don't have enough money for a key, or a certified authentication server, you can just access the DB manually and turn off the security.
Yeah. Great design guys. 10/10
|
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
