Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Linus Torvalds' poll about “big versions” in kernel releases

plus.google.com

Post reply on HN
Print view View original

61–70 of 70 posts

Re: Linus Torvalds' poll about “big versions” in kernel releases

#61

Post by weinzierl »

Perceval wrote: post #59
mlinksva wrote: post #56

Earlier quoted context omitted.

Numeric sorting can still work after 985 years. Only question is whether to use 1000.01 or 3000.01. I slightly prefer former, as a final rejection of the culture-specific BC/AC split. The ascendance of the net is the beginning of the real CE. Though skipping year notation altogether for seconds (or some 10s multiple of) since the epoch would also be fun for versioning.

> the culture-specific BC/AC split Any dating scheme is going to be culture-specific. The point you pick to be "year zero" is always going to be a point in time that's culturally valuable. > The ascendance of the net is the beginning of the real CE. That's an assertion that a marker you find culturally important (as a techie) is more meaningful to you than a marker that other people find culturally significant. You c…

There is no year zero in Common Era/Anno Domini.

Re: Linus Torvalds' poll about “big versions” in kernel releases

#62

Post by jokoon »

thirsteh wrote: post #38
jokoon wrote: post #33

I never understand why linux distributions download updates so often. I'd prefer something monthly at the most. I can't believe there are so many critical security update that much often...

You would prefer to wait a month for a security update rather than get it as soon as possible, is what you're saying? Even when the update process is as non-tedious as Linux's?

How can there be so many security updates though ?

Re: Linus Torvalds' poll about “big versions” in kernel releases

#63

Post by Perceval »

weinzierl wrote: post #61
Perceval wrote: post #59

Earlier quoted context omitted.

> the culture-specific BC/AC split Any dating scheme is going to be culture-specific. The point you pick to be "year zero" is always going to be a point in time that's culturally valuable. > The ascendance of the net is the beginning of the real CE. That's an assertion that a marker you find culturally important (as a techie) is more meaningful to you than a marker that other people find culturally significant. You c…

There is no year zero in Common Era/Anno Domini.

"Year Zero" was more a reference to the idea of trying to wipe out symbols of past culture (i.e. Anno Domini) for political reasons: https://en.wikipedia.org/wiki/Year_Zero_%28political_notion%...

Re: Linus Torvalds' poll about “big versions” in kernel releases

#64

Post by TazeTSchnitzel »

CopperWing wrote: post #20
coldpie wrote: post #4

By his own admission, the first two numbers mean nothing. Kernel releases happen on a roughly regular schedule. Date-based versioning is clearly the correct answer and I don't know why it's never even discussed.

They already discussed about this few years ago, but they decided against a date-based versioning because that would have meant breaking a lot of scripts and programs doing kernel detection assuming the old scheme. [1] [1] https://lkml.org/lkml/2011/5/23/358

Maybe just make the major be (year - 2000) and have the minors increment as normal?

Re: Linus Torvalds' poll about “big versions” in kernel releases

#65

Post by toyg »

jrochkind1 wrote: post #57
toyg wrote: post #10

Earlier quoted context omitted.

If you mean having something like "2015.01.13", it wouldn't look nice if stability-oriented distributions were forced to be seen as shipping "last year's kernel". It also looks stupid to patch a kernel you know is NN months old, even though you know it's the one you need to patch for reason XYZ. If you mean bumping the major release number every N years, then you'd have people complaining when a "major" release inevi…

> it wouldn't look nice if stability-oriented distributions were forced to be seen as shipping "last year's kernel". It also looks stupid to patch a kernel you know is NN months old, even though you know it's the one you need to patch for reason XYZ. But stability-oriented distributions ARE shipping "last year's kernel", and people ARE patching a kernel that is NN months old (whether they know it or not). Yes? You ar…

> You are arguing that what people are actually doing should be kept less transparent, because if it were obvious what they were doing it would look bad?

It would be nice if all people were so logically minded, and could think rationally about pros and cons of running a battle-hardened piece of code from last year, being guided in their decisions only by the unshakable faith in the values of critical thought and Scientific Enlightenment as declined by our Engineer-in-Chief.

The truth is, we all know that the average geek, giving a choice between $software version 2012_11_20 and 2014_12_15, would almost always pick the latter. Arguments that "the 2012_11* codeline is a workhorse and runs better with our hardware!" would simply not cut it; newer software will have more bugs fixed, right? It's only natural. Of course "nobody would run 2015_02_13, it's too bleeding edge", but a couple of months should be fine, surely? ... This sort of thought is not even conscious in most seasoned geeks, but it's inevitably there. Anything older than a few months would quickly lose all significance.

