Then you could have bought 4-6" Cat 5e/6a pre-made patch cables to connect in the majority of your patch panel ports. The only cables that would traverse through the cable mgmt panel would be longer cables to the servers in your rack.
I have a similar Cisco switch as your 24 port. I am not fan of how they arranged all the ports at the right side of the enclosure. Why not make the 24p one row along the top (or bottom), like the 48p with the 2nd row removed? It would be a lot easier for cable mgmt.
The reason its arranged like that is because it started as 1 switch and 1 patch panel, and slowly evolved, so its not ideal, but I am fairly happy with the outcome
If I could re-rack it all, I might make some changes. But that means turning everything off, and I'm not sure when, if ever, I want to do that
I had the patch panels above a collection of switches in both the MDF and IDF closet. About a year in I rearranged it to the more common interleaved switches and panels, mostly just to make it look a bit cleaner.
I moved from 10g to 40g for switch interconnects in a few places, as well as used the fiber I installed to do 10g to most of the desktops, etc. Fun stuff for sure!
I noticed this as well. The patch panels seem only to bring some wire to the front of the rack, only to immediately send the patched wire toward the back of the rack again.
You mean besides the last three years of reduced on-site staffing, and employee travel to support maintenance and modernization? No.
$5 says this is the XKCD for this. Corrupted DB file was the culprit, as announced by the FAA. It's a system that relies on user inputs, often manual, and it's all being put into a database. My bet is a user decided to put in a bunch of "fun characters" to make their input easier to read. You can't account for and sanitize all levels of stupidity on user inputs.
> You can't account for and sanitize all levels of stupidity on user inputs.
That is false and a defeatist attitude.
Sanitization is not the right solution anyway. If you are working with any form of a database and don't know from the top of your head how to avoid query injection attacks then you should look up in the manual of your database. The solution is most often called "parameterized query" or something similar.
Agreed. Use JSON, proprietary binary formats are terrible, and 99% of the time the bandwidth savings aren't worth it. For messaging, I really like NATS (incubating in the K8S landscape - probably graduating soon). My fav thing is the wildcard usage in NATS.
Bandwidth isn't the primary concern here. CPU time spent parsing/unparsing is. Depending on how your application is structured, it can actually dominate time spent in application logic. Whatever the case, it's simply waste heat being added to the universe. Use a little-endian, 64-bit-aligned binary format, and parsing overhead simply goes away.
Great point. I'm not one to over optimize, but seems like parsing messages for internet sized apps is worth spending a little effort to save energy and environment.
This could have some implications in the computational expense of trilateration for GNSS applications. "Optimal trilateration is an eigenvalue problem" <title of another paper>.
