Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

eBPF on Windows

github.com

Post reply on HN
Print view View original

151–160 of 169 posts

Re: eBPF on Windows

#151

Post by tux3 »

skinkestek wrote: post #27
encryptluks2 wrote: post #5

Earlier quoted context omitted.

They implement Linux functionality enough to suck at it and then the Windows users that try it thinks it is Linux that sucks and not Windows.

Let me tell you something interesting: .Net Core programs run much faster on Linux. Does that sound like something they would let happend if they wasn't serious about their Linux efforts? That said: all is not good. For years there seems to be a fight going on in the wheelhouse. One month it is: Microsoft, the reliable, reasonable vendor in a world full of Oracle and Google. Next month it is: let's increase the cost…

>Does that sound like something they would let happend if they wasn't serious about their Linux efforts?

Hhhm I think the most remarkable parr is that it runs at all, really! .Net Core on Linux by itself shows plenty commitment.

The performance of it? Considering NT was only developped by a single company, has to maintains a lot of stable/legacy driver APIs, and seems to have been on the backburner for a few years, as a Linux user I'd find it very humbling if our kernel still came out behind :)

It's interesting to see where this is all converging. It'll be easier to run Linux tech on Windows, and all the MS legacy still runs.

But at the same time maybe they're familiarising their loyal userbase with the outside ecosystem a little more than they should. If new Windows users are encouraged to learn Linux ways, at some point you're making it easier for people to transition

Re: eBPF on Windows

#152

Post by garethrowlands »

encryptluks2 wrote: post #146
garethrowlands wrote: post #93

Earlier quoted context omitted.

> worse than a native Linux distro that doesn't use a file system integration layer What filesystem integration layer?

https://docs.microsoft.com/en-us/windows/wsl/compare-version... > We recommend against working across operating systems with your files https://nelsonslog.wordpress.com/2019/06/01/wsl-access-to-li...

Yes, having your compiler on Linux access its files over plan9 would indeed have terrible performance. That's why Microsoft tell you not to do that.

Just run everything on the Linux kernel and compilation will be the same as on Linux. You do have a choice of where you put your files.

Re: eBPF on Windows

#153

Post by whizzter »

salawat wrote: post #130
sanxiyn wrote: post #107

Earlier quoted context omitted.

Microsoft did termination proof for Windows drivers in 2006. Termination proof does not require solving halting problem. Termination proofs for systems code (PLDI 2006): https://dl.acm.org/doi/10.1145/1133255.1134029

As mentioned in a sibling reply, there goes my week. Thanks for the reference! Time to learn something I apparently did not know!

I think you can reason it like this.

Assuming certain constraints (what you can define bounded analysis rules for) you can prove that things terminate. These rules things are usually far more advanced than we suspect initially, but they're not still not fully unbounded.(And we can often come up with more rules to make things practical even if unwieldy)

Deciding termination for an arbitrarily large program in a turing complete system CAN require no less than execution of such a program thus we CANNOT guarantee to be able to verify termination for EVERY program. (This is the halting problem)

I spent a lot of time on my thesis learning about type inference systems and as many such systems for uncooperative languages(JS,Python,etc) need to do abstract interpretation they fall into the same kind of issues and this is why practical systems use JIT compilation instead of AOT even if there are exceptions (Shed Skin Python is quite impressive for example).

Re: eBPF on Windows

#154

Post by [deleted] »

hs86 wrote: post #54

Here is a recent comment from Dropbox engineers about the state of tracing tooling on Linux compared to Windows: https://dropbox.tech/infrastructure/boosting-dropbox-upload-... Is their assessment correct? If so, how comes that we got DTrace in 2019 and now eBPF ported to Windows? Are they trying to consolidate all tooling into one platform?

[deleted]

Re: eBPF on Windows

#155

Post by garaetjjte »

hs86 wrote: post #54

