Live data from Hacker News

eBPF on Windows

github.com

61–70 of 169 posts

Re: eBPF on Windows

#61
post #2

And that is, kids, how MS Windows piece-by-piece was slowly transformed into a Linux distro.

"Eschew flamebait. Avoid unrelated controversies and generic tangents." https://news.ycombinator.com/newsguidelines.html

Comments like this one take threads in predictable, uninteresting directions, and—what's worse—they often get upvoted, accumulating mass at the top of the thread and choking out the specific interesting stuff.

"Windows v Linux" is a classic example of a generic black hole, sucking passing spaceships into a state from which no light can emerge: https://hn.algolia.com/?dateRange=all&page=0&prefix=true&que....

To be fair, this is a co-creation between the comment and the upvotes, and the upvotes are more to blame. But the idea of that guideline is to refrain from introducing black holes in the first place, so the spaceship can poke around something interesting in the vicinity without collapsing, screaming, into an irreversible fate.

Related explanation here if anyone wants more: https://news.ycombinator.com/item?id=26894739. Note the point about diffs—that's key. Diffs are what's interesting!

Re: eBPF on Windows

#62
post #28

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 won't comment on the eBPF or WSL or even the Windows as linux debate, but I used to do some Windows admin. Some clarifications are in order. MSIs CAN be installed on servers with no gui required. Or much more commonly via powershell automation. Completely remotely and I'm not referring to remote desktop either. I know its fun to complain about Windows, but really, if you're not using powershell and the right tools…

I can't imagine how anybody manages any number of Windows machines w/o a domain. Even just an NT 4.0-style "downlevel" domain (hosted with Samba, if need be) made life so much easier "back in the day". Once Active Directory came out I never looked back. Group Policy makes so many Windows administration tasks reproducible and automated.

I keep meaning, year after year, to take at Samba and see how its Active Directory emulation functionality has progressed. I never end up getting around to it. Presumably, since so much of Active Directory is really just leveraging LDAP and a funky proprietary schema, it has progressed significantly.

I've had a hard time figuring out how to position Desired State Configuration. It feels like an appeal to Linux sysadmins used to Puppet, Chef, et al. I can already do everything it can do with Group Policy, and I'd want an Active Directory domain for single-sign-on anyway. I have a hard time coming up with a use case for learning all new tooling when I've already got AD and Group Policy.

Re: eBPF on Windows

#63

Earlier quoted context omitted.

> Powershell is apparently pretty modern and well designed, but it's quite confusing if you're used to Unix. bash is pretty confusing eve if you're used to unix -- Greg's

Bash is simply outdated. It grown organically and thats what you got. Now you have zillion scripts and situation is even worst then with cobol. PowerShell was made by Unix people after 2+ decades of bash experience. It solved hundreds of things. Yet people complain it didn't solve few or it takes a bit more to load (no, verbosity = RTFM). You can't ever please I guess.

were powershell designers from the unix world ? I didn't know that

I don't mind bash warts, history is what it is, I don't sell powershell .. but someone saying powershell is confusing has serious jaws. powershell is really nice and only if you fancy sed/grep everything then you'll consider bash* superior

Re: eBPF on Windows

#64
post #58

Earlier quoted context omitted.

"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…

Microsoft is getting really lazy with their new "PowerShell for everything" mantra. Many examples with Windows Server and even the Azure Portal. It's great to have the ability to do things with both a GUI and CLI, but then arbitrarily limiting things to one or the other (usually the CLI) gets incredibly annoying.

Lets limit GUI then :)

Re: eBPF on Windows

#65

Earlier quoted context omitted.

Bash is simply outdated. It grown organically and thats what you got. Now you have zillion scripts and situation is even worst then with cobol. PowerShell was made by Unix people after 2+ decades of bash experience. It solved hundreds of things. Yet people complain it didn't solve few or it takes a bit more to load (no, verbosity = RTFM). You can't ever please I guess.

were powershell designers from the unix world ? I didn't know that I don't mind bash warts, history is what it is, I don't sell powershell .. but someone saying powershell is confusing has serious jaws. powershell is really nice and only if you fancy sed/grep everything then you'll consider bash* superior

sed/grep/awk have nothing to do with bash tho and you can run them equally easy on Windows (cinst sed grep awk) if you like outdated reg ex.

Re: eBPF on Windows

#66

Earlier quoted context omitted.

The Linux functionality is intended to allow Windows developers to develop for Linux and deploy to Linux.

Compiling on WSL2 would have terrible performance. WSL2 is just there to try to entice companies to say their developers shouldn't need to move to Linux or Mac. No one is seriously developing in WSL.

> 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 ?

Re: eBPF on Windows

#67
post #41

Earlier quoted context omitted.

BPF or berkely packet filter was written to be a faster replacement of tcpdump. People saw that it was pretty neat and started using it for non-tcp dump like stuff and it became extended BPF/eBPF. I would guess that running eBPF on Windows would be a lot slower, but it would be interesting to see a performance comparison.

Point of order: BPF wasn't written simply for tcpdump; it's part of a line of research on using PL runtimes to configure and operate networking stacks; so, right after McCanne's BPF paper, you get MPF, which is proposed to do all of demux for Mach.

Neat, did not know that.

Re: eBPF on Windows

#68

Earlier quoted context omitted.

Bash is simply outdated. It grown organically and thats what you got. Now you have zillion scripts and situation is even worst then with cobol. PowerShell was made by Unix people after 2+ decades of bash experience. It solved hundreds of things. Yet people complain it didn't solve few or it takes a bit more to load (no, verbosity = RTFM). You can't ever please I guess.

were powershell designers from the unix world ? I didn't know that I don't mind bash warts, history is what it is, I don't sell powershell .. but someone saying powershell is confusing has serious jaws. powershell is really nice and only if you fancy sed/grep everything then you'll consider bash* superior

> Sure, although, you know, my team – we all have deep UNIX backgrounds, before getting into NT, I was a UNIX development manager at Digital [Equipment Corporation], … worked on Ultrix, System 5.

https://www.networkworld.com/article/3110744/linuxcon-qa-wit...

Re: eBPF on Windows

#69
post #58

Earlier quoted context omitted.

Microsoft is getting really lazy with their new "PowerShell for everything" mantra. Many examples with Windows Server and even the Azure Portal. It's great to have the ability to do things with both a GUI and CLI, but then arbitrarily limiting things to one or the other (usually the CLI) gets incredibly annoying.

Lets limit GUI then :)

Ha, that's actually what I'm complaining about. So many things that can only be done via CLI and there's no way to even know they're possible without crawling through documentation or (more often) finding somebody's blog post or a StackOverflow answer.

Re: eBPF on Windows

#70
post #41

Earlier quoted context omitted.

Point of order: BPF wasn't written simply for tcpdump; it's part of a line of research on using PL runtimes to configure and operate networking stacks; so, right after McCanne's BPF paper, you get MPF, which is proposed to do all of demux for Mach.

Neat, did not know that.

A long post I wrote about this stuff, taking the history back to the Xerox Alto:

https://fly.io/blog/bpf-xdp-packet-filters-and-udp/

Post reply on HN