Earlier quoted context omitted.
but are they? on average? how do you measure this? it's pretty easy to talk to a solo-dev or gardener
It's easy to talk to Microsoft employees too.
Not in my experience.
Microsoft Dependency Has Risks
201–210 of 238 posts
Re: Microsoft Dependency Has Risks
#202Earlier quoted context omitted.
> How do you separate the good from the bad? Developer tools and enterprise stuff good (mostly). Consumer products bad.
MS office is 30 years ahead of open office.
did you get those the wrong way round?
office 95 (without the ribbon) is more usable than office 365 (with the ribbon)
Re: Microsoft Dependency Has Risks
#203Earlier quoted context omitted.
Genuine question that sounds like trolling: can you get an insurance against critical service provider going poof for political reasons?
Here you are https://www.insurancebusinessmag.com/us/guides/what-is-polit...
if there was a major "incident" I would have thought the odds of the insurer going bust are 100%
Re: Microsoft Dependency Has Risks
#204Earlier quoted context omitted.
MS office is 30 years ahead of open office.
did you get those the wrong way round? office 95 (without the ribbon) is more usable than office 365 (with the ribbon)
no. the ribbon is fully customizable with greater functionality than traditional menu.
Re: Microsoft Dependency Has Risks
#205Earlier quoted context omitted.
did you get those the wrong way round? office 95 (without the ribbon) is more usable than office 365 (with the ribbon)
no. the ribbon is fully customizable with greater functionality than traditional menu.
> the ribbon is fully customizable
so was the one in office 95
> with greater functionality than traditional menu
you click a button and something happens?
except now the button isn't in a consistent place
a usability regression
Re: Microsoft Dependency Has Risks
#206Earlier quoted context omitted.
Are you kidding? By the time you get through the first half of the requirements document of most windows customers, OSX and Linux alternatives have already been thoroughly ruled out.
When it starts with the phrase “FIP-S compliant”, hardly anyone is wants to do that on Linux.
It seems that both RHEL [1] and Ubuntu Pro have docs on FIPS, so it looks like the distribution vendors have thought about this problem, at least for paying customers. Might you be able to sketch out what the problem with FIPS compliance on Linux is?
[1] https://access.redhat.com/compliance/fips [2] https://ubuntu.com/security/fips
Re: Microsoft Dependency Has Risks
#207Earlier quoted context omitted.
no. the ribbon is fully customizable with greater functionality than traditional menu.
> the ribbon is fully customizable so was the one in office 95 > with greater functionality than traditional menu you click a button and something happens? except now the button isn't in a consistent place a usability regression
Wrong about "inconsistent", the ribbon follows predictable patterns. Home tab always has basic formatting, Insert always has objects/media, etc. What changed is intelligent positioning based on context.
Office 95's menus were consistent in the worst way - consistently buried everything under nested submenus. Finding mail merge meant File→Tools→Mail Merge→Options→Setup. Now it's Mailings tab, right there.
Re: Microsoft Dependency Has Risks
#208Earlier quoted context omitted.
Unless you found yourself in some bizarre dark corner of a huge ecosystem of products, that's just not true. Deployments are just "file copy". You don't even need Docker, because Windows isn't Linux, it has stable user-land APIs so apps are portable . Not to mention that the dotnet sdk can create container images directly without even needing Docker installed: https://learn.microsoft.com/en-us/dotnet/core/containers/…
> with C code blended in randomly And now add a small Python neural network to a .NET app. Just to do some mild AI stuff. Go on, I'll wait. Oh, and I forgot: don't forget about data migrations. It's a freaking disaster in .NET deployments. Apparently, the best practice is to apply them manually?
CSnakes integrates Python into .NET apps - https://tonybaloney.github.io/CSnakes/
https://www.youtube.com/watch?v=DqoxHNH9Iwo shows adding an LLM
There are several ways to manage migrations depending on the team structure and dev practices: SQL scripts, command line, bundles (single-file executables), and in-app. The team recommends SQL scripts since they can be reviewed, tuned, and managed by a DBA but take your pick. https://learn.microsoft.com/ef/core/managing-schemas/migrati...
Re: Microsoft Dependency Has Risks
#209Earlier quoted context omitted.
> with C code blended in randomly And now add a small Python neural network to a .NET app. Just to do some mild AI stuff. Go on, I'll wait. Oh, and I forgot: don't forget about data migrations. It's a freaking disaster in .NET deployments. Apparently, the best practice is to apply them manually?
CSnakes integrates Python into .NET apps - https://tonybaloney.github.io/CSnakes/ https://www.youtube.com/watch?v=DqoxHNH9Iwo shows adding an LLM There are several ways to manage migrations depending on the team structure and dev practices: SQL scripts, command line, bundles (single-file executables), and in-app. The team recommends SQL scripts since they can be reviewed, tuned, and managed by a DBA but take your pic…
And how do you _build_ it? "It works on my machine", yeah? "Just copy it", ya?
Re: Microsoft Dependency Has Risks
#210Earlier quoted context omitted.
CSnakes integrates Python into .NET apps - https://tonybaloney.github.io/CSnakes/ https://www.youtube.com/watch?v=DqoxHNH9Iwo shows adding an LLM There are several ways to manage migrations depending on the team structure and dev practices: SQL scripts, command line, bundles (single-file executables), and in-app. The team recommends SQL scripts since they can be reviewed, tuned, and managed by a DBA but take your pic…
And how do you _build_ it? "It works on my machine", yeah? "Just copy it", ya?
dotnet build
https://tonybaloney.github.io/CSnakes/getting-started/#build...
What's with the "just copy it" thing? Nobody does that, we use NuGet packages, GitHub Actions, SDK supported containers, reproducible cross-platform builds from command line, etc.
edit: I'm sure some people use file/copy, but you sure don't have to. That stopped being a common thing 10+ years ago with cross-platform .NET.