Here is a recent comment from Dropbox engineers about the state of tracing tooling on Linux compared to Windows: https://dropbox.tech/infrastructure/boosting-dropbox-upload-... Is their assessment correct? If so, how comes that we got DTrace in 2019 and now eBPF ported to Windows? Are they trying to consolidate all tooling into one platform?

>This was an eye-opening experience for us. We saw how far behind Linux is on the tracing tooling side.

Yet, in a typical Microsoft way, if you want to use that Message Analyzer tool now:

>Microsoft Message Analyzer (MMA) is being retired and its download packages removed from microsoft.com sites on November 25 2019. There is currently no Microsoft replacement for Microsoft Message Analyzer in development at this time.

Re: eBPF on Windows

#156

Post by jhomedall »

encryptluks2 wrote: post #144
jhomedall wrote: post #118

Earlier quoted context omitted.

Having followed the instructions from https://docs.docker.com/engine/install/ubuntu/ , I was able to get this working fine. This is without Docker Desktop installed. It probably would have also worked with the version from distro repository. zed@ZED-PC:~$ sudo service docker start * Starting Docker: docker [ OK ] zed@ZED-PC:~$ sudo docker run hello-world Unable to find image 'hello-world:latest' locally latest: Pulli…

Are you even on Windows? This is with WSL 2, as you can systemd doesn't work as expected in WSL2. This is a known issue. If systemd is working for you, then you are doing something magic: sudo systemctl start docker [sudo] password for u3332: System has not been booted with systemd as init system (PID 1). Can't operate. Failed to connect to bus: Host is down https://stackoverflow.com/questions/55579342/why-systemd-is…

