Linux.Slashdot.org

Linus Torvalds has pondered his professional mortality in a self-deprecating post to mark the release of the first release candidate for version 7.0 of the Linux kernel. From a report: "You all know the drill by now: two weeks have passed, and the kernel merge window is closed," he wrote in the post announcing Linux 7.0 rc1. "We have a new major number purely because I'm easily confused and not good with big numbers." Torvalds pointed out that the numbers he applies to new kernel releases are essentially meaningless. "We haven't done releases based on features (or on "stable vs unstable") for a long, long time now. So that new major number does *not* mean that we have some big new exciting feature, or that we're somehow leaving old interfaces behind. It's the usual "solid progress" marker, nothing more.â He then reiterated his plan to end each series of kernels to end at x.19, before the next release becomes y.0 -- a process that takes about 3.5 years -- and then pondered what happens when the next version of Linux reaches a number he finds uncomfortable. "I don't have a solid plan for when the major number itself gets big," he admitted, "by that time, I expect that we'll have somebody more competent in charge who isn't afraid of numbers past the teens. So I'm not going to worry about it."

Read more of this story at Slashdot.

Berlin-based T2 Linux developer René Rebe (long-time Slashdot reader ReneR) is announcing that their Xorg display server has now restored its XAA acceleration architecture, "bringing fixed-function hardware 2D acceleration back to many older graphics cards that upstream left in software-rendered mode." Older fixed-function GPUs now regain smooth window movement, low CPU usage, and proper 24-bit bpp framebuffer support (also restored in T2). Tested hardware includes ATi Mach-64 and Rage-128, SiS, Trident, Cirrus, Matrox (Millennium/G450), Permedia2, Tseng ET6000 and even the Sun Creator/Elite 3D. The result: vintage and retro systems and classic high-end Unix workstations that are fast and responsive again.

Read more of this story at Slashdot.

Linus Torvalds has told The Register how Linux went from a solo hobby project on a single 386 PC in Helsinki to a genuinely collaborative effort, and the path involved crowdsourced checks, an FTP mirror at MIT, and a licensing decision that opened the floodgates. Torvalds released the first public snapshot, Linux 0.02, on October 5, 1991, on a Finnish FTP server -- about 10,000 lines of code that he had cross-compiled under Minix. He originally wanted to call it "Freax," but his friend Ari Lemmke, who set up the server, named the directory "Linux" instead. Early contributor Theodore Ts'o set up the first North American mirror on his VAXstation at MIT, since the sole 64 kbps link between Finland and the US made downloads painful. That mirror gave developers on this side of the Atlantic their first practical access to the kernel. Another early developer, Dirk Hohndel, recalled that Torvalds initially threw away incoming patches and reimplemented them from scratch -- a habit he eventually dropped because it did not scale. When Torvalds could not afford to upgrade his underpowered 386, developer H. Peter Anvin collected checks from contributors through his university mailbox and wired the funds to Finland, covering the international banking fees himself. Torvalds got a 486DX/2. In 1992, he moved the kernel to the GPL, and the first full distributions appeared in 1992-1993, turning Linux from a kernel into installable systems.

Read more of this story at Slashdot.

A proposal within the Fedora Linux community suggests improving the kernel's DRM Panic screen to a more user-friendly, BSOD-style experience. Phoronix reports: Open-source developer Jose Exposito proposed today a nicer experience for DRM Panic integration on Fedora. Rather than using DRM Panic with just the kernel log contents being encoded in the QR code displayed when a kernel panic occurs, the proposal is to have a customized Fedora web-page with the encoded QR contents to be shown on that web page. Besides having a more pleasant UI/UX, from this web page the intent would also be to make it easier to report this error to the Fedora BugZilla. Being able to easily pass the kernel log to the Fedora bug tracker could help in making upstream aware of the problem(s) and seeing if other users are also encountering similar panics. Right now this idea was just raised earlier today as a "request for comments" on the Fedora mailing list. While a prototype at this point, Exposito already developed a basic web interface for demoing the solution.

Read more of this story at Slashdot.