Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Microsoft Dependency Has Risks

blog.miloslavhomer.cz

Post reply on HN
Print view View original

211–220 of 238 posts

Re: Microsoft Dependency Has Risks

#211

Post by whoknowsidont »

majkinetor wrote: post #200
mrcsharp wrote: post #181

Earlier quoted context omitted.

> What is done using c# in 10 lines can be done in a single line in pwsh Mostly, yes. The problem is that the moment I need something more than what a single cmdlet or bash utility can provide, now I have to use an awkward looking scripting language (bash is the worst offender here). Almost every time I found myself having to write a somewhat long script file, I wish I could just do it with a C like language instead.…

There are many simple tasks in a typical multiyear project. Most of my scripts are between 100 and 1000 lines of code. Example: https://github.com/majkinetor/SSImport That script made noticeable difference in speed, quality and pleasure on our recent project (production tests on payment gateway for half of the country) as before I wrote it, devs did it by hand which took 10s of minutes every day with awkward tools (i…

Your github link 404's, FYI.

Re: Microsoft Dependency Has Risks

#212

Post by majkinetor »

whoknowsidont wrote: post #211
majkinetor wrote: post #200

Earlier quoted context omitted.

There are many simple tasks in a typical multiyear project. Most of my scripts are between 100 and 1000 lines of code. Example: https://github.com/majkinetor/SSImport That script made noticeable difference in speed, quality and pleasure on our recent project (production tests on payment gateway for half of the country) as before I wrote it, devs did it by hand which took 10s of minutes every day with awkward tools (i…

Your github link 404's, FYI.

Sorry, was private repo, now its public.

Re: Microsoft Dependency Has Risks

#213

Post by mrcsharp »

majkinetor wrote: post #200
mrcsharp wrote: post #181

Earlier quoted context omitted.

> What is done using c# in 10 lines can be done in a single line in pwsh Mostly, yes. The problem is that the moment I need something more than what a single cmdlet or bash utility can provide, now I have to use an awkward looking scripting language (bash is the worst offender here). Almost every time I found myself having to write a somewhat long script file, I wish I could just do it with a C like language instead.…

There are many simple tasks in a typical multiyear project. Most of my scripts are between 100 and 1000 lines of code. Example: https://github.com/majkinetor/SSImport That script made noticeable difference in speed, quality and pleasure on our recent project (production tests on payment gateway for half of the country) as before I wrote it, devs did it by hand which took 10s of minutes every day with awkward tools (i…

I think we are talking a bit past each other here. I don't contest the benefit of writing small helper utilities.

> Regarding syntax, not sure why would you consider that awkward

This is more true with Bash than Powershell. However, this is the same with programming languages in general. There are those who look at Julia's syntax and think it's absolutely beautiful and those who consider it to be absolutely bad and prefer Visual Basic.

Re: Microsoft Dependency Has Risks

#214

Post by mrcsharp »

cyberax wrote: post #196
mrcsharp wrote: post #141

Earlier quoted context omitted.

> The deployment story is non-existent Wrong! it is as simple as executing `dotnet publish`, zipping up the output folder and sending that package somewhere using whichever protocol and shell utility you like. > monitoring, tracing, alarming is barely there Also wrong. OpenTelemetry is fully supported by first-class packages and the dotnet runtime itself exposes a lot of counters. There are a lot of tools to monitor…

> Wrong! it is as simple as executing `dotnet publish` Yeah. And now add a C/C++ component there. Or maybe a neural network in Python? In my case, it was a ray tracer that used a GPU. "Just zip it", yea sure.

> Yeah. And now add a C/C++ component there. Or maybe a neural network in Python?

How do you compile and package those components up? Answer that and you have your answer for this scenario.

>"Just zip it", yea sure.

I don't understand this. You can zip it. You can XCopy it. You can RSync it. Doesn't matter. What's your objection to that statement?

Re: Microsoft Dependency Has Risks

#215

Post by cyberax »

mrcsharp wrote: post #214
cyberax wrote: post #196

Earlier quoted context omitted.

> Wrong! it is as simple as executing `dotnet publish` Yeah. And now add a C/C++ component there. Or maybe a neural network in Python? In my case, it was a ray tracer that used a GPU. "Just zip it", yea sure.

> Yeah. And now add a C/C++ component there. Or maybe a neural network in Python? How do you compile and package those components up? Answer that and you have your answer for this scenario. >"Just zip it", yea sure. I don't understand this. You can zip it. You can XCopy it. You can RSync it. Doesn't matter. What's your objection to that statement?

> How do you compile and package those components up? Answer that and you have your answer for this scenario.

