Linux

AI is here to stay, and understanding how it works under the hood can mean the difference between frustration and genuinely useful results. This article covers LLM fundamentals, effective prompting, and a structured agentic workflow that puts you in control. Переглянути повний текст

This month in Linux Voice and Elvie. Переглянути повний текст

Exploiting Layer 4 protocol handshakes and the resource limits of Layer 7. Переглянути повний текст

This month, we explore the top FOSS, including a popular BitTorrent Client, a modern 8-bit game, and a slick web browser. Переглянути повний текст

There are several main categories into which kernel releases may fall: Prepatch Prepatch or "RC" kernels are mainline kernel pre-releases that are mostly aimed at other kernel developers and Linux enthusiasts. They must be compiled from source and usually contain new features that must be tested before they can be put into a stable release. Prepatch kernels are maintained and released by Linus Torvalds. Mainline Mainline tree is maintained by Linus Torvalds. It's the tree where all new features are introduced and where all the exciting new development happens. New mainline kernels are released every 9-10 weeks. Stable After each mainline kernel is released, it is considered "stable." Any bug fixes for a stable kernel are backported from the mainline tree and applied by a designated stable kernel maintainer. There are usually only a few bugfix kernel releases until next mainline kernel becomes available -- unless it is designated a "longterm maintenance kernel." Stable kernel updates are released on as-needed basis, usually once a week. Longterm There are usually several "longterm maintenance" kernel releases provided for the purposes of backporting bugfixes for older kernel trees. Only important bugfixes are applied to such kernels and they don't usually see very frequent releases, especially for older trees. Longterm release kernels Version Maintainer Released Projected EOL 6.18 Greg Kroah-Hartman & Sasha Levin 2025-11-30 Dec, 2028 6.12 Greg Kroah-Hartman & Sasha Levin 2024-11-17 Dec, 2028 6.6 Greg Kroah-Hartman & Sasha Levin 2023-10-29 Dec, 2027 6.1 Greg Kroah-Hartman & Sasha Levin 2022-12-11 Dec, 2027 5.15 Greg Kroah-Hartman & Sasha Levin 2021-10-31 Dec, 2026 5.10 Greg Kroah-Hartman & Sasha Levin 2020-12-13 Dec, 2026 Distribution kernels Many Linux distributions provide their own "longterm maintenance" kernels that may or may not be based on those maintained by kernel developers. These kernel releases are not hosted at kernel.org and kernel developers can provide no support for them. It is easy to tell if you are running a distribution kernel. Unless you downloaded, compiled and installed your own version of kernel from kernel.org, you are running a distribution kernel. To find out the version of your kernel, run uname -r: # uname -r 5.6.19-300.fc32.x86_64 If you see anything at all after the dash, you are running a distribution kernel. Please use the support channels offered by your distribution vendor to obtain kernel support. Releases FAQ Here are some questions we routinely receive about kernel release versions. See also the main "FAQ" section for some other topics. When is the next mainline kernel version going to be released? Linux kernel follows a simple release cadence: after each mainline release, there is a 2-week "merge window" period during which new major features are introduced into the kernel after the merge window closes, there is a 7-week bugfix and stabilization period with weekly "release candidate" snapshots rc7 is usually the last release candidate, though occasionally there may be additional rc8+ releases if that is deemed necessary So, to find the approximate date of the next mainline kernel release, take the date of the previous mainline release and add 9-10 weeks. You can also subscribe to the releases calendar that forecasts key development dates for the upcoming kernels: https://www.kernel.org/releases-calendar.ics What is the next longterm release going to be? Longterm kernels are picked based on various factors -- major new features, popular commercial distribution needs, device manufacturer demand, maintainer workload and availability, etc. You can roughly estimate when the new longterm version will become available based on how much time has elapsed since the last longterm version was chosen. Why are some longterm versions supported longer than others? The "projected EOL" dates are not set in stone. Each new longterm kernel usually starts with only a 2-year projected EOL that can be extended further if there is enough interest from the industry at large to help support it for a longer period of time. Does the major version number (4.x vs 5.x) mean anything? No. The major version number is incremented when the number after the dot starts looking "too big." There is literally no other reason. Does the odd-even number still mean anything? A long time ago Linux used a system where odd numbers after the first dot indicated pre-release, development kernels (e.g. 2.1, 2.3, 2.5). This scheme was abandoned after the release of kernel 2.6 and these days pre-release kernels are indicated with "-rc". nПереглянути повний текст статті

