3 ms·
Most people here are commenting about the look and feel of LWN, I really don't have any complaints about the UI/UX so far, I don't expect to read LWN on my mobi
by filereaper 10y ago
Most people here are commenting about the look and feel of LWN, I really don't have any complaints about the UI/UX so far, I don't expect to read LWN on my mobile phone.
I think the main reason of the drop in readership is firstly kernel development is very involved and detailed, LWN mostly reflects the kernel mailing list and associated events and tech talks.
I guess what I find most difficult as an outsider of the kernel community, is trying to keep up. Jonathan Corbet is doing and extraordinary job summarizing the activities of the kernel community in LWN. But the kernel doesn't maintain any main "Epics" that we have in software traditional development, so take for example fair scheduling. AFAIK, the kernel community does not decide to tackle fair scheduling on the next release of kernel, ie 4.7. Then say power management in 4.8 etc...
LWN ends up with a smattering of various articles under common themes like "Kernel", "Security" etc...
LWN has in the past explained long running topics like scheduling when key updates are happening and I commend them for that.
None of the above is a negative reflection on the kernel community or LWN in how they operate but it feels kinda hard to keep up and stay vested.
Anyways just a few thoughts, will renew membership now.
- DiabloD3 10y agoNot all software uses epics. I've actually found epics personally to be a bit of an antipattern, but that's a conversation for another time. If the kernel has anything like an epic, there is multiple concurrent epics because the Linux is not a monolithic project. Nor are epics related to any kernel version. For example, each major GPU driver (radeon, novaeu, intel) manages their own development, and push things upstream. DRM (the kernel part of DRI) interacts with those guys, and DRM pushes things upstream. Network drivers and the network core are managed by small teams, push things to each other (such as adding support for major intrusive features like, say, when they added segment offload support, or recently genericfied the interface for that to support more protocols; or alternatively, when they started making more complex DMA patterns like scatter-gather and other zero-copy methodologies happen). The network guys push things to each other, and push things upstream. The storage guys also do that, storage drivers and storage core push things to each other, and push things upstream. Every possible major section of the kernel is a project in of itself, and have project leaders, and have parts that are ran by different people. Generally, you don't push a patch to lkml by itself, and then you're done; this almost never happens. What happens more often is you go to one of the people who manage that part of the kernel, or has significant experience with that part of the kernel, and discuss your patch with them, and then they will try to help you make a patch that can be merged upstream. More patches are rejected than committed because of how this works. Linus, or any other kernel maintainer, does not want your patch if it hasn't been ok'ed by the people who maintain those other parts of the kernel unless it is a small patch that does something obviously useful. And what about the companies that just push drivers? Companies employ kernel hackers that know how to write drivers. For example, Intel employs the Intel GPU driver guys, Radeon employs the Radeon GPU guys, and all those guys are already major authors in the X/DRI/Gallium/DRM/whatever community; the infrastructure to make that all work is shaped by the hardware, the hardware is not shaped by the infrastructure.
- cbsmith 10y agoLWN covers a lot in userspace as well. Kernel is only one section (though it occasionally expands in to other sections).