nullindividual

It's not a script, which would be a .ps1 file, but from the sounds of it the actual script block/PowerShell function which isn't governed by the signing policy. It could simply be an Invoke-WebRequest to download that executable indicated in the article.

> I feel like that's a great way to make everyone hate you

Maybe. But at least you'd know what the discussion is about. Or ask for notes. I can't say I've been in a meeting where someone asking questions was frowned upon.

You're on the right track.

You already have your solution. You typed it out.

You ask questions. You stop them and circle back to the overview and context. Ask them about the high level. Ask them for the pretty pictures PPT.

If they deviate from what you need, stop them politely and put them back on track with the excuse of "it will help me understand this better so I can provide a solution".

The author is mistaken to believe that the features used by EDR moving out of the kernel will impact any other kernel driver implemented for non-EDR reasons.

N100 and fans? What fans?

https://www.servethehome.com/fanless-intel-n100-firewall-and...

The advantage over Arm is that it is x86-64.

Welcome to Microsoft Loop.

All major browsers now implement the ability to use a browser-defined resolver.

IT is a profession that attracts that type of personality. From autism to assholes. "Technically correct" is the best kind of correct for technology. Technology is an often "exacting" science in the eyes of those individuals even when it isn't exacting, it's just their strongly held preference or belief.

If you go into the profession, you will not be able to avoid it in a corporate environment. If it isn't something you feel you could handle and burn your way through, consider small teams, non-IT companies, or consulting/running your own business.

But these kind of people exist in every profession as do autistic individuals and assholes. It's part of being an adult and improving your interpersonal skills.

There have been many lone wolves who have created great things in our world. Don't discount them. You would not be "better off".

How String theorists lied to us - https://www.youtube.com/watch?v=kya_LXa_y1E

Check out Terry Davis' TempleOS. It's not named "The OS", but it fits with the numerous paragraphs included with this post.

The golden age of flight splattered the blood of professionals and innocents alike to write those regulations.

Flight is not for cowboys.

That’s less than a year’s salary for most Seattle PD officers.

> Customers get increased integration with Cloudflare Email Security and Zero Trust through expanded partnership with CrowdStrike

About that Zero Trust...

The Spider engineers weren't the ones to port BSD utilities. That was Microsoft.

That already exists! It's the HKCU.

They licensed Spider Software's TCP/IP stack. And you have no knowledge that Spider leveraged BSD code. You're probably too young to remember, but there were many vendors making TCP/IP stacks back in those days. Some based on pre-existing stacks, others from the ground up.

https://ia904500.us.archive.org/view_archive.php?archive=/23...

TCPIP.SYS is the TCP/IP stack in Windows.

I'm unsure as to why you're making unsubstantiated claims and sticking with them. You have zero proof that the claims you're making are true. I'd love to have the source for Spider's TCP or at least have a contact that worked on the stack to ask, it's interesting history. I don't care one way or another, it was a very temporary stack that didn't make it into 3.5 where the entire stack architecture changed (no longer based on SysV STREAMS).

The version picker is in the ToC on the upper left.

> Are you pretty sure about that?

NT OS/2 started development in 1988 and NT Win32 in 1990.

Build 297 of NT 3.1 contains a TCP/IP stack dated June 25th, 1992. This is not the earliest public build.

You're not seeing "pure" FS performance. You're seeing all of the abstractions between you and the file system.

To get more of the abstractions out of the way, you want DevDrive. And don't use Explorer.exe as a test bed which has shims and hooks and god knows what else.

Raymond Chen says "Not true, but true enough" [0]. But to your original claim of more advanced than NT... nah.

[0] https://web.archive.org/web/20111110161740/http://blogs.msdn...

[Extra] https://devblogs.microsoft.com/oldnewthing/20130208-00/?p=53...

Linux wasn't a thing by the time NT was in development. Hell, the GPL itself wasn't a thing when NT began development!

What happens if you have an extensible app, say Microsoft Office, which enumerated it's own subkeys to discover 3rd party plugins?

What if an app provides COM services and needs to write that to a centralized location that is enumerated to discover available COM services?

What if your app happens to be a god-awful HP Print Center app with it's own print drivers and a Windows Service, where it needs to write to a central location that is enumerated for device drivers and Windows Services?

It was introduced with Windows PowerShell 1.0[0]. A text editor would need to directly support managing the registry, but you can read/write/search/do terminally-stuff to the registry via PowerShell.

The term we're looking for is a PSProvider of which there are many. There's even a PSProvider for SharePoint Online[2].

[0] https://devblogs.microsoft.com/scripting/use-the-powershell-...

[1] https://learn.microsoft.com/en-us/powershell/module/microsof...

[2] https://github.com/pnp/powershell/blob/96d00aa60379d8e3310f7...

The registry was capable of being compacted, negating the need to defragment it. This was done via the standard Windows Backup utility provided OOTB.

As for performance, the registry was mapped in paged pool memory[0]; only sections in-use needed to be mapped. Other hives were volatile and never persisted to disk. When data is added to the registry, the paged pool expands to accommodate. Maximum registry size is based off of installed memory, up to a limit.

Registry subkeys are organized alphabetically in an internal list; searches are binary searches rather than using an index. Searches begin in the middle of the list and go up or down based upon the alphabetical value being searched for (so start at 50% -> up/down, split remaining list 50%, up/down -> repeat until found).

You can find more info in Chapter 4 of Windows Internals 4th Edition.

Needless to say, none of the concerns you presented were valid back in the dark days.

[0] https://learn.microsoft.com/en-us/windows/win32/sysinfo/regi...

That's an assumption that neither of us are qualified to make.

BSD wasn't the only TCP/IP stack on the market[0].

[0] https://en.wikipedia.org/wiki/Internet_protocol_suite#Adopti...

Windows is no different. Next time you're in front of Terminal, try:

    cd HKCU:\SOFTWARE

You're now browsing the registry and can use terminal commands.

> Windows/386 are hypervisors that run VMs under hardware-assisted virtualisation.

Not really. There was no Ring -1 (hypervisor), no hardware-assisted virtualization as we use the term today. On Windows/386, it ran in Ring 0.

Virtual 8086 mode was leveraged via the NTVDM, shipping with the first release of NT.

HKLM and HKCU have specific ACLs. It wouldn't make sense to have _two_ user-modifiable registry hives and ditto for machine.

Like I said, the userland applications (ping, tracert, etc.) were ports from BSD, probably nearly 1:1 copies.

The TCP & IP stacks were written by Microsoft in NT 3.5.

What Spider Software used (again, used by Microsoft in NT 3.1 due to time pressures) may have originated from BSD, but we don't know.

You can browse the NT4 source code TCP/IP stack. Just search GitHub.

Let's not forget TerraServer[0] which was in production prior to the acquisition of Hotmail (let alone the conversion from FreeBSD).

[0] https://www.microsoft.com/en-us/research/publication/the-mic...