The Linux kernel community operates a Code of Conduct based on the Contributor Covenant Code of Conduct with a Linux Kernel Contributor Covenant Code of Conduct Interpretation. Code of Conduct Committee The Linux kernel Code of Conduct Committee is currently made up of the following people: Kristen Accardi <kristen.c.accardi@intel.com> Shuah Khan <skhan@linuxfoundation.org> Greg Kroah-Hartman <gregkh@linuxfoundation.org> Joanna Lee <jlee@linuxfoundation.org> Committee members can be reached all at once by writing to <conduct@kernel.org>. Committee Reports We would like to thank the Linux kernel community members who have supported the adoption of the Code of Conduct and who continue to uphold the professional standards of our community. If you have any questions about these reports, please write to <conduct@kernel.org>. March 2025 Archival copy: https://lore.kernel.org/all/2025043021-reprogram-gloss-acb5@gregkh/ Updates to the Code of Conduct documents: The Code of Conduct documentation has been updated to clearly outline the enforcement when Unacceptable Behavior Code of Conduct Violations take place, and outline the Technical Advisory Board's role in approving remedial actions recommended by the Code of Conduct Committee. Reference: https://docs.kernel.org/process/code-of-conduct-interpretation.html#code-of-conduct-interpretation In the period of April 1, 2024 through March 31, 2025, the Code of Conduct Committee received the following reports: Reports received: 17 Development process related reports: Education and coaching on maintainers' right to accept or reject patches. Clarifying the expectations that developers can't demand their patches to be reviewed and/or accepted by the community. These reports were about a developer demanding their patch to be accepted even after repeated attempts by maintainers advising the developers to understand the development process. Code of Conduct scope and enforcement related reports: Education and coaching on the role and scope of the Code of Conduct. Several reports from people outside the kernel community reporting past incidents before the Code of Conduct was adopted. Reports resolved clarifying the scope and validity of reports about past incidents before adopting the Code of Conduct. Insensitive comments reports: Education and coaching on the role and scope of the Code of Conduct. Reports about Office of Foreign Assets Control (OFAC) related actions and offhand comments in technical discussions that do not rise to the level of violations. Unacceptable behavior or comments in email: 6 4 reports resolved instituting remedial measures on two individuals restricting their participation in development process. -- Rejecting pull requests from an individual for a full release cycle. Reference: https://lore.kernel.org/all/6740fc3aabec0_5eb129497@dwillia2-xfh.jf.intel.com.notmuch/ -- Banning an individual for 3 months from Linux kernel mailing lists. Reference: https://lore.kernel.org/all/67cf7499597e9_1198729450@dwillia2-xfh.jf.intel.com.notmuch/ Others - Resolved with the individuals making amends for their behaviors. We would like to thank the Linux kernel community members who have supported the adoption of the Code of Conduct and who continue to uphold the professional standards of our community. If you have questions about this report, please write to <conduct@kernel.org>. March 2024 Archival copy: https://lore.kernel.org/r/355aee5f-13ce-4e20-9ce8-e5bcddd14bc2@linuxfoundation.org In the period of October 1, 2023 through March 31, 2024, the Code of Conduct Committee received the following reports: Unprofessional behavior or comments in email: 2 The result of the investigation: Education and coaching clarifying the role of Code of Conduct conduct on conversations that don't go against the CoC. Education and coaching the individuals on the impact of making unprofessional comments which could be misunderstood leading to negative impressions about the community. The reports were about the offhand comments made while rejecting the code which are not violations of the Code of Conduct Unacceptable behavior or comments on a private invitee only chat channel: 1 Education and coaching clarifying the role of Code of Conduct conduct on conversations that occur on a private chat channel. We would like to thank the Linux kernel community members who have supported the adoption of the Code of Conduct and who continue to uphold the professional standards of our community. If you have questions about this report, please write to <conduct@kernel.org>. September 2023 Archival copy: https://lore.kernel.org/r/3351be6b-854e-479d-832c-83cb8829c010@linuxfoundation.org In the period of April 1, 2023 through September 30, 2023, the Code of Conduct Committee received the following reports: Unacceptable behavior or comments in email: 4 The result of the investigation: Education and coaching clarifying the Code of Conduct conduct related to normal review and patch acceptance process: 3 Clarification on the Code of Conduct conduct related to maintainer rights and responsibility to reject code: 1 The reports were about the discussion during the patch review and decisions made in rejecting code and these actions are not viewed as violations of the Code of Conduct. Please see the excerpt from the Responsibilities section in the Linux Kernel Contributor Covenant Code of Conduct Interpretation document: setting expertise expectations, making decisions and rejecting unsuitable contributions are not viewed as a violation of the Code of Conduct. March 2023 Archival copy: https://lore.kernel.org/r/557ef895-ad2d-eff9-7cb8-70dbcf41adea@linuxfoundation.org In the period of October 1, 2022 through March 31, 2023, the Code of Conduct Committee received the following reports: Unacceptable behavior or comments in email: 6 The result of the investigation: Education and coaching clarifying the Code of Conduct conduct related to normal review and patch acceptance process: 1 Clarification on the Code of Conduct conduct related to maintainer rights and responsibility to reject code: 5 The reports were about the decisions made in rejecting code and these actions are not viewed as violations of the Code of Conduct. Please see the excerpt from the Responsibilities section in the Linux Kernel Contributor Covenant Code of Conduct Interpretation document: setting expertise expectations, making decisions and rejecting unsuitable contributions are not viewed as a violation of the Code of Conduct. September 2022 Archival copy: https://lore.kernel.org/r/57a492fb-928b-9e0a-5f0e-dc95ef599309@linuxfoundation.org In the period of April 1, 2022 through September 30, 2022, the Code of Conduct Committee received the following reports: Unacceptable behavior or comments in email: 1 The result of the investigation: Resolved with a public apology from the violator with a commitment from them to abide by the Code of Conduct in the future. March 2022 Archival copy: https://lore.kernel.org/r/4401af50-083d-0239-6b7f-3454c8d69fec@linuxfoundation.org In the period of October 1, 2021 through March 31, 2022, the Code of Conduct Committee received the following reports: Unacceptable behavior or comments in email: 2 The result of the investigation: Education and coaching clarifying the Code of Conduct conduct related to normal review process: 2 September 2021 Archival copy: https://lore.kernel.org/r/e81f0726-5f8f-f10f-d926-a9126941d38e@linuxfoundation.org In the period of May 1, 2021 through September 30, 2021, the Code of Conduct Committee received the following reports: Unacceptable behavior or comments in email: 1 The result of the investigation: Education and coaching clarifying the Code of Conduct conduct related to normal review process: 1 April 2021 Archival copy: https://lore.kernel.org/r/448b06e4-41fc-26df-a862-c3ba2f70b6b3@linuxfoundation.org In the period of November 1, 2020 through April 30, 2021 the Code of Conduct Committee received the following reports: Unacceptable behavior or comments in email (3rd party): 4 The result of the investigation: Education and coaching: 1 Public response to call attention to the behavior and request correction with consequence of ban if behavior persists: 1 Public response to attention to the behavior and request correction: 1 Clarification on the Code of Conduct conduct related to maintainer rights and responsibility to reject code: 1 October 2020 Archival copy: https://lore.kernel.org/lkml/20201105083002.GA3429143@kroah.com/ In the period of January 1, 2020 through October 31, 2020 the Committee received the following reports: Unacceptable behavior or comments in email: 1 Unacceptable comments in github repo by non-community members: 1 Unacceptable comments toward a company: 1 The result of the investigation: Education and coaching: 1 Locking of github repo for any comments: 1 Clarification that the Code of Conduct covers conduct related to individual developers only: 1 December 2019 Archival copy: https://lore.kernel.org/lkml/20200103105614.GC1047442@kroah.com/ In the period of December 1, 2019 through December 30, 2019 the Committee received the following report: Insulting behavior in email: 1 The result of the investigation: Education and coaching: 1 August to November 2019 Archival copy: https://lore.kernel.org/lkml/20191218090054.GA5120@kroah.com/ In the period of August 1, 2019 through November 31, 2019, the Committee received no reports. September 2018 to July 2019 Archival copy: https://lore.kernel.org/lkml/20190810120700.GA7360@kroah.com/ In the period of September 15, 2018 through July 31, 2019, the Committee received the following reports: Inappropriate language in the kernel source: 1 Insulting behavior in email: 3 The result of the investigations: Education and coaching: 4 nПереглянути повний текст статті

