Hoo boy, let's count some of the ways:
- Excessive RAM/CPU requirements
- Abysmal search performance, ineptitude at finding or retrieving messages older than a week or so.
- Threads in Teams Channels are a backwards abomination; there is no way to start a thread in the middle of an existing thread. Their model exaggerates poor conversation and causes duplicate and orphaned threads.
- Chats are a second-class citizen and it is painfully slow to switch between conversations happening in Teams Channels and Chats.
- The "type-ahead" auto-formatter is broken, often not changing text when you want or changing text when you don't want. This should always "format-on-send" and offer an option to disable the idiotic auto-inline-formatter.
- Notifications... Teams is the only platform that barely offers "eventual consistency" sometimes. Messages and notifications are often out of sync across devices and worse, entire parts of conversations are sometimes just missing in the middle of a thread.

Preach!

Like many opinionated large companies that have specific requirements which are at odds with the full spectrum of a vendor's service, Insights is not an option for us.

I eventually figured out what I needed but that was far more trouble than it should have been.

You reached your Ballmer Peak.

Congratulations!

https://imgs.xkcd.com/comics/...

@Stuxnet "same" is only true if all parties use the web version.

As soon as one person emails a copy, the entire collaborative environment falls apart.

@Forside I don't so much blame the OS for the problem as I blame it for not helping with a solution. We're stuck at an earlier build of Windows 10 because of McAfee... Yay corporate PCs.

Update:
➖ After some considerable time tinkering with the monitor menus themselves, I have mostly solved the color issues.
✔️ DPI scaling fixed by NOT DOING THAT... Why Microsoft defaults that setting to "broken" I don't know.
✔️ Make all screens use the same resolution and reboot a lot after setup... Seems to be stablizing some.
❌ RAM turns out is a corporate issue... McAfee we're stuck with is sucking a considerable amount down. More tinkering required.

At the end of the day, I have a tool and I have to make it work. I don't have to like it.

@DomNomz If it's a hardware issue, I would expect similar problems in a different OS on the same hardware. Alas, my Debian-based bootable drive clearly demonstrate that Windows is utterly incompetent at text/DPI scaling and color profile matching.

I think the RAM will be fine but Windows is not as efficient at management as alternative operating systems.

@otavio I'm not finished setting everything up yet and I'm positive it is going to get worse.

Don't get me wrong, I don't hate Windows... I'm just not looking forward to building my development environment in Windows again.

@busuu - You only have to worry about finding and watching "The Matrix". There were never any sequels. 😏
https://xkcd.com/566/

Gah, there's even a closing php tag. 😬

#BurnIt #KillWithFire

@byte-me, now you just need to:
- git commit -Am "Feature built, tested and passed. First time."
- git checkout master
- git checkout -b real-feature-brach
- git merge --squash original-feature-branch

Then history will show you did it all in one commit. 😏 #ImBatman

Real programmers use MS Paint...

...pixel by pixel, machine language is born.

It's a shame really, because the box has literally been rock solid since the day it was built. I was annoyed at the time that the console never worked but I could remote in via SSH on the first boot.

One day it didn't boot up and I thought it had suffered a hardware failure. I migrated everything to a new box and moved on. For kicks, I dragged the old one back out and gave it a fresh go with newer versions, fresh kernel and everything. Amazingly, it worked a treat but still no console...

(queue rant, subsequent fix)

With a completely working install complete with console, I tried booting up the original install from the old drive, turns out it didn't die at all. One of the dead external USB devices in fstab was hanging the boot waiting for me to "Press C to continue". 😒 But, without a console it was hard to tell.

Apparently the ScaleIO storage device had an "incident" and sent most of production container filesystems into read-only mode.

The storage monitor still believes everything is okay...

There was a joke amongst the team to build a recipe for Alexa for eBay so we could say:

"Hey Alexa, sell yourself on eBay and order a Google Home."

HTC never said it was an accident. They said it was an "error".

The error was not in the implementation. The error was in the judgment to implement it.

@GinjaNinja Poor design choices and difficulties with getting RavenDB to handle partial document upserts reliably.

Every day many of the documents had some very trivial change in a nested node.
RavenDB seemed to struggle (at the time we used it) with upserts, and would often return the originally written document.
MongoDB worked better but the volume of changes caused significant drift between nodes. Eventually, nodes would go offline cause load spikes which exacerbated the problem unless things could settle down.

After all things tested, the best "solution" presented was to treat RavenDB and later MongoDB as caches and just dump/reload them daily to avoid inconsistent data and instability.

@configurator I appreciate the offer but that project has long since moved on away from both MongoDB and RavenDB.

@GinjaNinja Yes, load...

MongoDB simply couldn't handle what we threw at it and when things get busy in MongoDB, it starts guessing...

@configurator We might have been trying to stuff ~2.4 million documents, each one was several hundred KBs of json... 😇

Everything was updated daily as a dump/reload.

@GinjaNinja we did... It solved some problems and created hundreds more.

RavenDB had one bullet point that MongoDB doesn't have: It returns the data you ask for every time... (assuming the service was up and working)

MongoDB likes to guess sometimes and give you stale data.

Elasticsearch is where it is at. Bring resources though...

I realize I can get sed for Windows, and git and that it is "possible" to develop in that environment.

It is just orders of magnitude easier to use an OS with a real terminal and proper memory management than to waste crazy amounts of time getting things to work in a Fisher Price OS that wasn't meant for that kind of work.

Lesson was learned after years of doing it the difficult way.

C++ makes sense...

C# was somebody looking at C++, crossing their eyes and tilting their head.

@gitpush Well that escalated quickly...

I mean, that got out of hand fast.

I took these steps:
- Installed all updates and then ran Disk Clean to clear out temp files, logs and update caches
- Disabled system restore and deleted all restore points
- Disabled page file on all drives
- Disabled hibernate
- Deleted all unused applications and cleared browser caches.

It is a 180GB SSD, 155GB dedicated to Windows 10.
I cleared enough space to have 92GB free without affecting my development environment or installed applications.
I tried to carve out 48GB of the 92GB free and Disk Manager even reported I could carve out 75GB.

Nothing worked... It kept saying there wasn't enough space even when I dropped to a smaller 25GB shrink.

@apex It's an SSD, I did trim it though.

@lo98be I use "data center" liberally when I describe that particular data center. It had racks, that is about all I can say that made it qualify.

Electrically, we couldn't turn everything on at the same time or PDU circuits would trip and take random servers offline in the middle of heavy I/O. Drives usually didn't come back from hard power cycles like that.

Later in that job tenure, my coworker and I took it upon ourselves to completely refactor the wiring and layout and solved many of the electrical issues in the racks.

@umnikos True in some cases.

@tisaconundrum Vibration and electrical issues were the biggest enemies of drives in our data center. Heat and mechanical hardship didn't seem to affect much.

The torture those test drives saw regularly​ would have caused very frequent premature death if "heavy load" adversely ​affected the life span.

@lo98be Given that this task was given the same day as the visit, the fastest​ way to cause excessive but real disk activity was striping arrays and running IOmeter scripts. The blink patterns are mesmerizing.

If I had more time, I would have considered building an LED matrix connected to the backplanes of each server and driven over the network. We were building our own iSCSI storage server software at the time and slipping a "test the access lights" endpoint would have been possible.