From that link (permalink to answer: https://stackoverflow.com/a/61887923) :

> Nowadays you can try:

> sudo service docker start

> when using WSL2, if you are running on windows version 2004 or higher (I assume).

Which is what I did in the listing above.

Re: eBPF on Windows

#157

Post by corty »

EvanAnderson wrote: post #133
corty wrote: post #129

Earlier quoted context omitted.

Group policy "automation" is painful and inconsistent. Parts are only applied on user login. Parts only on reboot. Parts instantly. Hard to impossible to know which is which. And no way to log off users or reboot machines via group policy, so you need remote logins anyways.

I'd argue it's just being familiar with the tools. I'm biased, no doubt. Windows sysadmin work has paid the lion's share of my bills since the late 90s. I've been using Group Policy heavily since 1999 (during the Windows 2000 beta), so I'm used to knowing what applies when. Being familiar with which client-side extensions (CSEs) do which processing helps. The documentation for Microsoft's own functionality is reasona…

I didn't claim that rebooting a Windows box is impossible or hard. It is just that group policies are no complete solution for anything, they are just a small and imho weird part.

Also, for a lot of things there is just no group policy you can set somewhere, so you are still in need of some "execute me that script that does the needful" in a lot of cases.

Re: eBPF on Windows

#158

Post by EvanAnderson »

corty wrote: post #157
EvanAnderson wrote: post #133

Earlier quoted context omitted.

I'd argue it's just being familiar with the tools. I'm biased, no doubt. Windows sysadmin work has paid the lion's share of my bills since the late 90s. I've been using Group Policy heavily since 1999 (during the Windows 2000 beta), so I'm used to knowing what applies when. Being familiar with which client-side extensions (CSEs) do which processing helps. The documentation for Microsoft's own functionality is reasona…

I didn't claim that rebooting a Windows box is impossible or hard. It is just that group policies are no complete solution for anything, they are just a small and imho weird part. Also, for a lot of things there is just no group policy you can set somewhere, so you are still in need of some "execute me that script that does the needful" in a lot of cases.

We have different experiences. Group Policy is a tool that I'm confident, in virtually any engagement, I can use to automate nearly all the goings-on of a Windows Server environment. Third-party software may not play well, but between the GPP CSEs and scripting, as necessary, I can get the job done. That's been my experience.

I'm not sure what to say re: "execute me that script that does the needful". That's going to hold true in any environment, Windows or Linux or whatever. If you've got third-party software that uses unique configuration persistence mechanisms, or doesn't work-and-play with the OS-provided management interfaces (Service Control Manager on Windows, systemd on Linux, etc) then you're going to have to script one-offs. Most real sysadmin work, in my opinion, involves leveraging or creating code and infrastructure to handle automating assemblages of software. Scripting is often how that's done. Configuration management tools add some formalism to the process, but it's still "glue and tape"-- albeit fancy.

Re: eBPF on Windows

#159

Post by corty »

kwdc wrote: post #147
EvanAnderson wrote: post #133

Earlier quoted context omitted.

I'd argue it's just being familiar with the tools. I'm biased, no doubt. Windows sysadmin work has paid the lion's share of my bills since the late 90s. I've been using Group Policy heavily since 1999 (during the Windows 2000 beta), so I'm used to knowing what applies when. Being familiar with which client-side extensions (CSEs) do which processing helps. The documentation for Microsoft's own functionality is reasona…

Re: rebooting is easy Full agreement. We were remotely powering on/off hundreds of machines with a single command line. Then just a web page because we needed non-IT people doing it on regular basis. We used to change wallpapers of certain groups of machines on a daily or even hourly basis due to special events. Do people really think we remotely logged into each one? Or manually remoted each one? Hmmm. Next someone…

Depends, event forwarding is quite weird and broken. Default settings delay and buffer events for quite some time so that an attacker can easily suppress unsent event buffers. Crashes are also usually missed because buffered events have not been sent in time. That can be configured down, but all the provided defaults are useless.

Also, encryption and authentication for log forwaring is bound to AD Kerberos credentials that frequently expire, leaving you without logs again.

Any old syslog client and server is far superior in all the aspects mentioned.

Re: eBPF on Windows

#160

Post by corty »

EvanAnderson wrote: post #158
corty wrote: post #157

Earlier quoted context omitted.

I didn't claim that rebooting a Windows box is impossible or hard. It is just that group policies are no complete solution for anything, they are just a small and imho weird part. Also, for a lot of things there is just no group policy you can set somewhere, so you are still in need of some "execute me that script that does the needful" in a lot of cases.

We have different experiences. Group Policy is a tool that I'm confident, in virtually any engagement, I can use to automate nearly all the goings-on of a Windows Server environment. Third-party software may not play well, but between the GPP CSEs and scripting, as necessary, I can get the job done. That's been my experience. I'm not sure what to say re: "execute me that script that does the needful". That's going to…

I think Group Policies are a very incomplete, partial solution. As you said, you usually have to combine it with a few more things to get the job done, and that is how any sysadmin job works. But: You need not only a one-off-script to make things really work.

You need a script that is idempotent, so you can execute it on all your machines and maybe do a retry or two if some are unreachable or an error happens. So the script should not only change things it is supposed to change (e.g. append a configuration line somewhere) but also check if that action is necessary or already done (e.g. that line has already been appended). Then you maybe need to restart the respective service to reread it's configuration. But of course you wouldn't want to unnecessarily restart it, since that might be disruptive or expensive, so you have to check if that configuration has been changed or not before restarting. Then handle automatic application for machines that are currently offline, have just been installed or need a refresh. Add in a some templateing and parameters, different groups, logging success/failure and you are at quite a complex script.

Or rather, a script that no-one should write, because it is exactly what configuration management is supposed to do. If you are writing all that by hand for each one-off, you are doing it wrong because you are reinventing the wheel, and usually badly. If you aren't doing all that, you are missing important parts. So imho configuration management like puppet, salt, chef, … is table stakes for any kind of sysadmin work. I'm not familiar with Windows DSC, but I find it strange that you dismiss it as pandering to the Linux crowd.

Post reply on HN