You may access the archives of many Linux development mailing lists on lore.kernel.org. Most of them include a full archive of messages going back several decades. listing of currently hosted archives If you would like to suggest another kernel development mailing list to be included in this list, please follow the instructions on the following wiki page: Adding list archives to lore.kernel.org Archiving software The software managing the archive is called Public Inbox and offers the following features: Fast, searchable web archives Atom feeds per list or per individual thread Downloadable mbox archives to make replying easy Git-backed archival mechanism you can clone and pull Read-only nntp gateway We collected many list archives going as far back as 1998, and they are now all available to anyone via a simple git clone. We would like to extend our thanks to everyone who helped in this effort by donating their personal archives. Obtaining full list archives Git clone URLs are provided at the bottom of each page. Note, that due mailing list volume, list archives are sharded into multiple repositories, each roughly 1GB in size. In addition to cloning from lore.kernel.org, you may also access these repositories on erol.kernel.org. Mirroring You can continuously mirror the entire mailing list archive collection by using the grokmirror tool. The following repos.conf file should get you all you need: [lore.kernel.org] site = https://lore.kernel.org manifest = https://lore.kernel.org/manifest.js.gz toplevel = /path/to/your/local/folder mymanifest = /path/to/your/local/folder/manifest.js.gz pull_threads = 4 Please note, that you will require at least 20+ GB of local storage. The mirroring process only replicates the git repositories themselves -- if you want to use public-inbox with them, you will need to run "public-inbox-init" and "public-inbox-index" to create the database files required for public-inbox operation. Linking to list discussions from commits If you need to reference a mailing list discussion inside code comments or in a git commit message, please use the "permalink" URL provided by public-inbox. It is available in the headers of each displayed message or thread discussion. Alternatively, you can use a generic message-id redirector in the form: https://lore.kernel.org/r/message@id That should display the message regardless in which mailing list archive it's stored. nПереглянути повний текст статті

