Hacker News Reader

Comment by nickysielicki | Hacker News Reader

I’m highly jealous of teams that can containerize all their build tools.

If you deal with proprietary toolchains that are tens of gigabytes (Windows WDK, Xilinx Vivado/Vitis) it’s just untenable, and that’s before even mentioning licensing. Even Azure doesn’t have a great solution for WDK development. It’s hard to feel like we’re not being left behind.

Bind mounting the tools into the container is an option but at that point you’re using the container just because that’s what your CI expects, not because it’s any better or more reproducible than a raw Jenkins shell script.

View on HN

In my personal experience, Windows development is absolutely awful. Nothing about it is ergonomic, and the management of the development environment is just painful. Obviously you don't always have a choice, but creating a nice development experience is clearly not a priority for Microsoft. One really basic example: I was deploying files to a Windows Server box using scp, but my internet connection died midway through the transfer. All subsequent deployments would fail until I could connect via RDP to kill the old SSH process holding an open file handle. Another example: I bought into the WSL hype, hoping it would solve all my problems. But you can't easily interact with files on the system outside of Linux subsystem, which made it more or less useless for my purposes. If I wanted to interact only with Linux files, I would have used a Linux-based server. Maybe I could get better at Powershell, but it felt overly verbose while also being less composable / powerful. The simple posix shell primitives were sorely missed. Running things on startup was also insane. I think I needed to add a triggered job that ran on user log in, and then configure the host to login a specific user when the host starts. Very crazy...

> But you can't easily interact with files on the system outside of Linux subsystem, which made it more or less useless for my purposes.

It’s possible in file explorer via \\wsl$, but that is not always supported by applications so it’s not 100%.

ls /mnt/c

Oh, hey, there's the C drive in WSL! ;)

ln -s /mnt/c/Users/Somejerk/Documents ~/documents

Oh, man, a shared documents folder!

Granted, access to those files is slow as dirt because of the Plan9 filesystem, and there are some weird bugs where a process sometimes loses access to $cwd if it's not a native wsl filesystem (also a Plan9 bug reported to MS over a year ago). But it's tolerable when interoperability is necessary.

It also facilitates using the same filesystem under multiple WSL instances.

I love unix tools (grep, sed, cut, etc.), and while there are some good sub-systems (msys2, cygwin), they might be bit heavey. For that the windows version of busybox - https://frippery.org/busybox/ - and then I make sure my scripts are not using too powerful features of said tools (grep especially), such that the version in busybox works. Great, and also possible to port some of that back to linux (but I mostly use it to build something, or extract some data but want to share the .bat file with others - one day when I get better in PowerShell I'll try there more).

I use scoop to install this sort of tool in Windows.

iwr -useb get.scoop.sh | iex # install scoop

scoop install coreutils vim nano [...] # yay

Nice! I'll try it out tomorrow finally.. after giving up on choco, and possibly on winget.

But in my case I wanted to leave something small (and busybox.exe is that small) /portable - for others to use (without the requirement to install scoop).

So scoop is awesome so far - the only thing I'm missing (right now) is to be able to specify specific bucket for some actions (but found workarounds).

Usually it helps by adopting Windows development practices instead of trying to cram UNIX workflows into it.

Who on their right mind uses ssh/scp on Windows development other than connecting to UNIX boxes?

> Who on their right mind uses ssh/scp on Windows development other than connecting to UNIX boxes?

Exactly. That's like complaining that I can't RDP into a linux box to install the toolchain!

What’s the alternative? I was deploying from a Mac, so connecting to a Unix box is exactly what I was doing.

A possible alternative.

https://support.apple.com/guide/mac-help/share-mac-files-wit...

https://docs.microsoft.com/en-us/windows-server/remote/remot...

Another alternative,

https://docs.microsoft.com/en-us/powershell/scripting/learn/...

I was deploying to a fleet of servers. Having every engineer add every server via the macOS sharing UI or using RDP to manually connect to each host doesn’t seem scalable. Maybe remote power shell sessions would work, but I’m not even sure if there is a power shell client for Mac, and it’s also not clear if remote power shell sessions would fix the open file handle issue.

Experienced Windows devs I talked to said they used Packer from Hashicorp to entirely recreate their server image whenever they wanted to deploy. This process takes hours, but that was the best I found.

I use gitlab for ci/cd, a gitlab-runner runs on a windows based system (legacy aka not .net core so can only build with msbuild.exe). Now I have to copy this release to another windows based system. Are you calling me stupid for using scp via openssh? Would like to hear an alternative? Took me like 5 minutes to set openssh up.

