4 ms·

This is precisely the attitude that I'm arguing against. No, Linux is not superior in any way for Windows install image automation! Why the heck would you rev

This is precisely the attitude that I'm arguing against. No, Linux is not superior in any way for Windows install image automation! Why the heck would you reverse engineer and port the DISM tool, when the DISM tool already exists!?. Windows has a built-in set of free tools for automating image updates, integrations, and builds. E.g.: you can mount a WIM image offline (without booting a VM or needing a container), and inject updates, software, configuration, or even drivers. This is 100% supported an Will Just Work. It takes minutes, not hours. The article is the rough equivalent of trying to build a Linux install image using Windows, via some broken FUSE EXT3 driver the causes blue-screen crashes of the entire host OS, then spending a month trying to fix that instead of just using Linux to solve the task like a normal person. PS: I do 99.9% of my work with Windows. The one time in my career I had to inject drivers into a Linux install image, I created a Linux VM and just used that. (I had to make a version of XenServer that could boot from a MPIO FC adapter during install time, even if a path was down. Fun stuff.)

encryptluks2 4y ago
> No, Linux is not superior in any way for Windows install image automation! Having to configure a Windows environment for programmatic actions and subsequent changes is definitely more challenging. Even with the recent SSH access, which I believe the WinRM feature is still in preview, there are a lot of challenges for authentication that simply are not present in Linux. > Why the heck would you reverse engineer and port the DISM tool, when the DISM tool already exists!?. Because if you can do it in Linux, it makes sense to use an OS that is optimized to run like 95% of the world's server infrastructure due to performance and operational benefits. I really don't have time to get into an argument about why Steam OS chose Linux and why people use Wine to run Windows games on Linux. However, those are just a few indications that you're wrong. > Windows has a built-in set of free tools for automating image updates, integrations, and builds. They have a tool. I'm aware of Windows ADK. Everything else they had is no longer updated as far as I can tell. Most of them are just crappy GUIs wrapped around basic instructions that are as simple as creating partitions and copying files. > E.g.: you can mount a WIM image offline (without booting a VM or needing a container), and inject updates, software, configuration, or even drivers. It takes several minutes when in reality it is a subpar experience for developers looking to create multiple images. If someone creates a tool in Linux to do the same thing, but does it better, why does that bother you so much? Are you as bothered that Windows essentially has tried to create a Linux subsystem for Windows because developers were leaving Windows in droves because they found developing on Linux more pleasant? > The one time in my career I had to inject drivers into a Linux install image. You mean essentially installing a package via cloud-init which takes a second to add? Injecting drivers with Windows is still tedious if done through DISM and not the unattended XML.
- jiggawatts 4y ago
  > You mean essentially installing a package via cloud-init which takes a second to add? No. I had to rebuild the entire image, from the boot image up, to support MPIO Fibre Channel with the capability to install successfully via PXE network boot even if one of the two fabric paths was down. This was to support large-scale deployments to diskless blade servers using a central SFTP server, where the installation target was a SAN disk array. This is actually possible to achieve purely via Windows, using various Cygwin tools, but it is incredibly painful. I used Linux in a virtual machine to do the build, which made this was relatively quick and easy[1] to implement. This makes sense, of course! Windows is easy to use to build Windows images, Linux is easy to use to build Linux images. Similarly, I would use MacOS to build MacOS images, and so forth. Note that I basically never use Linux, except for rare cases such as needing to deploy the XenServer hypervisor, or some network appliance. Nonetheless, I did not "reach for Windows" as my preferred option, despite my vastly greater familiarity and skills with it compared to Linux. That's my point. The original article author has only a hammer and sees everything as a nail, even screws. It doesn't matter if the hammer is great at driving in nails. It can be awesome at that. If you need to drive a screw, pick up a screwdriver, instead of writing clever blog posts about how hammers can be laboriously filed down to enable them to clumsily turn a screw. [1] The requirement was complex, the actual change steps to get there were not too bad, even for a "non Linux person" like me.
  - encryptluks2 4y ago
    > No. I had to rebuild the entire image, from the boot image up, to support MPIO Fibre Channel. I've never seen this. At least for the distros I'm familiar with it is a simple as modifying your mkinit to include a driver. Maybe XenServer is different or whatever it was that you were using.