Copyright and license Except where otherwise stated, content on this site is copyright (C) 1997-2014 by The Linux Kernel Organization, Inc. and is made available to you under the Creative Commons Attribution ShareAlike 4.0 International License. Distributed software is copyrighted by their respective contributors and are distributed under their own individual licenses. Legal Disclaimer This site is provided as a public service by The Linux Kernel Organization Inc., a California 501(c)3 nonprofit corporation. Our servers are located in San Francisco, CA, USA; Palo Alto, CA, USA; Corvallis, OR, USA; Portland, OR, USA and Montréal, Québec, Canada. Use in violation of any applicable laws is strictly prohibited. Neither the Linux Kernel Organization nor any of its sponsors make any guarantees, explicit or implicit, about the contents of this site. Use at your own risk. Trademarks Linux is a Registered Trademark of Linus Torvalds. All trademarks are property of their respective owners. Переглянути повний текст статті

Welcome to the reworked kernel.org website. We have switched to using Pelican in order to statically render our site content, which simplifies mirroring and distribution. You can view the sources used to build this website in its own git repository. Additionally, we have switched from using gitweb-caching to using cgit for browsing git repositories. There are rewrite rules in place to forward old gitweb URLs to the pages serviced by cgit, so there shouldn't be any broken links, hopefully. If you notice that something that used to work with gitweb no longer works for you with cgit, please drop us a note at webmaster@kernel.org. Переглянути повний текст статті

You are probably wondering what happened to the site's look. Unfortunately, we've been alerted that the default theme shipped by Pelican (which we largely adapted) has an unclear license. Until this is cleared up, we've put together a quick-and-dirty cleanroom CSS reimplementation that preserves the functional aspects of the site, but sacrifices a lot of the bells and whistles. If you are a CSS designer and would like to donate your own cleanroom style, please let us know at webmaster@kernel.org. Our apologies, and we promise to keep a keener eye on licensing details of various templates distributed with open-source products. Переглянути повний текст статті

