jborean93

Plain old reflection that just works (why should it not?)

I definitely don't fully understand the landscape, so I could certainly be wrong, but I assumed that normal reflection didn't work in AOT because after trimming that method may or may not be there. If it was never called in a normal way then the compiler doesn't know that `Console.WriteLine` was being used as `GetMethod` may have a runtime value as a string rather than a constant value known at compile time. If the compiler didn't know it was being called then it will be trimmed out of the final binary whereas with `UnsafeAccessorAttribute` it provides the information required to not trim it.

Edit: I tried the following https://sharplab.io/#v2:D4AQTAjAsAUCAMACEEB0AlApgMwDaYGMAXAS... and it fails when I provide the type and method for Console.WriteLine as arguments. If I was to add `typeof(Console).GetMethod(args[1], [typeof(string)])!.Invoke(null, ["dummy"]);` to it before the `Type.GetType` call it seems to be enough to not trim out the `Console` type and the `WriteLine` method. The compiler seems to at least be smart that way.

It works through the new UnsafeAccessorAttribute [1]. This provides the information needed for AOT to know what needs to be in the final binary and not trimmed. It also removes the lookup overhead associated with normal reflection which is very nice.

[1] https://learn.microsoft.com/en-us/dotnet/api/system.runtime....

This only works if credential guard has implemented a way to build a subsequent token/value from that secret. For things like basic auth the secret would need to eventually hit the userland process that needs it in some shape or form to then embed it in the HTTP payload which is plaintext.

*nix fanboys were totes fine with wget and ls being an aliases in PowerShell for years but when they found out what PS is coming to Linux they made a biggest stink

The curl and wget aliases don’t exist on the PowerShell 7 version which is the cross platform one. Only the old powershell.exe builtin to Windows has these aliases and it’s worse today because curl.exe is builtin and the curl alias takes priority when you run just curl.

The runas command doesn’t elevate just runs as another user. This is a console executable that drives UAC and also provides a way to capture the stdout/stderr elevated process which isn’t natively possible today without your own wrapper.

Looks like Microsoft is trying to stop internal products from using MSI in favour of MSIX packages. MSIX is nice for interactive applications but has a few issues with dealing with system wide installations and automation scenarios that I doubt the PowerShell team will be able to solve by the time of the 7.7 release.

I don't mind NRT but I hate dealing with C# projects that haven't set < Nullable>Enable</Nullable> in their csproj. It's not perfect because I know at runtime it can still be nullable but it's nice when the compiler does most of the checks for you.

They didn't just write the PEP, they implemented them.

That's the thing, you don't have to :) While I think uv is a great tool and highly recommend it, you are more than welcome to use any of the other build backends or package management tools that fit your workstyle. By having these packaging PEPs (amongst) others, the ecosystem has been able to try out different approaches and most likely over time will consolidate on specific ones that work better than the others.

They refused to invest in packaging to the extent that a separate company (astral) had to do it for them

uv didn't just happen in a vacuum, there has been lots of investment in the Python packaging ecosystem that has enabled it (and other tools) to try and improve the shortcomings of Python and packaging.

There's PEP 518 [1] for build requirements, PEP 600 [2] for manylinux wheels, PEP 621 [3] for pyproject.toml, PEP 656 [4] for musl wheels platform identifiers, PEP 723 [5] for inline script metadata.

Without all this uv wouldn't be a thing and we would be stuck with pip and setuptools or a bunch of more bandaid hacks on top making the whole thing brittle.

[1] https://peps.python.org/pep-0518/ [2] https://peps.python.org/pep-0600/ [3] https://peps.python.org/pep-0621/ [4] https://peps.python.org/pep-0654/ [5] https://peps.python.org/pep-0723/

There shouldn't be any difference between those two values. I'm not saying you are wrong and it didn't break but it's definitely surprising a parser would choke on that vs YAML itself being the problem.

Don't get me wrong I can empathise with whitespace formatting being annoying and having both forms be valid just adds confusion it's just surprising to see this was the problem.

& has no special behaviour in strings, backticks and $ on the other hand do. For example "&Some String&" and '&Some String&' are all the literal value `&Some String&`. Backticks and $ are special in double quoted strings as they are the escape character and variable reference chars respectively.

per-minute is really just a way to express the cost in a human friendly name. Doing per-hour, per-second, per-day could all result in the same total value just at a different number. If anything per-minute is better than per-hour as you won't be charge for minutes you don't use.

Maybe to you, I enjoy the fact that

I don't knock it out of my head by having the wire catching on something Dealing with the cable and having to pack it back up when I'm done It auto connects to both my phone and laptop 99% of the time It easily swap between the 2 as I change the focus

Now they aren't perfect, charging can be a bit fiddly over time but they certainly are nicer than the normal headphones. Maybe you just aren't the target audience but clearly they are popular enough for most people.

