Nothing. This isn't something that is even tracked. AI usage is obviously encouraged but HR has far better things to do than go gather this kind of data.
Internally, depending on what product is being worked on teams will have different development flows and different usage points of AI. For things like VSCode, teams have freedom on how they use it completely.
I had a brief look at the docker image, and it's pretty clearly a repackaged version of OpenConnect. Debian's copyright linked to from https://packages.debian.org/sid/openconnect says it's primarily LGPL but with a plethora of other licences like the GPL.
Since there is GPL they are required to make some source available, and if they modified it they are required by the LGPL to make their modifications available. They have extended it by adding Microsoft's authentication mechanisms, but perhaps that is just a DDL mixin, and I could well believe / forgive them not being aware of the other licences.
What is not so easy to forgive is them not acknowledging the open source they used in any way. Instead they slapped as pretty standard Microsoft Licence claiming it's all theipr own work, similar to this one: https://support.microsoft.com/en-us/office/microsoft-softwar...
Scant on details, sure, but hard to parse, not really.
The problem is folks this thread seemingly taking a interlocutory approach that can be summarized as, "That which is not explicitly denied can be freely assumed to be true."
(Then throw on top of that, "Depending on how committed you are to your grandstanding, that which is explicitly denied can be conveniently ignored.")
I'm not an engineer, and no one should be getting the impression that anyone else is under the impression that HN is the place to seek an authoritative disposition about this. It is, though, an acceptable channel for the sort of collegial and informal heads-up that this is (and which is all that this is).
Correct, that was my intent - Ben isn't the proper channel as he is just an engineer responding to comments here. Stuff like this is serious and so should be escalated.
The guidance you offer here remains as necessary and is as appreciated now as it was the first time. Rest assured that I am capable and well-informed about how to proceed with these sort of things. Warm regards.
I think it would be interesting for people if your comment was a little more specific about what the issue is. Is this about ffmpeg as raised here: https://github.com/electron/electron/issues/34236 ?
QNX is heavily used in industries where functional safety or particular high assurance models are required.
Sure FreeRTOS has a SafeRTOS mode, but its not sufficiently functional for a modern ADAS stack or complex robotics systems. QNX is used in all major automotive companies around the world for a reason, and a crucial part of NVIDIA's DriveOS stack.
QNX is in a space with few competitors. FreeRTOS or ThreadX are designed to provide microcontrollers with scheduling and memory management functionality. They don't depend on fancy things like MMUs or provide frameworks for networking or file systems out for the box. The flipside is that you can compile them down to maybe 30kB of machine code.
QNX is designed for more powerful and featureful hardware to drive a software stack with true process isolation and generally provide the bells and whistles of general purpose OS on top of a hard realtime core. It can run complex GUIs without sacrificing its real time capabilities. Not many competitors live in that particular space.
“Of course, the contents of the hard drive might incriminate Rawls, but the contents of the hard drive are not considered testimony for Fifth Amendment purposes.”
"Microsoft made both changes in response to antitrust concerns from the European Commission. Led by Symantec, the world's largest antivirus software maker, security companies had publicly criticised Microsoft over both Vista features and also talked to European competition officials about their gripes."
Perhaps reactive, but there were definitely conversations between EU and MS.
As someone that watched the video (and directly worked on this stuff during my time at MS), I think Marcus has no idea on how the OS vendors relationships work with governments. He misses the fact that if Windows releases user-level APIs that provide similar functionality, it would break existing functionality and force a migration.
For the example he uses patch guard, existing functionality did not break anywhere as significant as say would evicting drivers from the kernel.
Windows does have the ability to have sovereign builds (and has had this since 2016?), but the capability wasn't present when the decision was made (in 2006). Windows build is complex and tightly coupled with performance testing, telemetry collection, etc and at the time this decision was made, not feasible to do.
Reversing a change from 2006 would likely bring anti-trust action from the remainder of the world immediately, as that change from 2006 is relied on by everyone else globally today.
The EUs stance isn't bad either, as MS has a competitor in this space that also relies on a kernel driver (MDATP does use a kernel driver) and it is unlikely MS would remove its own competitor from the kernel (at least this item was not discussed during my time at MS and I was in the security space of Windows).
As someone that worked at MS, on a team that worked directly on this issue (among other things) some years ago, MS did figure out better solutions and did discuss it with industry.
Kaspersky was running an SSL/TLS Proxy in the kernel IIRC and didn't want to have to move it elsewhere due to the fact it would require them to rework their product quite a bit.
The solutions MS (we) proposed were agnostic and overall better, the anti-malware industry simply doesn't want to make the changes as these things do impose technical work on existing products.
No worries. That wasn't at all evident from the above complaint.
Was the drive for this industry forum coming from dealing with the EU, or was it more from MS trying to make things better without needing the prodding?
Well Microsoft did not publicly commit to using the same APIs, and no privileged access, for its own antivirus products. That's why the EU said no way; not because kernel access was revoked.
Yes, but then of course Microsoft is being obligated to open part of kernelspace to competitors, which is arguably "OK" from a competitive regulation perspective, but that then places a special burden on competitors to maintain code hygiene given the potential for crashes. It makes CrowdStrike's negligence all the more unacceptable.
I believe what philistine is suggesting is that Microsoft could have implemented their own security offering using a safer alternative like eBPF, and then opened that interface to competitors as well.
I think that would have been a proactive approach. That said, I'm not entirely convinced that the EU was right to place the restriction in the first place.
The article you shared says that Kaspersky filed a complaint, but I didn't see a clear statement there about what the outcome was. I do now see other reputable sources reporting that an agreement was reached in 2009 where Microsoft promised to allow vendors the same access to the kernel its security software had [0].
I think a proactive approach might have been for Microsoft to provide safer interfaces with the kernel, and then use those in its own security offerings.
That said, it does sound like EU competition regulation was a contributing factor here, and I think the EU is wrong on this one and that an OS vendor should not be required to provide unrestricted kernel access to allow security software vendors to compete.
Mostly unrelated, it seems somewhat interesting that this was Kaspersky insisting on kernel access... The US government seems convinced they are compromised.
So the grandparent poster has a fundamental misunderstanding of how Windows works, and why CrowdStrike has a kernel driver in the first place.
Microsoft has long desired to kick AV vendors out of kernel space and has even attempted to do so prior, however because of its dominant position in the market, it is unable to do so. I was at MS when an iteration of this effort was underway, and the EU said no.
See, Windows is a highly regulated OS today, and making a change like kicking out AV vendors from the kernel runs afoul of antitrust laws.
Microsoft also has ELAM: https://learn.microsoft.com/en-us/windows-hardware/drivers/i... which is a rootkit / bootkit defensive mechanism. A defect in the definition files (as noted in the twitter thread) is what caused the crash in an ELAM driver. CrowdStrike obviously was not following the required process for ELAM drivers.
All good points, I might have been slightly over-impassioned and under-informed in my original rant (though still salty at Microsoft's assault on the usability of Windows).
My understanding was that CrowdStrike breaking on Debian was actually the motivation for them moving to user-space on Linux. I'm surprised that, assuming they have the capability to do so, they haven't done the same on Windows.
Internally, depending on what product is being worked on teams will have different development flows and different usage points of AI. For things like VSCode, teams have freedom on how they use it completely.