yes they're not bash but they're an integral part of bash scripts pipe processing
They are "integral" only because shell is lacking those functions. On some places tools are not there (docker image for example). Some people complain about size of the dotNet runtime, but if you install all those tools bash "needs" for comfy usage, you can equally easy install dotNet.
I don't think that's right. unix users care a lot about streams of bytes as exchange format, powershell tried the object stream way, to avoid parsing manually stuff every time and also share some common bits (table formatting for free, map/filter for free too)
unix give you partial stuff for that like comm but it's just brittle
And that is, kids, how MS Windows piece-by-piece was slowly transformed into a Linux distro.
I recently spun up a Windows EC2 server instance in aws, running the latest Windows, and was not impressed. The entire system is not very well set up for operation via SSH. SSH is not even enabled by default on ec2. You have to Remote Desktop in, run a bunch of commands to enable it, and even then I could never figure out how to get authorized_keys to work. Once you have SSH running, you can run commands via command…
I kinda like Windows server, mostly for the stability - both of the runtime and of functionality. Compared to Linux it requires less attention, i can concentrate more on software and less on the system: after two years of not touching i can still find configuration options in more or less same places. With Linux i have to re-learn quite a lot after not paying attention for a while. Missing good ssh/command line but not badly, I don't really need advanced shell scripting.
> Compiling on WSL2 would have terrible performance. define terrible. Compared to what ? > No one is seriously developing in WSL. A very strong statement. Do you have any proof perhaps ?
> define terrible. Compared to what ? Terrible = significantly worse than a native Linux distro that doesn't use a file system integration layer. > A very strong statement. Do you have any proof perhaps ? Just experience working in the industry.
> worse than a native Linux distro that doesn't use a file system integration layer
Microsoft is really being bold about adopting open tech to improve either it’s bottom line (Azure now runs more Linux VMs than Windows ones) and now with eBPF. Truly a new and different Microsoft.
See https://en.wikipedia.org/wiki/Embrace,_extend,_and_extinguis... Step 1: Getting SQL and a few other things running in Linux. That was in 2016. Step 2: WSL and WSL 2 eBPF puts them at something like step 2.2.5
This seems like the exact opposite of EEE. Care to explain your thinking?
If you're thinking in EEE terms, this is Embrace. Extend and Extinguish come later, once you've got a preponderance of developers on your platform.
I like Windows Server more than Linux. I administer both of them, although I am more familiar with Windows Server which definitely plays a big part in my preference. But I think that's going to be the biggest part of anyone's preference. Everything you complain about Windows Server not supporting is actually supported, but it was your unfamiliarity that was ultimately the issue. "Linux guy who is unfamiliar with Wind…
"When in Rome, do as the Romans do." I don't complain that Linux is hard to administer with PowerShell. I learned SSH and Bash. The reverse does not seem to be true, Linux admins generally expect everything to work exactly the same in Windows as in Linux. A negative effect of this is that Windows has many recent hires working on some of their teams with mostly Linux experience, and they're copying Linuxisms into Wind…
Those recent hires are also affecting how Visual Studio gets developed.
It is starting to become tiresome to get some CLI stuff instead of proper VS wizards.
Great news, I'm looking forward to analyzing performance on Windows with BPF! Given that PerfView and WPA also got flame graphs it'll start to feel like home. :-)
Great news, I'm looking forward to analyzing performance on Windows with BPF! Given that PerfView and WPA also got flame graphs it'll start to feel like home. :-)
From the architecture diagram, it looks like just network ebpf only.
Does anyone know if it can profile file/disk io type activities?
I like Windows Server more than Linux. I administer both of them, although I am more familiar with Windows Server which definitely plays a big part in my preference. But I think that's going to be the biggest part of anyone's preference. Everything you complain about Windows Server not supporting is actually supported, but it was your unfamiliarity that was ultimately the issue. "Linux guy who is unfamiliar with Wind…
Windows OS is a thing of the past, when people were supposed to do most of their work from a desktop. As soon as computing become based on remote services, Windows lost its main reason to exist. It is Windows that needs to adapts to the new times, not people working on other OSs.
It is the OS from the past and still most people use it on their computers. Because they are still doing things from the desktop. And I suppose they're happy not having to adapt to technology du jour again and again.
I admittedly have only an extremely cursory knowledge of these sort of technologies, but how does eBPF compare to NDIS filters and WFP filters? Biggest reason I could imagine for this is easier portability of existing eBPF applications.
You can do a lot more in NDIS and probably more in WFP than you can in eBPF, if only because eBPF has strict limits on the kinds of loops you can express (they have to be verifiably bounded). Packet-processing BPF programs are tightly bound to Linux kernel APIs, many of which won't be ported here, so I think write-once-run-anywhere is unlikely to be an attribute of this. Importantly: eBPF has at this point not much t…
The packet-processing BPF programs are less tightly bound to Linux kernel APIs than you might think. Even in Linux, there has been motivation to make the APIs more generic to support different kernel hooks for packets, in particular XDP which doesn't operate on the standard internal packet buffer representation (skbuff).