I have a Dockerfile that contains the build instructions? How would I do that with MSVS?

> I don't understand this. You can zip it.

Yes, and then my Linux machine that runs the server will happily run a Windows application. With all the dependencies, including the GPU toolkits.

But even if we stay _within_ the MS ecosystem, the "just copy it" deployment doesn't cover everything. E.g. it can't change the settings of the "App Service Logs" from within the app itself. Of course you can also use Terraform for the infra, but at this point you're way off the "just copy a folder".

MSVS also supports containers, but if you do that it just becomes a UI for their configuration, not really any different from JetBrains.

Re: Microsoft Dependency Has Risks

#216

Post by cyberax »

jongalloway2 wrote: post #210
cyberax wrote: post #209

Earlier quoted context omitted.

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.

Nope. Try again.

> Nobody does that

Read the parent post.

> we use NuGet packages, GitHub Actions, SDK supported containers, reproducible cross-platform builds from command line, etc.

So basically, "NPM but different". Got it.

Re: Microsoft Dependency Has Risks

#217

Post by mrcsharp »

cyberax wrote: post #215
mrcsharp wrote: post #214

Earlier quoted context omitted.

> Yeah. And now add a C/C++ component there. Or maybe a neural network in Python? How do you compile and package those components up? Answer that and you have your answer for this scenario. >"Just zip it", yea sure. I don't understand this. You can zip it. You can XCopy it. You can RSync it. Doesn't matter. What's your objection to that statement?

> How do you compile and package those components up? Answer that and you have your answer for this scenario. I have a Dockerfile that contains the build instructions? How would I do that with MSVS? > I don't understand this. You can zip it. Yes, and then my Linux machine that runs the server will happily run a Windows application. With all the dependencies, including the GPU toolkits. But even if we stay _within_ th…

> I have a Dockerfile that contains the build instructions

So what's stopping you from doing this with dotnet? Going by your logic, no other programming language reaches your ideal "deployment story" the moment you reach for docker.

> Yes, and then my Linux machine that runs the server will happily run a Windows application. With all the dependencies, including the GPU toolkits.

Dotnet is cross platform. If you are targeting Linux then you can give that information using `dotnet build --os linux` and nuget packages that have platform-specific binaries would then supply the build with the correct binary.

> But even if we stay _within_ the MS ecosystem, the "just copy it" deployment doesn't cover everything. E.g. it can't change the settings of the "App Service Logs" from within the app itself. Of course you can also use Terraform for the infra, but at this point you're way off the "just copy a folder".

That's because it is not the job of any programming language compiler to make changes to cloud infrastructure. You know single responsibility and all that.

Re: Microsoft Dependency Has Risks

#218

Post by xcrunner529 »

firesteelrain wrote: post #40
mnadkvlb wrote: post #26

Earlier quoted context omitted.

genuinely interested, what are the alternatives ? i know ping/forgerock and some old ibm stuff. what is state of the art today that compares to ActiveDirectory (not talking azureAd - or whatever they call it these days) ?

Samba4 is the closest you can get. It is not as nice as ActiveDirectory.

Why not Okta? I know a company that uses it and no AD. (But they are mostly Mac)

Re: Microsoft Dependency Has Risks

#219

Post by xcrunner529 »

p_ing wrote: post #62
cyberax wrote: post #36

Earlier quoted context omitted.

AD is one of the few good MS projects. But you can use it with Macs and Linux just fine! Just keep a couple of Windows servers running AD, and migrate everything else.

Apple doesn't recommend joining Macs to AD -- their implementation is awful, along with their SMB implementation. But it is technically possible.

The new way is local account with synced password and Kerberos.

Re: Microsoft Dependency Has Risks

#220

Post by xcrunner529 »

briHass wrote: post #76
smaudet wrote: post #70

Earlier quoted context omitted.

> IT never even has to be in the same zipcode as the new laptop or ever remotely connect to it to perform maintenance tasks. That sounds nice, but that's not exactly a feature specific to AD. All perfectly possible with a couple well placed scripts and some remote logins. > TPM-backed certificates/WebAuthn for securing web apps or anything behind MS-linked SSO Yeah this is the overengineered stuff that is therefore d…

How are you having Dell ship a brand new laptop to a non-technical user and having that machine configured/software installed with a couple of scripts? Autopilot locks Windows OOBE to your Intune instance based on the serial number. The user only has to know their email and a temp password if they're new, or existing login/otp if not. The device can be remotely wiped, and it will start back over at the OOBE (Windows…

Sure but Apple had that first. With MDM.
Post reply on HN