As long as v4.0-
Is incompatible with systemd, I'd say go for it.
Linus Torvalds is “running out of fingers and toes” and therefore wonders if it might be a good time to tip the Linux Kernel over into version 4.0. Torvalds has previously suggested version 4.0 could be set aside for a release dedicated entirely to bug fixes, but that idea didn't catch on. The Linux Lord has also previously …
But if The Register wants me to continue reading articles while I am at work, it needs to can the idea of adding pointless risqué images to articles. Not every employer would appreciate it, and it can make for a very uncomfortable conversation if the wrong person sees it.
>Although I looked at the photo for a good 2 minutes thinking they were boobs.
I hardly looked, assumed boobs and went straight to the article. Thank you, wolfetone, for pointing out how wrong I was ;-).
Now, I do not mind a middle finger and I work from home so no boss around ;-), however, I could not have read this article in the office without a problem or two with my female co-workers ... ;-) Besides, I do not think the boss would care, tbh, but that is just my boss, I guess ;-).
This post has been deleted by its author
The way I read it he is thinking of making 3.20 as 4.0 ?
If that is the case the huge milestone in that release is live kernel patching (i.e no need to reboot for a kernel update)
I see 4 as a rewrite of the kernel and not an incremental increase.
If we take x.y.z as our version scheme then 4 is code base, y is feature and z is fixes. You can amend an additional octet for build number.
I appreciate that no one ever uses version numbering the way I envision it. I can't see the first octet being changed if you aren't doing a rewrite.
I don't see how versions matter, I wouldn't mind seeing version 53245 myself. They serve no purpose, each release should point to a change list anyway. End users really don't care, they should be notified an update is available and have it applied, not bothering them with the version. Tech people should refer to the change list to see how important it is, not guess from which number changed in the version.
Depends, some projects use a source control system that generates nice human-friendly numbers (e.g. Subversion), others generate a hash?
The following statements are equivalent:
- I am running Linux kernel 906d77a3c6c0578ccb1834875ab53360777b7ff3
- I am running Linux kernel 3.17.2
Which is easier from a human-perspective? As it happens I track the linux-stable branch (git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable.git). If the main branch were to use just ordinal numbers, what does the stable branch use?
Seems like the dot is a pretty easy way to separate parts of the version number, and it's not difficult to go into a git clone directory and type:
RC=0 stuartl@rikishi /usr/src/linux-stable $ git log v3.17..v3.17.2 --oneline
906d77a Linux 3.17.2
29e7431 sparc64: Implement __get_user_pages_fast().
3ecc3b8 sparc64: Fix register corruption in top-most kernel stack frame during boot.
5cf02ef sparc64: Increase size of boot string to 1024 bytes
5c51a8b sparc64: Kill unnecessary tables and increase MAX_BANKS.
82f230e sparc64: sparse irq
0c64120 sparc64: Adjust vmalloc region size based upon available virtual address bits.
004f665 sparc64: Increase MAX_PHYS_ADDRESS_BITS to 53.
1bbd677 sparc64: Use kernel page tables for vmemmap.
92566c4 sparc64: Fix physical memory management regressions with large max_phys_bits.
73bf1d0 sparc64: Adjust KTSB assembler to support larger physical addresses.
498db9c sparc64: Define VA hole at run time, rather than at compile time.
665fae7 sparc64: Switch to 4-level page tables.
Isn't that what the LTS kernels are for? I suppose the idea is to get everyone focused on bug fixes, but what will happen is that a lot of kernel guys will take the time to develop even more aggressive changes than usual. The release after the bugfix only release will be extra unstable and it'll take another release cycle or two to recover from that!
Biting the hand that feeds IT © 1998–2021