The email doesn't seem to be going through. I am trying to send it to jaboutboul@msft.com but am getting this message "There was a temporary problem delivering your message to jaboutboul@msft.com. Gmail will retry for 46 more hours. You'll be notified if the delivery fails permanently." Could you provide me with an alternative email address?
Really? Any numbers? Cause I aleays comented that for allnthe companies I've worked, even the ones thatnloterally developed proprietary desktop software for Linux and thus had RedHat on all workstations... they never sent a single dime to RedHat.
Were they actually running RedHat Enterprise Linux, or was it something like Fedora or CentOS? CentOS was basically RHEL with the branding stripped, but I don't believe they had any kind of support agreements.
For general compute yes, that is correct. A good chunk of the work that we do is making sure that that HostOS plays nicely with Linux guests and vice-versa.
The Azure infrastructure, as I assume most hyperscale infrastructures are, is hybrid depending on the service. Service owners typically have a fair amount of liberty in deciding how they architect their service and what they use underneath it.
Hey everyone. We put in lots of efforts to make sure that Linux runs really well on Azure and that you have a great experience. Glad this got some traction and glad to answer any questions.
Is the hypervisor of the hosts also Linux based, or Hyper-V? I recall seeing Github Actions errors the other day that suggested a hyper-v failure even though all of our stuff is linux.
Is there a paved path for bringing up NixOS on Azure VMs? I haven’t looked hard yet, but I’m about to so if this is a known thing I’d be grateful for any pointers.
My experience was that the Linux VM agents used to cause frequent problems but in the time I was using Azure I did see great improvements in them, kudos for that. I'd like to see less churn and breaking changes in agents and in Azure in general, but that seems to be a problem common to all major clouds.
Thanks for posting that. This post had nothing to do with Satya nor did he or anyone aside from myself and a couple other team mates see it before posting.
I really fail to see how interacting with the community to see how we feel could possibly be negative. Sure theyre doing it to push their product, but theyre also doing it to see where they need to improve.
The RHEL sources aren't freely available. They are only provided to RHEL customers. Red Hat strongly discourages said customers from leaking the sources to Rocky, so Rocky won't say anything that might reveal where they got the sources. [1]
The GPL only requires that you provide sources to those to whom you distribute binaries, not to the general public.
[1] Red Hat can probably figure it out anyway. For example, they could slightly alter the sources and/or assets provided to each customer in a way that doesn't affect the functionality, and see which version turns up in Rocky's repository. But the leaky customer might too big for Red Hat to punish. Government maybe.
Just want to note that there is a lot of non GPL software in RHEL. e.g. Apache licensed or MIT. For which they do not have an obligation to provide the sources.
I already pointed that out multiple times to Rocky Linux staff. They have no answer to this. The whole concept of Rocky is a big bet, that Red Hat won't pull the sources of non-GPL binaries e.g. in cloud instances and other public accessable places, where Rocky is currently fetching their sources from.
If you choose not to participate in this gamble, then this distro may not be suitable for you.
> The GPL only requires that you provide sources to those to whom you distribute binaries, not to the general public.
Interesting. I looked at Wikipedia GPL page and saw this: "The GNU General Public License (GNU GPL or simply GPL) is a series of widely used free software licenses or copyleft that guarantee end users the four freedoms to run, study, share, and modify the software.[7] "
So any user of GPL covered software can share it with anyone. Right? Can any RHEL user share sources to Rocky? And to public?
I think this is an interesting question in general because GPL has also this clause
> You may not impose any further restrictions on the recipients' exercise of the rights granted herein
So I think it could be debatable if RHELs policy represents a restriction. Overall I feel this part of GPL has not been explored all that thoroughly and I feel it raises questions beyond this RHEL case. For example FSFs GPL FAQ states:
> For instance, you can accept a contract to develop changes and agree not to release your changes until the client says ok. This is permitted because in this case no GPL-covered code is being distributed under an NDA
I don't understand how that is not conflicting here; wouldn't your client be distributing the code to be modified to you, and that should be covered by GPL? And as such the NDA would represent additional restriction?
I suppose there could be a special case where the client would ask modifications for a publicly available sources and as such would not be distributing the code themselves, but I feel that can not be considered typical or general case.
Similar interesting case would be employees receiving copies of company internal forks of GPL code. Should employees have right to redistribute the code in accordance to GPL terms without threat of getting punished?
AFAIK mere exchange of code between employer and employee is not considered "distribution" for the purpose of the GPL. They are part of the same company, working on the same project. Similar relationships exist between client and contractor, client and lawyer, etc.
> The function of the contractor in such cases is nearly identical to that of an employee; however, because the contractor is not an employee, providing a copy of software to the contractor could be considered distribution. This is one of the thornier areas of GPLv2 interpretation, and it is discussed in more detail below
> A full discussion of the tenets of international copyright law bearing upon this issue is beyond the scope of this article, but it seems likely the question would have different answers outside the U.S [...] Therefore, the triggers for copyleft obligations, based on activity outside the U.S., may have a lower threshold than in the U.S.
They can, and they do, so the community eventually gets the sources. But Red Hat has every right to terminate their paid support contract with any customer who shares.
> Wouldn’t rebuilding from the RHEL sources be the easier approach?
Yes, if you can get the sources, of course. RH tells that they'll stop doing business with you if you share the source code you get from RHEL, which is Free and/or Open Source software.
> Also Alma doesn’t mirror Stream, they pull sources from several unencumbered places including stream.
Thanks for clarification. AFAIK they target versions of Stream and ABI of RHEL, but I learnt more today.