A date will irrevocably reduce a piece of software to a moment in time, an idea that a release is just a timestamp on a single line going from A to B; a date-agnostic release number gives software an identity that transcends time, so that it will actually make the choice clearer: you run 2.x because you want some features and not others for your own purposes, regardless of when they were released.

Man is what it is, and despite all their protestations, engineers are just men. If you think this sort of process does not happen in our minds, or that it doesn't matter in the end, then you should try replacing a release manager with a small timestamp-checking shell script.

Re: Linus Torvalds' poll about “big versions” in kernel releases

#66

Post by thirsteh »

jokoon wrote: post #62
thirsteh wrote: post #38

Earlier quoted context omitted.

You would prefer to wait a month for a security update rather than get it as soon as possible, is what you're saying? Even when the update process is as non-tedious as Linux's?

How can there be so many security updates though ?

Every platform that receives any attention is like that.

Re: Linus Torvalds' poll about “big versions” in kernel releases

#67

Post by 4ydx »

toyg wrote: post #65
jrochkind1 wrote: post #57

Earlier quoted context omitted.

> it wouldn't look nice if stability-oriented distributions were forced to be seen as shipping "last year's kernel". It also looks stupid to patch a kernel you know is NN months old, even though you know it's the one you need to patch for reason XYZ. But stability-oriented distributions ARE shipping "last year's kernel", and people ARE patching a kernel that is NN months old (whether they know it or not). Yes? You ar…

> You are arguing that what people are actually doing should be kept less transparent, because if it were obvious what they were doing it would look bad? It would be nice if all people were so logically minded, and could think rationally about pros and cons of running a battle-hardened piece of code from last year, being guided in their decisions only by the unshakable faith in the values of critical thought and Scie…

Ubuntu releases on specified dates and has names associated with those dates. Basically arguing that a date dilutes the value of the release seems pretty weak to me. Given that we are "engineers" who are people I think we would be able to look at a changelog of some sort and understand what a particular time stamp brings with it.

They are only numbers after all.

Re: Linus Torvalds' poll about “big versions” in kernel releases

#68

Post by mlinksva »

Perceval wrote: post #59
mlinksva wrote: post #56

Earlier quoted context omitted.

Numeric sorting can still work after 985 years. Only question is whether to use 1000.01 or 3000.01. I slightly prefer former, as a final rejection of the culture-specific BC/AC split. The ascendance of the net is the beginning of the real CE. Though skipping year notation altogether for seconds (or some 10s multiple of) since the epoch would also be fun for versioning.

> the culture-specific BC/AC split Any dating scheme is going to be culture-specific. The point you pick to be "year zero" is always going to be a point in time that's culturally valuable. > The ascendance of the net is the beginning of the real CE. That's an assertion that a marker you find culturally important (as a techie) is more meaningful to you than a marker that other people find culturally significant. You c…

You're right, thanks. The claims in my comment require lots of qualification, are embarrassing without.

I enjoy your a[s]t[ron]omic epoch year zero idea. One could start from much further back (eg beginning of universe, earth, modern humans, writing) but those would all be specific to the culture estimating them and to what that culture valued.

Re: Linus Torvalds' poll about “big versions” in kernel releases

#69

Post by moe »

toyg wrote: post #65
jrochkind1 wrote: post #57

Earlier quoted context omitted.

> it wouldn't look nice if stability-oriented distributions were forced to be seen as shipping "last year's kernel". It also looks stupid to patch a kernel you know is NN months old, even though you know it's the one you need to patch for reason XYZ. But stability-oriented distributions ARE shipping "last year's kernel", and people ARE patching a kernel that is NN months old (whether they know it or not). Yes? You ar…

> You are arguing that what people are actually doing should be kept less transparent, because if it were obvious what they were doing it would look bad? It would be nice if all people were so logically minded, and could think rationally about pros and cons of running a battle-hardened piece of code from last year, being guided in their decisions only by the unshakable faith in the values of critical thought and Scie…

Sounds like a win for everyone?

Those who always want the latest and greatest can see easier when their kernel gets "too old".

And the rest of us who run behind the curve benefits from the increased test coverage.

Post reply on HN