Windows has a mechanism for sharing folders; the protocol is SMB (CIFS is a dialect of SMB). You mount the the target and destination folders on the same machine (doesn't matter which one mounts the other), and then copy the file locally on the machine where they're both mounted.

That's my primary issue with Windows workflows, though. Unless you really convert over to using pretty much only MS tools, it is extremely hard to use them. Meanwhile the "Unix" workflow tends to be a collection of many open source tools with lots of competing solutions.

100% this.

I feel like there's a ton of innovation in the cloud/container CI/CD space, but next to nothing elsewhere. In fact, some of the innovations in CI/CD make things _more_ difficult for those of us developing in other environments (such as game development).

There's a lot of low hanging fruit for improving things elsewhere.

Yes! I’m responsible for a game development CI/CD pipeline that needs to run on windows and I feel like it’s harder than it needs to be in 2022.

Do you work in game development? I would love to hear a little bit more about your experience. I play and follow Apex Legends and I'm always so curious about how bugs and regressions seem to make it into every one of their patches. As well as tons of new information that gets data-mined.

To me, its like they don't have branches (tons of new code not accessible in the game is released in a patch) and they don't have unit tests that catch bugs (a certain ability has 2 modes, with 2 different activation times. In the most recent patch, the activation times ended up the same) but it's possible that developing a game is far different than developing a SaaS product from a coding perspective. Or it could be that studio just has weird practices.

> As well as tons of new information that gets data-mined.

Client side encryption is basically impossible; the decryption key has to be in the executable you ship somewhere, or at least sent to the client after a connection with the server. Perhaps some encryption tiering system could work to keep unreleased locked content locked for longer but I don’t think anyone has gone through that trouble yet.

> To me, its like they don't have branches (tons of new code not accessible in the game is released in a patch)

This is likely by choice, feature flags have a fair few advantages over feature branches and are generally far less of a pain point long term.

> This is likely by choice

It's likely because of inertia. I don't work for EA, but the majority of games studios use Perforce for source control which has... awful support for branches. They've got streams which are a huge improvement, but still nowhere near as flexible or easy to use as branches in git.

Exactly. I manage a CI infrastructure for a mobile game company (28 macs, a few Linux and windows VMs). I still can‘t use docker because our main development box is still macOS. We are slowly moving this to Linux. The reasons why we are still using macs as the main build machines are manyfolded. I know that android SDK and Unity run on Linux but our whole company came from a iOS first model and still uses macOS as the primary development box. But even docker would not help 100%. I have a strong emphasis that the tools run locally as well. And we have a mix of build and development tools. What I mean is that one and the same basic script should be used both during CI and differently with other parameters during development. Jenkins is our build executor. The whole build is setup with gradle as it had 5 years ago some very nice properties over other tools (self bootstrapping, robust plugin system, lots of libraries available). We build everything around this and only use Jenkins-pipelines to kick of said gradle jobs. But I would prefer a nicer solution. Ah we manage the machines with ansible (Mac, windows and Linux) I guess redhad had not thought about the fact that someone took the Multiplattform claims to the test. I can say it is kind of a nightmare to Code playbooks and roles against three different OS types.

You can add Apple toolchains to that list also

preach

I've been in your shoes before at a previous gig where we had a highly successful desktop application that ran on Windows. Containerization was an utter nightmare. It's brutal seeing posts like this too, because you feel like the whole world is leaving you behind.

It's made me super grateful to be where I am now, and able to even view tools like this as an option.

I saw a lot of projects build Windows artifacts with GitHub Actions.

It doesn't seem too hard.

Okay, here’s an SDK I use. It’s 16GB.

https://docs.microsoft.com/en-us/windows-hardware/drivers/do...

Show me how to use this with GitHub actions, if it’s not too hard.

I would use a self-hosted runner for that [1]. You can setup the SDK in that machine and it will be available for any jobs that end up running there.

Depending on your requirements/scale the runner(s) can be a VM in your main machine, a cheapo dedicated server (hetzner/ovh) or even autoscaled hotspot instances in your preferred cloud.

It is less pure than using GH's runners and having an end-to-end setup/teardown for your whole toolchain, but it would work just fine. Definitely better than without any CI.

In practice, this is what I’m doing with Jenkins. But my point is that all of these container-first CI solutions lack relevancy for my team.

Reply on news.ycombinator.com