|
very good to know...
diligent hands rule....
|
|
|
|
|
In my last job, the employer insisted on running some malware detector (I am not able to recall its name right now) that all the time triggered on the system I was developing. So I declared a dummy string variable (and had to make a dummy modification to it to ensure that it wasn't optimized away) to disturb that bit pattern in my code that the virus scanner mistook for a virus signature.
Every few code updates, other changes made the offending bit pattern again reappear in my code. So I had to delete from or insert into that dummy string a few characters to disturb the 'virus signature' bit pattern again. (After a while, I ended up with having two string, commenting out one, uncommenting the other. It never happened that the virus scanner gave me trouble with either alternatives and no other code changes.)
I complained so loudly about this that I was told that the virus scanner could be configured to bypass any given directory, and they could set it up so that the directory where I generated the system during development not scanned. Production versions were generated in another directory, which they refused to except from virus scanning. So several times, the first attempt at production build caused a virus warning, and I had to rebuild after commenting and uncommenting the alternate dummy string. We did not make releases every month, so this was considered acceptable, as long as the daily development work didn't require daily rubbing the virus scanner behind its ear to keep it from biting.
|
|
|
|
|
thanks for your story
diligent hands rule....
|
|
|
|
|
Immediately get rid of any so-called anti-malware that is so amateurish that it takes this drastic an action as a result of something it failed so badly at.
[Edit]
Oh. Kaspersky strikes again, I see.
A few decades ago my employer had us use Kaspersky, and I remember having to tell it to skip my dev folder for reasons similar to yours.
Nice to see that decades later they're still dealing with this. How long can they repeat this before they realize their approach to scanning should be abandoned?
|
|
|
|
|
In times like this I would not use an IS / AV that is related to Russia
|
|
|
|
|
Don't forget that Kaspersky is a Russian company. The problem here is that the Russian Government can force Kaspersky to turn over anything they collect, and likely does.
|
|
|
|
|
|
|
Just remember, it's only in math classes where you can buy 64 watermelons and no one wonders why.
|
|
|
|
|
So Doordash has no security is the lesson I received from this.
|
|
|
|
|
I never liked it when my wife let the kids play games on her phone, when they were young. Thankfully, no one ordered a bunch of Micky D burgers. Yikes!!!
Years ago, my SIL's son downloaded and played a video game on her phone, racking up over $800 on in-game purchases. I was laughing for weeks at that one.
|
|
|
|
|
|
|
So I have an app that's designed to run on a piece of hardware intended for musicians, who are not tech savvy.
They also use equipment that can produce corrupt files, although that's not exceedingly common.
My software boots and reads an inserted SD card. Currently during this process it loads each MIDI file and scans through its entire contents to determine if its valid before adding it to the list of available files. That way, corrupted files do not appear in the list. It also means I can display more information about each file.
Once loaded, you scroll through the file list with a small rotary encoder (a knob basically for those of you that don't know what one is)
The issue is this: The title screen can take some time to load. It's not terrible with a dozen files, but more than that and it starts to be like "hurry up!"
Couple this with the difficulty of scrolling through a ton of files with just a knob.
I'm thinking this is okay. Basically, don't put 100 files on an SD card. What do you think?
To err is human. Fortune favors the monsters.
|
|
|
|
|
Do not wait for the scan to finish all the files. When one scanned add it to the list and to the screen (scroll in the new ones)
It probably will take more time to finish the scan but the end user will not wait on empty screen
As for the knob - IMHO it is much better than push buttons...
“Real stupidity beats artificial intelligence every time.”
― Terry Pratchett, Hogfather
|
|
|
|
|
That's an interesting idea. I'll consider it. My main concern with it is if the list isn't done loading it will be hard to tell when it's done and you've reached the end or if there's more to go. I guess I can squeeze an indicator on there but the screen is very small.
Also it displays only one file at a time due to the size of the screen, and displaying information about each file, so there's no "list" to scroll. Plus scrolling is out of the question for performance reasons the way these little gadgets work.
To err is human. Fortune favors the monsters.
|
|
|
|
|
The indicator is very important for perceived performance - if you can quickly count the files, I assume you can even show a percentage or similar?
Maybe if you detect more than a reasonable amount of files, you can start by displaying a text saying "This will take a long time, do you want to continue" (well, something shorter probably). If you are really fancy, you can start the loading in the background while displaying the message so the time until they react (if they react) is not wasted. If they just insert the SD card and throw it on the table without paying attention - at least it will then have finished loading when they come back from lunch instead of just sitting waiting for them to press the button.
|
|
|
|
|
Yeah I probably could put an indicator. Do you want to continue is a little tricky, as taking input is always a bit involved when you're dealing with limited user input devices.
To err is human. Fortune favors the monsters.
|
|
|
|
|
"Click to continue". It's not like saying "no" really means anything they can't express by taking out the SD card. The important thing is that they are told what they can do to avoid it being so slow. Do not expect users to think twice about filling an SD card with old data if you do not tell them the problems it will give.
|
|
|
|
|
lmoelleb wrote: The indicator is very important for perceived performance - if you can quickly count the files, I assume you can even show a percentage or similar? This is roughly my thought -- when loading will take a long perceived time, I count files, records, or whatever, and post a message that says "loading file xx of yy", and force the screen to update periodically. If there's a thousand files, I won't update display for every file (that will slow down the process), but every 10 to 20 files. If you're expecting a max of 100 files, updating the display every 10 should give the user good feedback while not bogging down the process.
|
|
|
|
|
I am thinking of: [x] fileName
where [x] is really an movement indicator.
Either a number (n), that you fill in as you process each file.
Or a Linux style set of ".-/-*^v" that you MOD your way across, to give the appears of progress per file.
the upside to this is that a long file doesn't make the user think it is done at file [13] xyz
and they can start spinning the nob to select another...
Also, I am a FAN of red LED for busy, and GREEN LED for available. So if you have a power LED, red during boot up.
GREEN when good. YELLOW when you have an issue (Either a specific corrupted MIDI file, or something).
But here I go adding hardware...
And not sure if Nob only rotates, or if it contains a "switch" (pressing) as well. (Turn to select, Press to play type thing).
But your project sounds like FUN!
And you do a GREAT job on asking questions... I can REALLY tell you care about how it turns out!
|
|
|
|
|
Maybe add a button and use a tree structure for the files, where you can drill down into; (and I don't know a damn thing about it...but)
drum beats
chill
jazzy
moody
etc.
The most expensive tool is a cheap tool. Gareth Branwyn
JaxCoder.com
|
|
|
|
|
That's not possible. MIDI files aren't classified that way, and to impose such a structure would require the user to do so in some way, such as using folders. I'm not scanning subfolders due to the complexity, primarily of navigating folders using nothing but a button and rotary encoder. This isn't for tech savvy folks.
To err is human. Fortune favors the monsters.
|
|
|
|
|
Gotcha, only other way would be paging.
The most expensive tool is a cheap tool. Gareth Branwyn
JaxCoder.com
|
|
|
|
|
My current solution is to simply make the user wait to load it all. It doesn't handle a lot of files really well anyway because it has to load them all into memory first. The reason is the rotary encoder can be turned much faster than the SD card reader can read file info. So I have to prefetch everything. I have about 320kB free at that point, so it's not terrible, but it can't be excessive.
So my current idea is - MIDI files in the root directory only, and then just don't put a ton of them there.
It's actually better to use multiple SD cards. If you only have one file on it it will load it automatically so you can punch sets in an out.
To err is human. Fortune favors the monsters.
|
|
|
|