Due to a failure in one of the rsync scripts during the maintenance window, the mirrors of /pub hierarchy on www.kernel.org got erased. We are resyncing them now from the master storage, but in the meantime you will probably get an occasional "Forbidden". The entirety of the archive should be rsync'ed in a few hours. We apologize profusely for the problem and will fix the script to make sure this doesn't happen again. Contents of git.kernel.org are unaffected. Переглянути повний текст статті

We've implemented two oft-requested features today: The download links now default to .tar.xz versions of archives There is now a JSON file with the release information located in https://www.kernel.org/releases.json. If you've been screen-scraping the front page, please use this instead. If you have any other feature suggestions, please send them to webmaster@kernel.org. Переглянути повний текст статті

Special thanks to Benoît Monin for donating a MIT-licensed CSS theme to the kernel.org project to replace the one we hastily put together. Though the Pelican authors have since obtained a free-license commitment from the copyright owners of the CSS files shipping with Pelican, we wanted to have something that looked a bit less like the default theme anyway. If anyone else wants to participate, full sources of the kernel.org website are available from the git repository. Переглянути повний текст статті

If you would like to mirror all or a subset of kernel.org git repositories, please use a tool we wrote for this purpose, called grokmirror. Grokmirror is git-aware and will create a complete mirror of kernel.org repositories and keep them automatically updated with no further involvement on your part. Grokmirror works by keeping track of repositories being updated by downloading and comparing the master manifest file. This file is only downloaded if it's newer on the server, and only the repositories that have changed will be updated via "git remote update". You can read more about grokmirror by reading the README file. Obtaining grokmirror If grokmirror is not yet packaged for your distribution, you can obtain it from a git repository: git clone git://git.kernel.org/pub/scm/utils/grokmirror/grokmirror.git In additon to git, you will need to install the following python dependencies on your mirror server: GitPython Setting up a kernel.org mirror It is recommended that you create a dedicated "mirror" user that will own all the content and run all the cron jobs. It is generally discouraged to run this as user "root". The default repos.conf already comes pre-configured for kernel.org. We reproduce the minimal configuration here: [kernel.org] site = git://git.kernel.org manifest = http://git.kernel.org/manifest.js.gz default_owner = Grokmirror User # # Where are we going to put the mirror on our disk? toplevel = /var/lib/git/mirror # # Where do we store our own manifest? Usually in the toplevel. mymanifest = /var/lib/git/mirror/manifest.js.gz # # Where do we put the logs? log = /var/log/mirror/kernelorg.log # # Log level can be "info" or "debug" loglevel = info # # To prevent multiple grok-pull instances from running at the same # time, we first obtain an exclusive lock. lock = /var/lock/mirror/kernelorg.lock # # Use shell-globbing to list the repositories you would like to mirror. # If you want to mirror everything, just say "*". Separate multiple entries # with newline plus tab. Examples: # # mirror everything: #include = * # # mirror just the main kernel sources: #include = /pub/scm/linux/kernel/git/torvalds/linux.git # /pub/scm/linux/kernel/git/stable/linux-stable.git # /pub/scm/linux/kernel/git/next/linux-next.git # # mirror just git: #include = /pub/scm/git/* include = * # # This is processed after the include. If you want to exclude some specific # entries from an all-inclusive globbing above. E.g., to exclude all # linux-2.4 git sources: #exclude = */linux-2.4* exclude = Install this configuration file anywhere that makes sense in your environment. You'll need to make sure that the following directories (or whatever you changed them to) are writable by the "mirror" user: /var/lib/git/mirror /var/log/mirror /var/lock/mirror Mirroring kernel.org git repositories Now all you need to do is to add a cronjob that will check the kernel.org mirror for updates. The following entry in /etc/cron.d/grokmirror.cron will check the mirror every 5 minutes: # Run grok-pull every 5 minutes as "mirror" user */5 * * * * mirror /usr/bin/grok-pull -p -c /etc/grokmirror/repos.conf (You will need to adjust the paths to the grok-pull command and to repos.conf accordingly to reflect your environment.) The initial run will take many hours to complete, as it will need to download about 50 GB of data. Mirroring a subset of repositories If you are only interested in carrying a subset of git repositories instead of all of them, you are welcome to tweak the include and exclude parameters. Переглянути повний текст статті

