31–40 of 169 posts
Earlier quoted context omitted.
This seems like the exact opposite of EEE. Care to explain your thinking?
One assumes the idea is to make windows have feature parity with linux, then try to leverage network effects for features windows has but linux doesn't, such that the "extinguish" step will follow the "extend" step.
And that is, kids, how MS Windows piece-by-piece was slowly transformed into a Linux distro.
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.
Earlier quoted context omitted.
I'm probably pretty similar in experience to you. I "grew up" with Linux (and Xenix) in the early 90s, not being able to afford to buy Windows Server. I transitioned over to Windows Server around NT 3.51 and now handle both. All the tooling for headless / remotely-manageable Windows is "in there" in 2008 and later. Prior versions required more jumping thru hoops to manage via command line, but Resource Kit tools help…
My server administration journey actually began with a pirated copy of Windows 2000 Advanced Server. And I don't feel bad for it, because having started very young with Windows Server has directly led to many tens/hundreds of thousands of dollars in licensing fees paid to Microsoft at my direction :)
The tedious "re-apply the service pack and reboot" or "you thought about changing a setting, so therefore reboot" scenarios were nearly removed with Windows 2000. Having plug 'n play and hot-plug hardware work well was great, too.
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.
Importantly: eBPF has at this point not much to do with packets; it's a generic kernel and userland instrumentation layer. Most new BPF code is written to monitor local program runtimes, not to look at packets.
If Windows adopts XDP, we might get to a point where
I wonder what kind of performance this gets when compared with running eBPF since eBPF was written with performance in mind from the start.
What?
Earlier quoted context omitted.
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 seem to recall authorized_keys works as expected; it goes into %HOME%\.ssh\authorized_keys (I'm not sure/can't recall if there are some similar permission requirements). Anyway, that's eg: c:\users\mcgyver\.ssh\authorized_keys And ssh needs a restart. That said, windows remote management is traditionally via WMI, not powershell. But PS has come a long way, and ssh is a sane transport. And it can function as a tunne…
https://docs.microsoft.com/en-us/windows-server/administrati...
Is there any analogue of seccomp in windows that can be used with BPF?
I wonder what kind of performance this gets when compared with running eBPF since eBPF was written with performance in mind from the start.
Earlier quoted context omitted.
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 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…
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 Windows bug-for-bug. Even if it makes no sense in Windows.
A recent example that boiled my blood is that the new Windows Terminal emulates the incorrect "Clear-Host" behaviour of ancient Linux terminals. It doesn't clear the virtual terminal any more, just the current viewport. Before, it was a convenient way to reset the terminal's display state without resetting variables. NOW, it just deletes some of the display state, so if you scroll back you get scrambled garbage.
This is not a small thing: it's significantly impacting my workflow. I've seen garbage output, overwritten output, scrolling back accidentally corrupts the output completely, you name it. This is not a coding error, this is correctly copying a limitation of some terrible terminal from the 1960s nobody should give a shit about in 2021.
Worse: If you look back at the history of the debate around fixing this, as far back as the early 1990s there were Linux people advocating for fixing this! It's obviously broken.
Then: When the same debate came up in the Windows Terminal issue tracker, people making the same rational, logical arguments were shot down with: "We have to copy the standard."
Hint: There is no "standard". This is not an RFC. It's just what Linux does! Linux does this just because this is what some random MIT or Berkley student wrote in a hurry in the 1960s! If you make the argument that the majority of systems work some way or another, and that's a defacto standard... then Windows should win because it was used for the the vast majority of computing for many decades. Linux has taken over only recently, and only in some areas (Android and web servers).