Arthur T Knackerbracket has processed the following story:
Linus Torvalds has announced the version 6.1 release candidate for the Linux kernel, and added a stern message to developers: stop submitting code at the last minute.
This release isn't that big, Torvalds noted, as it only features 11,500 non-merge commits during the merge window, versus 13,500 last time. But he's been dealing with hardware problems while getting the infrastructure set up for developers to use the Rust programming language for updating the kernel. On top of these hardware glitches, he said he was "somewhat frustrated with various late pull requests."
"I've mentioned this before, but it's _really_ quite annoying to get quite a few pull requests in the last few days of the merge window," wrote Torvalds in his usual Sunday evening update. Work started on Linux 6.1 at the beginning of October.
"Yes, the merge window is two weeks, but that's very much to allow me time to look things over, not "two weeks to hurriedly put together a branch that you send Linus on Friday of the second week". The whole "do an all-nighter to get the paper in the day before the deadline" is something that should have gone out the window after highschool. Not for kernel development."
[...] "With some slack for 'life happens', of course, but I really get the feeling that a few people treat the end of the merge window as a deadline, missing the whole 'it was supposed to be ready before the merge window'."
(Score: 5, Interesting) by RamiK on Wednesday October 19 2022, @05:07PM (4 children)
People been complaining about procrastination and procrastinators for 2000 years now but whenever you ask them if they're taking any steps to remedy the problem, it's always "I'm too busy right now but I'll get to it as soon as my schedule clears up".
Here's a lucrative solution that will free the Linux foundation from it's political "allies": Schedule an early deadline for normal submission and a late deadline for paid submission. Get really greedy about it too. Like, add tiers for Gold members and the likes and throw in some point system for early submission.
Squeeze, Rabban. Squeeze hard.
compiling...
(Score: 4, Touché) by looorg on Wednesday October 19 2022, @06:41PM (3 children)
He clearly needs to set better deadlines. If there is only one deadline it's not a surprise people use that or wait until the last moment to submit. That said it's somewhat bad form to do a pull and submit right at the end of the timeline. What he should do is either move the timeline so he has more time or add a week or two after the deadline when he gets shit done.
That said old Linus wouldn't have let this slide, there would be some angry profane mails on the mailinglist. #BringBackOldLinus!
(Score: 4, Insightful) by krishnoid on Wednesday October 19 2022, @06:46PM (2 children)
Or how about an "I'll look at this for this merge" window, followed by "if it's too late, it'll get pushed to the next merge at my discretion" window?
(Score: 4, Insightful) by looorg on Wednesday October 19 2022, @06:55PM (1 child)
That would be valid to in my mind. Late submissions gets pushed until the next release. Still that is just another arbitrary line in the sand. He'll probably be upset then about how many submissions come in right before the "this merge" date. Another option might be that some submits have more leeway then others -- critical breaking things have more slack then something that is just nice to have. That said someone will probably qq about it no matter what if their precious submit didn't make it or wasn't in the correct category.
(Score: 1, Insightful) by Anonymous Coward on Wednesday October 19 2022, @07:41PM
Triage... It isn't just for the emergency room
(Score: 2) by mcgrew on Wednesday October 19 2022, @06:36PM (6 children)
It appears that some developers never learned that it's very disrespectful and unmannerly. Thoughtlessness.
Carbon, The only element in the known universe to ever gain sentience
(Score: 2) by RS3 on Wednesday October 19 2022, @07:29PM (5 children)
Was your comment sarcasm? Sorry, I can't tell. (I usually see both sides of a coin).
Either way, I think it's just a big coincidence that's likely to happen from time to time. Linus might consider some kind of staggered timeline system, rather than one big deadline for everything and everyone.
While I'm at it, much of the kernel is drivers, and I've long thought it might make sense to somehow divide the project into two major categories: core kernel, and drivers. A simple division might be that anything that can be a module should be in the second category. Maybe that's what Linus does anyway, I don't know.
(Score: 1, Interesting) by Anonymous Coward on Wednesday October 19 2022, @07:55PM (4 children)
Hmm, microkernel... What ever became of that? And why aren't "drivers" in the hardware? I shouldn't need to send anything more than a standard "print" signal to a designated port. Huge data I can understand, but fat software? A gigabyte to run a video card? It's insane. A machine with no moving parts should be ready to run in less than two seconds after flipping the switch
(Score: 5, Insightful) by RS3 on Wednesday October 19 2022, @09:19PM (3 children)
Microkernel is still a thing, esp. in RTOS (Real Time OS) stuff. A few weeks ago I was reading up on an interesting (slightly heated) discussion between Linus and I forget who but someone who had (still sort of has) a microkernel OS.
To me it's a kind of gray area. Years ago (mid-90s?) QNX had a downloadable floppy image that booted to a GUI, had a few utilities, ppp "stack" to dial up modem to the 'net, and a freaking web browser. I still have it somewhere.
One of their biggest features (selling / bragging points) was that their microkernel was so small that it would fit in, and stay in, the 80486's internal cache, giving the fastest response times and context switches. Pretty cool.
I'm not in on all the kernel development details, nor OS design considerations, but I'm sure there are limitations to microkernel designs (need to read Linus' discussion).
By definition, a "driver" is software, so I'm not sure what you mean by them being in hardware. I get what you mean about them being complex.
Years ago I remember a thing called a "Winmodem". It was where they (modem engineers) realized that PC CPUs were getting very powerful (late 90s) and rather than putting tons of expensive hardware on a modem circuit board, they could move most of the DSP processing to "driver" software that runs on the PC CPU. Now the modem can be less expensive. And if mods are needed, software updates can be sent out, including to accommodate newer telephone / modem specs (v.92 BIS comes to mind, but I forget what that means...).
Ensoniq did that with their audio chips- the PCI bus and CPUs were fast enough to move all of the complex sound libraries, processing, etc., into the main CPU and you obviously could update the software much more easily than re-flashing an expensive (and large) plug-in circuit board.
I also remember "Win Printers"- laser printers that were stupid, and would only work under Windows. The "driver" was large and complex and did all the vector to raster processing to then send that to the printer, which was just a dumb thing, probably much like a FAX printer (just prints what it gets, no page memory and processing). Not sure what ever happened to "win printers"... but for sure much printing processing is done in the PC before sending to the printer.
Boot times, well, that's another discussion. I don't have good answers, mainly because I don't get to design entire systems. At work we have one machine, very complex machine with many sensors, motors, solenoids, and a proprietary controller. As fast as you can turn it on, it's up and running. We have other machines that are based on (fully run on) standard hardware- PLCs and HMI displays- and they can take minutes to reboot.
I have some PCs that boot so fast you can barely get into BIOS settings. I have servers that take 5 or more minutes to get to loading the OS.
Better motherboards have at least a dual mode- full deep POST tests, and quick "assume things are okay" boot mode.
(Score: 5, Insightful) by sjames on Thursday October 20 2022, @05:50AM
Micro vs monokernel is an age old debate. Famously (or infamously), Torvalds and Tanenbaum had quite a discussion [wikipedia.org] about that shortly after Linux was published.
To this day, it's not settled. Things like Free RTOS can be microkernel because it runs on platforms that have little to no memory protection and so no real overhead. Few if any microkernel systems running on systems with real process isolation and protected memory have survived without at least some compromises to the architecture for the sake of performance. Othertwise, context switches drag the system down.
Meanwhile, it's been a long time since Linux was a pure monokernel as well. It started with modules and tasklets in the kernel that behave a bit like specially privileged programs living between the core of the kernel and userspace. A number of system init functions have moved into a minimalist userspace kept in an initramfs. Systems like FUSE take things a step or two further with filesystems implemented as daemons in userspace.
(Score: 1, Interesting) by Anonymous Coward on Thursday October 20 2022, @05:54AM (1 child)
That's just it, there should be no "boot/reboot". There should only be on and off.
(Score: 3, Insightful) by RS3 on Thursday October 20 2022, @06:38AM
You're not wrong, and it can be and is done. Since most OSes are built in RAM during boot, the concept of "hibernate" helps speed boot times. Also, suspend where you keep RAM alive in a very low-power state is possible.
Another approach is to have the OS image fully built and held in ROM (or FLASH), ready to run. Many simpler machines do it that way. Problem is, for general-purpose computing (PC, etc.), ROM and FLASH are much too slow, so you'd need to copy the whole thing to (fast) RAM then run, and you're back to hibernate.
Long BIOS boot times are because some BIOSes are doing a ton of internal tests (POST = Power On Self Test). I argue in favor of pretty much no testing unless it's needed. Many (better) BIOSes will boot super fast (again, before I can hit F2 or whatever) - unless they read a "flag" that wasn't cleared by a proper shutdown. The concept is, if PC didn't properly shut down, and therefore wasn't able to clear (or set, I forget) the "good shutdown" flag in "CMOS" memory (which is always alive), then BIOS decides something might have failed in hardware, so it'll do a thorough system test. This can often be skipped by hitting ESC, spacebar, or maybe some other "skip it" key.
Many pro audio, video, and lighting systems and some digital musical instruments use a hibernate so they can boot fast. But every now and then it might be good to do a boot from scratch, and it's usually possible to do that with some kind of button / keyboard combination.
(Score: 4, Funny) by bart9h on Wednesday October 19 2022, @06:54PM (2 children)
Instead of complaining that people are submitting on the deadline, and you think they should submit one week before, then just move the deadline one week earlier.
(Score: 4, Funny) by istartedi on Wednesday October 19 2022, @07:43PM (1 child)
They'll know you're lying though, and submit late on purpose. To prevent this, make the lie the result of the roll of 2 fair dice, the total minus 2 being the actual days to extend the deadline. They'll never be sure if the real deadline is the day you said, or some random number as much as 10 days from now.
Appended to the end of comments you post. Max: 120 chars.
(Score: 2) by Freeman on Thursday October 20 2022, @02:04PM
Your comment reminded me of this epic from xkcd. https://xkcd.com/221/ [xkcd.com]
int getRandomNumber()
{
return 4; // chosen by fair dice roll.
// guaranteed to be random.
}
Joshua 1:9 "Be strong and of a good courage; be not afraid, neither be thou dismayed: for the Lord thy God is with thee"
(Score: 4, Interesting) by Thexalon on Wednesday October 19 2022, @08:38PM
In this era of corporate-sponsored kernel development, I'd bet that the people that really need to be educated on this point isn't the developers but their managers who will get some sort of bonus if feature ABC is in the kernel by a certain date.
And yes, the way to teach that lesson is, as others have mentioned, to refuse all late feature merges as a matter of course, and bug merges will only be considered if the next version would reduce functionality without it.
The only thing that stops a bad guy with a compiler is a good guy with a compiler.