Montreal frontend We have added another official frontend for serving the kernel content, courtesy of Vexxhost, Inc. There is now a total of three frontends, one in Palo Alto, California, one in Portland, Oregon, and one in Montreal, Quebec. This should allow for better geographic dispersion of official mirrors, as well as better fault tolerance. Kernel.googlesource.com We are happy to announce that kernel.googlesource.com is now relying on grokmirror manifest data to efficiently mirror git.kernel.org, which means that if accessing git.kernel.org is too high latency for you due to your geographical location (EMEA, APAC), kernel.googlesource.com should provide you with a fast local mirror that is at most 5 minutes behind official sources. We extend our thanks to Google for making this available to all kernel hackers and enthusiasts worldwide. TLS 1.2 and PFS With the latest round of upgrades, we are now serving TLS 1.2 with PFS across all kernel.org sites, offering higher protection against eavesdropping. Переглянути повний текст статті

Good-bye bzip2 We started listing xz-compressed versions of kernel archives in all our announcements back in March 2013, and the time has come to complete the switch. Effective immediately, we will no longer be providing bzip2-compressed versions for new releases of the Linux kernel and other software. Any previously released .tar.bz2 archives will continue to be available without change, and we will also continue to provide gzip-compressed versions of all new releases for the foreseeable future. So, from now on, all releases will be offered as both .tar.gz and .tar.xz, but not as .tar.bz2. We apologize if this interferes with any automated tools. Happy new year! Happy new year to all kernel.org users and visitors. The Linux Foundation and Linux Kernel Archives teams extend their warmest wishes to you all, and we hope that 2014 proves to be just as awesome (or awesomer) for the Linux kernel. Переглянути повний текст статті

Since we rely on the OpenSSL library for serving most of our websites, we, together with most of the rest of the open-source world, were vulnerable to the HeartBleed vulnerability. We have switched to the patched version of OpenSSL within hours of it becoming available, plus have performed the following steps to mitigate any sensitive information leaked via malicious SSL heartbeat requests: Replaced all SSL keys across all kernel.org sites. Expired all active sessions on Bugzilla, Patchwork, and Mediawiki sites, requiring everyone to re-login. Changed all passwords used for admin-level access to the above sites. As kernel.org developers do not rely on SSL to access git repositories, there is no need to replace any SSH or PGP keys used for developer authentication. If you have any questions or concerns, please email us at webmaster@kernel.org for more information. Переглянути повний текст статті

We've had to temporarily limit FTP access to mirrors.kernel.org due to high IO load. We have recently upgraded our hardware in order to increase capacity -- 16TB was no longer nearly sufficient enough to host all the distro mirrors and archives. We chose larger but slower disks and offset the loss of performance by heavily utilizing SSD IO caching using dm-cache. While it was performing very well, we have unfortunately run across an FS data corruption bug somewhere along this stack: megaraid_sas + dm_cache + libvirt/virtio + xfs We've temporarily removed dm-cache from the picture and switched to Varnish on top of SSD for http object caching. Unfortunately, as Varnish does not support FTP, we had to restrict FTP protocol to a limited number of concurrent sessions in order to reduce disk IO. If you are affected by this, simply switch to HTTP protocol that does not have such restrictions. This is a temporary measure until we identify the dm-cache problem that was causing data corruption, at which point we will restore unrestricted FTP access. Переглянути повний текст статті

Linus named the upcoming 4.0 release of the kernel "Hurr Durr I'ma Sheep" (see his git commit), so we are celebrating this April Fool's day with a minor prank. If you've been redirected to imasheep.hurrdurr.org, do not panic. It's all part of the joke. We've also restored all FTP and Rsync access to the mirrors.kernel.org servers, as we seem to have resolved our SSD and dm_cache problems. If you're still using FTP, however, please consider switching to HTTP. FTP is a protocol designed for a different era -- these days everyone should be avoiding it for multiple reasons. Переглянути повний текст статті

We are happy to announce that Fastly has offered their worldwide CDN network to provide fast download services for Linux kernel releases, which should improve download speeds for those of you located outside North America. We have modified the front page to offer CDN-powered download links, but all the existing URLs should continue to work. If you would like to avoid using Fastly, you can simply change the URL to have "www.kernel.org" instead of "cdn.kernel.org". As always, please use PGP Signature Verification for all downloaded files regardless of where you got them. Переглянути повний текст статті