hamburglar 4y ago
I have nice, mature infrastructure (and expertise) for managing linux boxes. I do not have any desire to build or purchase infrastructure (and expertise) for managing windows boxes. If I have a task that can be done reasonably on my existing infrastructure, I’m not adding Windows to the mix without good reason.
- Kwpolska 4y ago
  If you’re building Windows images, you’re already doing serious stuff with Windows, and you’re probably about to deploy it to multiple workstations. Having a Windows server in this scenario makes a whole lot of sense.
  - hamburglar 4y ago
    End-user workstations are way different than operational hosts. The workstations themselves are not "serious" because they don't necessarily need configuration management, compliance monitoring, centralized user management, operational metrics monitoring, yadda yadda yadda. The service which builds those workstations' custom images is operationalized and does need all this. I'm not a Windows shop. There's no Windows in my datacenter. That's reason enough to use "non-native" processes for building Windows images.

encryptluks2 4y ago

> No, Linux is not superior in any way for Windows install image automation! Having to configure a Windows environment for programmatic actions and subsequent changes is definitely more challenging. Even with the recent SSH access, which I believe the WinRM feature is still in preview, there are a lot of challenges for authentication that simply are not present in Linux. > Why the heck would you reverse engineer and port the DISM tool, when the DISM tool already exists!?. Because if you can do it in Linux, it makes sense to use an OS that is optimized to run like 95% of the world's server infrastructure due to performance and operational benefits. I really don't have time to get into an argument about why Steam OS chose Linux and why people use Wine to run Windows games on Linux. However, those are just a few indications that you're wrong. > Windows has a built-in set of free tools for automating image updates, integrations, and builds. They have a tool. I'm aware of Windows ADK. Everything else they had is no longer updated as far as I can tell. Most of them are just crappy GUIs wrapped around basic instructions that are as simple as creating partitions and copying files. > E.g.: you can mount a WIM image offline (without booting a VM or needing a container), and inject updates, software, configuration, or even drivers. It takes several minutes when in reality it is a subpar experience for developers looking to create multiple images. If someone creates a tool in Linux to do the same thing, but does it better, why does that bother you so much? Are you as bothered that Windows essentially has tried to create a Linux subsystem for Windows because developers were leaving Windows in droves because they found developing on Linux more pleasant? > The one time in my career I had to inject drivers into a Linux install image. You mean essentially installing a package via cloud-init which takes a second to add? Injecting drivers with Windows is still tedious if done through DISM and not the unattended XML.

jiggawatts 4y ago
> You mean essentially installing a package via cloud-init which takes a second to add? No. I had to rebuild the entire image, from the boot image up, to support MPIO Fibre Channel with the capability to install successfully via PXE network boot even if one of the two fabric paths was down. This was to support large-scale deployments to diskless blade servers using a central SFTP server, where the installation target was a SAN disk array. This is actually possible to achieve purely via Windows, using various Cygwin tools, but it is incredibly painful. I used Linux in a virtual machine to do the build, which made this was relatively quick and easy[1] to implement. This makes sense, of course! Windows is easy to use to build Windows images, Linux is easy to use to build Linux images. Similarly, I would use MacOS to build MacOS images, and so forth. Note that I basically never use Linux, except for rare cases such as needing to deploy the XenServer hypervisor, or some network appliance. Nonetheless, I did not "reach for Windows" as my preferred option, despite my vastly greater familiarity and skills with it compared to Linux. That's my point. The original article author has only a hammer and sees everything as a nail, even screws. It doesn't matter if the hammer is great at driving in nails. It can be awesome at that. If you need to drive a screw, pick up a screwdriver, instead of writing clever blog posts about how hammers can be laboriously filed down to enable them to clumsily turn a screw. [1] The requirement was complex, the actual change steps to get there were not too bad, even for a "non Linux person" like me.
- encryptluks2 4y ago
  > No. I had to rebuild the entire image, from the boot image up, to support MPIO Fibre Channel. I've never seen this. At least for the distros I'm familiar with it is a simple as modifying your mkinit to include a driver. Maybe XenServer is different or whatever it was that you were using.

hamburglar 4y ago

I have nice, mature infrastructure (and expertise) for managing linux boxes. I do not have any desire to build or purchase infrastructure (and expertise) for managing windows boxes. If I have a task that can be done reasonably on my existing infrastructure, I’m not adding Windows to the mix without good reason.

Kwpolska 4y ago
If you’re building Windows images, you’re already doing serious stuff with Windows, and you’re probably about to deploy it to multiple workstations. Having a Windows server in this scenario makes a whole lot of sense.
- hamburglar 4y ago
  End-user workstations are way different than operational hosts. The workstations themselves are not "serious" because they don't necessarily need configuration management, compliance monitoring, centralized user management, operational metrics monitoring, yadda yadda yadda. The service which builds those workstations' custom images is operationalized and does need all this. I'm not a Windows shop. There's no Windows in my datacenter. That's reason enough to use "non-native" processes for building Windows images.