|
8Mbps down, 0.75 up!
DSL sucks ass
|
|
|
|
|
Chris Losinger wrote: DSL sucks ass
It does. But that's what you get for living on the top of a mountain in the middle of nowhere. 
|
|
|
|
|
Meh. The more bandwidth I have, the more bandwidth I waste. My home connection can sustain a (roughly) 5.3mbps download, and I honestly feel very little incentive to get anything much faster.
[Edit]
And it's not one of those "you don't know what you're missing unless you experience it" type of situations. My work machine (which I reach over VPN) can sustain hundreds of megabytes (not megabits) per second, and while I find that all very impressive, I don't know what use I'd put that to if I had that here at home.
|
|
|
|
|
where more bandwidth comes in handy is when things get busy.
if my wife is on a Zoom call, my remote desktop connection will sometimes simply time out, with our glorious 8Mbps (max, and highly unstable) DSL connection.
if we had even 20Mbps, that wouldn't happen.
modified 11-Jun-21 16:11pm.
|
|
|
|
|
I was going to point out that I'm the only one in the house using my connection, but even then, I did complain a few days ago that every once in a while I have a system that randomly decides to start downloading something; I can't identify which system, and what it's downloading...and that can be a problem.
Getting a faster connection for this case however sounds like a Band-Aid solution, as the root cause would still exist.
|
|
|
|
|
I agree. I now have 120Mbps down and upload at 42Mbps with ping at 14ms. Downloading and running a project from github takes 1 minute.
A Xcode update of 14gb was a pain before and is now ready while I have a coffee. Of course, now I have no excuse for not working any more..
jhaga
|
|
|
|
|
I have two STM32 boards collecting dust for two main reasons:
1. There are too many toolchains/frameworks for me to decide which one to rely on primarily.
2. The build times for the ones I've tried from #1 are atrocious. This has been the biggest show stopper for me because even with incremental compiling and linking you still have to do full builds periodically and with these boards it's painful. With the ESP32 you can remove "components" from the framework so you don't suffer build times for things you don't need. With these STM32 frameworks it seems like you have to build things you'll never even use.
Given these two issues, with #2 being a huge deal to me, and given I want to stick with C++, what framework do I choose?
Anyone have any ideas?
Real programmers use butterflies
|
|
|
|
|
Yes, you should use V, according to this morning's newsletter
The V Programming Language[^]
From the website:
"As fast as C (V's main backend compiles to human readable C)
C interop without any costs
Fast compilation
V compiles ≈110k (Clang backend) and ≈1 million (x64 and tcc backends) lines of code per second per CPU core.
(Intel i5-7500, SM0256L SSD, no optimization)
V is written in V and compiles itself in under a second."
I have no idea what any of this means or if this is in any way applicable to you or your use case(s), but for some reason I thought about you when I read about V this morning
|
|
|
|
|
|
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.
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