If you find yourself on an unreliable Internet connection and need to perform a fresh clone of Linux.git, you may find it tricky to do so if your connection resets before you are able to complete the clone. There is currently no way to resume a git clone using git, but there is a neat trick you can use instead of cloning directly -- using git bundle files. Here is how you would do it. Start with "wget -c", which tells wget to continue interrupted downloads. If your connection resets, just rerun the same command while in the same directory, and it will pick up where it left off: wget -c https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/clone.bundle Next, clone from the bundle: git clone clone.bundle linux Now, point the origin to the live git repository and get the latest changes: cd linux git remote remove origin git remote add origin https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git git pull origin master Once this is done, you can delete the "clone.bundle" file, unless you think you will need to perform a fresh clone again in the future. The "clone.bundle" files are generated weekly on Sunday, so they should contain most objects you need, even during kernel merge windows when there are lots of changes committed daily. Переглянути повний текст статті

If your browser alerted you that the site certificates have changed, that would be because we replaced our StartCOM, Ltd certificates with those offered by our DNS registrar, Gandi. We are very thankful to Gandi for this opportunity. A common question is why we aren't using the certificates offered by the Let's Encrypt project, and the answer is that there are several technical hurdles (on our end) that currently make it complicated. Once we resolve them, we will most likely switch to using certificates issued by our fellow Linux Foundation project. Переглянути повний текст статті

Those of you who have been around for a while may remember a time when you used to be able to mount kernel.org directly as a partition on your system using NFS (or even SMB/CIFS). The Wayback Machine shows that this was still advertised some time in January 1998, but was removed by the time the December 1998 copy was made. Let's face it -- while kinda neat and convenient, offering a public NFS/CIFS server was a Pretty Bad Idea, not only because both these protocols are pretty terrible over high latency connections, but also because of important security implications. Well, 19 years later we're thinking it's time to terminate another service that has important protocol and security implications -- our FTP servers. Our decision is driven by the following considerations: The protocol is inefficient and requires adding awkward kludges to firewalls and load-balancing daemons FTP servers have no support for caching or accelerators, which has significant performance impacts Most software implementations have stagnated and see infrequent updates All kernel.org FTP services will be shut down by the end of this year. In hopes to minimise the potential disruption, we will be doing it in two stages: ftp://ftp.kernel.org/ service will be terminated on March 1, 2017 ftp://mirrors.kernel.org/ service will be terminated on December 1, 2017 If you have any concerns, please feel free to contact ftpadmin@kernel.org (ah, the irony). Переглянути повний текст статті

We are extremely happy to announce that Packet has graciously donated the new hardware systems providing read-only public access to the kernel.org git repositories and the public website (git.kernel.org and www.kernel.org, respectively). We have avoided using cloud providers in the past due to security implications of sharing hypervisor memory with external parties, but Packet's hardware-based single-tenant approach satisfies our security requirements while taking over the burden of setting up and managing the physical hardware in multiple worldwide datacenters. As of March 11, 2017, the four new public frontends are located in the following geographical locations: San Jose, California, USA Parsippany, New Jersey, USA Amsterdam, Netherlands Tokyo, Japan We have changed our DNS configuration to support GeoDNS, so your requests should be routed to the frontend nearest to you. Each Packet-hosted system is significantly more powerful than our previous generation frontends and have triple the amount of available RAM, so they should be a lot more responsive even when a lot of people are cloning linux.git simultaneously. Our special thanks to the following organizations who have graciously donated hosting for the previous incarnation of kernel.org frontends: Internet Systems Consortium Vexxhost Tizen If you notice any problems with the new systems, please email helpdesk@kernel.org. Переглянути повний текст статті

The XZ tarballs for the following kernel releases did not initially pass signature verification due to benign changes to the tarball structure done by the pixz compression tool: 4.11.1 4.10.16 4.9.28 4.4.68 These changes would have resulted in GPG returning "Bad Signature" if you tried to verify their integrity. Once we identified the problem, we generated new XZ tarballs without tar header modifications and now they should all pass PGP signature verification. We preserved the original .xz tarballs as -badsig files in the archives in case you wanted to verify that there was nothing malicious in them, merely tar header changes. You can find them in the same v4.x directory: https://www.kernel.org/pub/linux/kernel/v4.x/ Our apologies for this problem and thanks to Brad Spengler and everyone else who alerted us about this issue. Переглянути повний текст статті