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

Linux 5.19

lwn.net

Post reply on HN
Print view View original

221–230 of 239 posts

Re: Linux 5.19

#221

Post by viraptor »

coldpie wrote: post #159
School-Cotton wrote: post #115

Earlier quoted context omitted.

I find it irritating when people quote semver like it’s some kind of law. It’s a random protocol someone came up with that some other people decided to follow. It’s nowhere near a de facto standard for version numbers: plenty of software has non-semver version numbers (in fact, this applies to all software I have worked on so far in my career!)

I think it's pretty clear semver doesn't really have a place in modern software. Except for Microsoft, no one cares about backwards compatibility, which semver is all about. All software is continually developed, every release contains both new features and bug fixes, which violates semver. The vast majority of software has a meaningless "1." or "0." tacked to the front to try to satisfy semver, until the project get…

> backwards compatibility, which semver is all about

It's not about maintaining backwards compatibility. It's about making it explicit when you break compatibility. Whether you do or not is completely up to you - semver doesn't care.

Re: Linux 5.19

#222

Post by viraptor »

alexeiz wrote: post #214

So Linus wants to use an arm64 to build and test kernel. Why not use AWS Graviton instead? Graviton3 may be slightly less powerful than M1 for single core workloads, but for multicore workloads like building the kernel it's much better suited. In fact, I don't understand why Linus uses a laptop for development. You can easily configure a more powerful cloud instance for the type of work he does. It may be costing mor…

You're assuming that he does the work using a good internet connection, is not physically mobile, and doesn't care about latency if you're proposing AWS as a replacement for a laptop. Which may happen to be true... but these are still serious assumptions.

Re: Linux 5.19

#223

Post by necovek »

FullyFunctional wrote: post #195
necovek wrote: post #92

Earlier quoted context omitted.

While I am a devoted fan of Thinkpad laptops (they are better than Apple MacBooks because of — at least as an option — non-glare screens, keyboards and soft-touch non-wrist-cutting palmrest: two/three most important factors for a portable machine imho), that's only partially true, and rarely with a new generation of hardware. Eg. I remember getting Thinkpad X1 Carbon 6th gen early on in the cycle (I've also got 5th a…

Quick note about the screen glaring - my very first action upon unpacking any Apple notebook is to apply a matte screen protector (the purist may wince). I'd recommend a screen protector on any expensive purchase and the matte one has all but eliminated the glare for me.

I personally live in a country where it's hard to get any small thing easily online: I'd probably have to order it online from USA, UK or Germany, get it processed by customs and then hope it'd work well. To reduce the costs of trying out more than one item, I'd probably order a few different ones so the shipping costs and customs costs are contained. Which means that I'd be spending $150+ on a screen protector that might not work.

Or I could just look for a laptop that has an anti-glare screen ;-) And a good keyboard.

Too bad new AMD-based Thinkpad Z series do away with a bunch of the good things from X1 Carbon (soft-touch palmrests for one), or I'd seriously consider them to be able to drop my desktop entirely (Intel iGPUs struggle to do full screen video calls on 4k external screens under Linux, I am _hoping_ AMD 680M would do a better job).

Re: Linux 5.19

#224

Post by School-Cotton »

dagw wrote: post #219
Lio wrote: post #218

Earlier quoted context omitted.

> Except for Microsoft, no one cares about backwards compatibility That would seem to be contradicted by Linus's "WE DO NOT BREAK USERSPACE" [1]. The Linux community clearly cares for backwards compatibility too. 1. https://linuxreviews.org/WE_DO_NOT_BREAK_USERSPACE

That's "Linux" the kernel, not the operating system. No one building a 'modern' desktop OS on top of that kernel cares. Download a 20 year old Linux binary and try running it on a random up to date linux distro. Unless it's a trivial program it will almost certainly fail.

This post is about the kernel, though.

Re: Linux 5.19

#225

Post by School-Cotton »

bonzini wrote: post #192
OJFord wrote: post #183

Earlier quoted context omitted.

There's value, albeit less in the minor vs patch distinction I think. So you could imagine a world in which SemVer came first, Linux uses it, and we're on 1.5.19 but usually drop the 1. because we've agreed there'll never be a v2.

That's pretty much the state of the 3.x releases, but at some point numbers got big.

I’d say it was the stage of the 2.6.x series.

Re: Linux 5.19

#226

Post by School-Cotton »

OJFord wrote: post #183
dcminter wrote: post #32

Earlier quoted context omitted.

The unofficial motto of the Linux kernel is "Don't break userspace" so semver wouldn't be useful.

There's value, albeit less in the minor vs patch distinction I think. So you could imagine a world in which SemVer came first, Linux uses it, and we're on 1.5.19 but usually drop the 1. because we've agreed there'll never be a v2.

What would be the point of that?

Re: Linux 5.19

#227

Post by zirak »

alexeiz wrote: post #214

So Linus wants to use an arm64 to build and test kernel. Why not use AWS Graviton instead? Graviton3 may be slightly less powerful than M1 for single core workloads, but for multicore workloads like building the kernel it's much better suited. In fact, I don't understand why Linus uses a laptop for development. You can easily configure a more powerful cloud instance for the type of work he does. It may be costing mor…

Maybe Linus wants to work on his laptop and not the cloud, because that's just the way he wants to work. And he wants an M1 / M2 because he likes something about them.

That doesn't feel very controversial, someone wanting to work the way they want to and not some other way.

Re: Linux 5.19

#228

Post by GoblinSlayer »

nicce wrote: post #174
coldpie wrote: post #159

Earlier quoted context omitted.

I think it's pretty clear semver doesn't really have a place in modern software. Except for Microsoft, no one cares about backwards compatibility, which semver is all about. All software is continually developed, every release contains both new features and bug fixes, which violates semver. The vast majority of software has a meaningless "1." or "0." tacked to the front to try to satisfy semver, until the project get…

SemVer has significant benefit for package manager world. Many argue that why don’t you just read a changelog, but that is not the point. Package manager should know whether it can update some dependency to later version safely, without some guy always manually hardcoding the suitable version. It is everywhere. In Arch Linux, Debian, Pip and Cargo. They all rely on versions which itself should describe the impact of…

It's often a change in interface. If you build from source, old code simply won't compile with new incompatible interface, and won't get to the testing stage.

Re: Linux 5.19

#230

Post by nicce »

GoblinSlayer wrote: post #228
nicce wrote: post #174

Earlier quoted context omitted.

SemVer has significant benefit for package manager world. Many argue that why don’t you just read a changelog, but that is not the point. Package manager should know whether it can update some dependency to later version safely, without some guy always manually hardcoding the suitable version. It is everywhere. In Arch Linux, Debian, Pip and Cargo. They all rely on versions which itself should describe the impact of…

It's often a change in interface. If you build from source, old code simply won't compile with new incompatible interface, and won't get to the testing stage.

The impact comes from the dependencies you are using. Depending how the software is made, it can be noticed early on build time. But it can also be noticed just on runtime, e.g. dynamic libraries, which is hopefully noticed on testing stage.

However, how it impacts downstream, the dependents of your software, cannot be tested. You can only inform about it. For people, with changelog. For automated systems, with version number. But if you do not follow systematic version numbering, you fail to inform automatic systems. They update to the later version of you software and dependents will break.

Post reply on HN