This seems a bit pedantic, while you may be correct (I honestly don't know what standard this is referring to) the UTF-8 BOM is a thing that some tools do know about. Even then in the context of OP's question the BOM with UTF-8 isn't the specific problem but rather how the shebang interpreter reads the actual ASCII byte sequences so a UTF-16 with a BOM "text" file would also fail.

That's the realm side which should be upper case. The comment reference was for hostname themselves which I've always just done as lower case and have never seen a reason to make it upper case. The krb5.conf has a [domain_realm] section which can map a DNS name/suffix to the actual realm

    [domain_realm]
    .domain.com = DOMAIN.COM
    domain.com = DOMAIN.COM

The problem I have with using a gMSA outside of Windows is you need a Kerberos principal and credential for that principal in the first place to allow retrieving the gMSA details. Why not just use that principal and avoid adding this next step.

It would be great if Linux had a mechanism where the host itself could act as the principal to retrieve the gMSA like on Windows but the GSSAPI worker model just works differently there and runs in process. A similar problem exists for using Kerberos FAST/armouring where Windows uses the hosts' ticket to wrap the client request but on Linux there is no privileged worker process that protects this ticket so the client needs to have full access to it.

The closest thing I've seen is gssproxy [1] which tries to solve the problem where you want to protect host secrets from a client actually seeing the secrets but can still use them but I've not seen anything from there to support gMSAs for armouring for client TGT requests.

[1] https://github.com/gssapi/gssproxy

The subsystem in question would be the one to handle the logic for the syscall. So the POSIX subsystem would use the reparse data buffer as needed. It's just that the Win32 subsystem added its own symlink one in Vista/2008.

This is all a guess, the POSIX subsystems were a bit before my time and I've never actually used them. I just know how symlinks work on Windows/NTFS and when they were added.

No idea if the POSIX subsystem used NTFS or some other filesystem but if it was NTFS it probably just used the same reparse data buffer. It's just that Windows only added a symlink buffer structure in Vista/2008. You can manually use the same data buffer in older Windows versions it just won't know what to do with them just like all the other reparse data structures.

It had junction points and hard links but symbolic links were added in Vista/Server 2008.

Core biggest feature is running on Linux

There are so many features that .Net 5+ brings to the table. Even if features aren’t important the performance improvements you get with the newer versions should be enough to justify moving to it.

I agree the support side is annoying but honestly the support side is really just “security” fixes with security being a very hard thing to describe here and gives MS a lot of wiggle room to not actually support it.

They call them pico processes and have documented them quite well [1]. The pico processes has a userland and kernel component and is quite interesting from a technical perspective.

[1] https://learn.microsoft.com/en-au/archive/blogs/wsl/pico-pro...

Yep it’s been great to see the sites that try and track me vs them just doing it without me knowing.

This only works tor RSA keys and I believe ciphers that do not have forward secrecy. Quic is TLS 1.3 and all the ciphers in that protocol do forward secrecy so cannot be decrypted in this way. You’ll have to use a tool that provides the TLS session info through the SSLKEYLOGFILE format.

How does that refute what the parent comment was saying? Sounds like you are agreeing that the problem is not the technology but the people and processes in place.

And ssh is a binary so isn’t fully shell related :)

WSL1 used a concept called a pico process [1] and the pico driver that is associated with the process is forwarded the syscalls to translate to the required NT APIs. WSL2 is a VM running through Hyper-V but integrated in a way that mostly looks like a normal process. It was introduced to improve filesystem performance (on the Linux mounts) and avoid having to translate and maintain the syscalls required by Linux [2]. The tech behind WSL1 is quite fun but WSL2 certainly has better compatibility and aside from FS performance between Linux and Windows is mostly a positive.

[1] https://learn.microsoft.com/en-us/archive/blogs/wsl/pico-pro... [2] https://devblogs.microsoft.com/commandline/announcing-wsl-2/

Extended support ended in Jan 2020 and the paid ESU support ended in Jan 2023 [1]. Are you sure those updates aren't just defender/AV definition updates rather than actual OS updates?

[1] https://learn.microsoft.com/en-us/lifecycle/faq/extended-sec...

Sure I can agree with this (if it's actually viable to do). My reply was mostly to try and explain that the issue wasn't due to a driver update but rather an existing driver failing to work with a new file it was using hence why the last known good configuration feature didn't work.

having Windows roll back to the last known version of a driver/extension after a failed boot (or several)

One of the problems with CrowdStrike was the update was a definition/config file that was pushed out by CrowdStrike. There was no driver update and the BSOD was caused by the existing driver failing to parse/load the new file pushed out. This means there was no last known good state to rollback to in terms of driver updates.

Granted I still agree that MS can hopefully improve things to avoid this problem in the future but this isn't a simple problem that the OS can guard from short of stopping 3rd party kernel drivers.