|
Yeah. I suppose I could, but I don't like the idea of DCOM for IPC for some reason
Real programmers use butterflies
|
|
|
|
|
honey the codewitch wrote: I don't want to use TCP/IP for this, which seems my only other option, but it's not even reliable because I can't guarantee a fixed TCP port to use for the client/server. How do I know it's not in use? If i pick one at random, how can i negotiate it with the client? It's again, ridiculous.
Not to forget that even when you could do all that, then come a new "I know all better" moron in the IT department, they change the firewalls and puff... you are fvcked up.
M.D.V. 
If something has a solution... Why do we have to worry about?. If it has no solution... For what reason do we have to worry about?
Help me to understand what I'm saying, and I'll explain it better to you
Rating helpful answers is nice, but saying thanks can be even nicer.
|
|
|
|
|
That's what production documentation, change control, etc etc are supposed to prevent (sorry, I had the benefit of working for a 'large shop')
|
|
|
|
|
Garth J Lancaster wrote: That's what production documentation, change control, etc etc are supposed to prevent when done properly, being updated regulary and informing all relevant parts soon enough to prepare for it
FTFY
Garth J Lancaster wrote: (sorry, I had the benefit of working for a 'large shop')
And I have worked for a large shop too, where the IT just changed the IP of the production and statistic servers (3 pieces) without telling any of the production plants abroad. The action ended in 7 weeks without mirroring of the production buffered data (at least individual requests continued working), no mirror of the software libraries and no backup of our statistic DB. 7 weeks where 2 weeks where looking for the problem, we had all our requests done by DNS-Name but the firewalls were "reconfigured" to use the new IP. 1 Week more to get all needed signatures for the respective change_requests (in this part of the process of course they were active again), and 4 weeks to wait until the damned firewall entries were corrected and activated.
To answer your comment again I can only say:
Theory and Practice are in theory the same, but in practice...
M.D.V.
If something has a solution... Why do we have to worry about?. If it has no solution... For what reason do we have to worry about?
Help me to understand what I'm saying, and I'll explain it better to you
Rating helpful answers is nice, but saying thanks can be even nicer.
|
|
|
|
|
Quote: where the IT just changed the IP of the production and statistic servers
Ha ha, said the clown!
|
|
|
|
|
What is so funny?
M.D.V.
If something has a solution... Why do we have to worry about?. If it has no solution... For what reason do we have to worry about?
Help me to understand what I'm saying, and I'll explain it better to you
Rating helpful answers is nice, but saying thanks can be even nicer.
|
|
|
|
|
I wrote a tray app that communicates with a Windows service using named pipes, and it worked fine. Are you talking about .Net Core maybe?
|
|
|
|
|
I don't know "honey the codewitch's" situation, but your experience matches my recollection
|
|
|
|
|
Nah, it's DNF 4.72 
Real programmers use butterflies
|
|
|
|
|
In my several decades of working in the Win32 environment and now Win64, I have never, ever had an issue with credentials and inter-process communication. Not a single time and I have worked with pipes, events, mutexes, and shared memory extensively.
What I mean by this is, in and of themselves, none of those IPC mechanisms require anything involving credentials. Any issues you may have with them are arising from a different level such as dealing with a service OR they are being imposed by something in .nyet.
"They have a consciousness, they have a life, they have a soul! Damn you! Let the rabbits wear glasses! Save our brothers! Can I get an amen?"
|
|
|
|
|
It might be a .NET issue, but it looked like I was getting a win32 error result since it was 5: access denied
Real programmers use butterflies
|
|
|
|
|
"I would be looking for better tekkies, too. Yours are broken." -- Paul Pedant
Context: The inability to create or consume CSV files. 
|
|
|
|
|
|
"Anti-escape baffle", yeah, so when that 7,000 volts doesn't do the job. 
|
|
|
|
|
They finally built a better one.
Yuya Tuya want your mouse? I've got one.
Yuya Tuya want your mouse? I'm sayin'
modified 4-Aug-20 22:32pm.
|
|
|
|
|
I need a bowl and a half of walnut to catch a mouse - and it does not kill it...
"The only place where Success comes before Work is in the dictionary." Vidal Sassoon, 1928 - 2012
|
|
|
|
|
Don't eat the walnuts yourself, put them in the trap!
|
|
|
|
|
Do they make them burglar-sized, too? 
Freedom is the freedom to say that two plus two make four. If that is granted, all else follows.
-- 6079 Smith W.
|
|
|
|
|
Hillarious.
I find it odd no-one else has made mention of something.
Why would you fire the pulse 5 times if the device INSTANTLY KILLS em?
Also of note,
The device lure mice and sustaining a high-voltage discharge for 2 minutes to ensure the mouse is dead.
There's a very slim chance the marketing might not be quite accurate. Very slim. 
|
|
|
|
|
Someone's come to me with what I thought was a good question.
He's got some 320kbps MP3s that were upconverted from files that originally were anywhere between 128kbps and 256kbps.  Don't ask me why this was done. Someone must've thought introducing extra bits would magically improve the lower-res recording. He no longer has the original versions of the files.
The question he asked me, and I had no answer for, is this: Is there software that can analyze the audio in a given file, and determine that it's something that does NOT require 320kbps and there would be "no loss" converting it back to 256 or 128kps, or whatever it was originally encoded from? His argument is that his library is now taking roughly 2x+ the amount of disk space it used to, with no benefit to be gained. Of course, he's already got some MP3s that were originally ripped at 320kbps, so he doesn't want to bulk-convert everything back to 256kbps or lower - only those that were at the lower resolution to begin with.
Obviously this isn't "audio fingerprinting" like MusicBrainz Picard can do. And I can't come up with the right keywords for googling.
|
|
|
|
|
dandy72 wrote: he doesn't want to bulk-convert everything back to 256kbps or lower - only those that were at the lower resolution to begin with.
OK but how about this: re-encode everything anyway, then compare the loss between the 320kbps version and the new version. If there's a lot of loss, keep the big version. Audio comparison tools exist, so this wouldn't involve anything fancy.
|
|
|
|
|
That's an interesting idea, and makes sense.
There's that second step however, comparing whether there was a loss...
|
|
|
|
|
I always encode everything to 128kbps.
This comes from a time when my HD was only 500 GB (ancient times) and it was full.
It's still very relevant for my (old) 160 GB MP3 player today.
This may sound like I'm really old skool, or hipster maybe, but my music tastes aren't always on streaming platforms such as Spotify or Bandcamp.
I don't really hear the 128 vs. 320 difference though.
Maybe with headphones, but not from my laptop speaker or earplugs on my bike.
Besides, the brain is great at filling in missing parts.
The soundtracks back in the (S)NES days sounded like actual orchestras to me 
Anyway, "upcoding" isn't possible as far as I know.
Tried it sometime, but it gets glitchy.
I can't imagine "upcoding" and then decoding back is good for your quality.
I'm afraid your friend is out of luck 
But couldn't he just try to decode the 256 ones back to 128 and leave the 320 alone?
Or decode the 320 to 256 or 192 to save some space while still having decent quality?
He should also check VBR (Variable Bit Rate), which is kind of what you want, but not completely.
It will work for the original 320, but probably won't make the "upcoded" stuff better.
With VBR you get like 128 (or even less) at the quiet parts and maybe 320 at loud parts with lots of instruments, and everything in between, basically.
Your bit rate with VBR can be something like 213kbps because it's an average of the various parts.
It's the best of both worlds although, as said, I don't use it myself.
|
|
|
|
|
Sander Rossel wrote: I don't really hear the 128 vs. 320 difference though.
Maybe with headphones, but not from my laptop speaker or earplugs on my bike.
Besides, the brain is great at filling in missing parts.
The soundtracks back in the (S)NES days sounded like actual orchestras to me
For some reason that just reminds me of this scene: Everybody Loves Raymond - Vinyl vs CDs - YouTube[^]
|
|
|
|
|
Fun fact, in 2019, vinyl revenue surpassed that of CDs for the first time since 1986.
CDs still sold more in absolute numbers, but vinyl is more expensive
I say, bring back the VHS! 
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
