2 év 2 hónap óta
Over on the
Software Freedom Conservancy blog, Policy Fellow and Hacker-in-Residence Bradley M. Kuhn
analyzes the
recent changes to Red Hat Enterprise Linux (RHEL) source availability in light of the GPL. It contains some interesting information about two alleged GPL violations that came about because the company's business model is structured in a way that brings it too close to non-compliance with the license, he said:
Perhaps the biggest problem with a murky business model that skirts the line of GPL compliance is that violations can and do happen — since even a minor deviation from the business model clearly violates the GPL agreements. Pre-IBM Red Hat deserves a certain amount of credit, as SFC is aware of only two documented incidents of GPL violations that have occurred since 2006 regarding the RHEL business model. We've decided to share some general details of these violations for the purpose of explaining where this business model can so easily cross the line.
[...] In another violation incident, we learned that Red Hat, in a specific non-USA country, was requiring that any customer who lowered the number of RHEL machines under service contract with Red Hat sign an additional agreement. This additional agreement promised that the customer had deleted every copy of RHEL in their entire organization other than the copies of RHEL that were currently contracted for service with Red Hat. Again, this is a "further restriction". The GPL agreements give everyone the unfettered right to make and keep as many copies of the software as they like, and a distributor of GPL'd software may not require a user to attest that they've deleted these legitimate, licensed copies of third-party-licensed software under the GPL. SFC informed Red Hat's legal department of this violation, and we were assured that this additional agreement would no longer be presented to any Red Hat customers in the future.
jake
2 év 2 hónap óta
Security updates have been issued by Debian (asterisk, lua5.3, and trafficserver), Fedora (tang and trafficserver), Oracle (.NET 7.0, c-ares, firefox, openssl, postgresql, python3, texlive, and thunderbird), Red Hat (python27:2.7 and python39:3.9 and python39-devel:3.9), Scientific Linux (c-ares), Slackware (cups), SUSE (cups, dav1d, google-cloud-sap-agent, java-1_8_0-openjdk, libX11, openssl-1_0_0, openssl-1_1, openssl-3, openvswitch, and python-sqlparse), and Ubuntu (cups, dotnet6, dotnet7, and openssl).
jake
2 év 2 hónap óta
Security updates have been issued by Debian (avahi, hsqldb, hsqldb1.8.0, minidlna, trafficserver, and xmltooling), Oracle (.NET 6.0, .NET 7.0, 18, c-ares, firefox, kernel, less, libtiff, libvirt, python, python3.11, texlive, and thunderbird), Red Hat (c-ares, kernel, kernel-rt, kpatch-patch, less, libtiff, libvirt, openssl, and postgresql), Slackware (bind and kernel), SUSE (bluez, curl, geoipupdate, kernel, netty, netty-tcnative, ntp, open-vm-tools, php8, python-reportlab, rustup, Salt, salt, terraform-provider-aws, terraform-provider-null, and webkit2gtk3), and Ubuntu (bind9, linux-aws, linux-azure, linux-bluefield, linux-gcp, linux-gke,
linux-gkeop, linux-ibm, linux-kvm, linux-oracle, linux-raspi, linux-azure, linux-gcp, linux-ibm, linux-kvm, linux-oracle, and linux-ibm).
jake
2 év 2 hónap óta
Security updates have been issued by Debian (libfastjson, libx11, opensc, python-mechanize, and wordpress), SUSE (salt and terraform-provider-helm), and Ubuntu (firefox, libx11, pngcheck, python-werkzeug, ruby3.1, and vlc).
corbet
2 év 2 hónap óta
A major rewrite of
pfsync(4), the state table synchronization tool for redundant
pf(4) setups is in the works.
In a recent message to tech@, David Gwynne (dlg@) describes the multi-year process behind the diff contained in the message,
moving pf forward has been a real struggle, and pfsync has been a
constant source of pain. we have been papering over the problems
for a while now, but it reached the point that it needed a fundamental
restructure, which is what this diff is.
i started rewriting pfsync (again) during h2k22 last year, and it's
only been in the last couple of months that i got all the existing
functionality working again, and it's only been the last three weeks in
particular that it's been solid. this is the first time since about
openbsd 6.9 that i've been able to upgrade my production firewalls
without them falling over.
which means there may still be rough edges, but testing by brave souls is encouraged. There are huge potential performance gains to be found if this works out right.
You can read the entire message (with the diff) here, or just take in the rest of the text after the fold.
Read more…
2 év 2 hónap óta
The real-time and scheduling micro-conference joins these two intrinsically connected communities to discuss the next steps together.
Over the past decade, many parts of PREEMPT_RT have been included in the official Linux codebase. Examples include real-time mutexes, high-resolution timers, lockdep, ftrace, RCU_PREEMPT, threaded interrupt handlers, and more. The number of patches that need integration has been significantly reduced, and the rest is mature enough to make their way into mainline Linux.
The scheduler is at the core of Linux performance. With different topologies and workloads, giving the user the best experience possible is challenging, from low latency to high throughput and from small power-constrained devices to HPC, where CPU isolation is critical.
The following accomplishments have been made as a result of last year’s micro-conference:
Ideas of topics to be discussed include (but are not limited to):
- Improve responsiveness for CFS tasks – e.g., latency-nice patch
- The new EEVDF scheduler proposal
- Impact of new topology on CFS including hybrid or heterogeneous system
- Taking into account task profile with IPCC or uclamp
- Improvements in CPU Isolation
- The status of PREEMPT_RT
- Locking improvements – e.g., proxy execution
- Improvements on SCHED_DEADLINE
- Tooling for debugging scheduling and real-time
It is fine if you have a new topic that is not on the list. People are encouraged to submit any topic related to real-time and scheduling.
Please consider that the goal is to discuss open problems, preferably with patch set submissions already in discussion on LKML. The presentations are very short, and the main portion of the time should be given to the debate – thus, the importance of having an open and relevant problem, with people in the community engaged in the solution.
Submissions are made via LPC submission systems, selecting Track Real-time and Scheduling MC