Linux 4.18 Kernel Officially Released

[dungeon]

There is million ways how software is used...

... but only one way to be a troll

There are many stable believers.

Of course believers, it is normal that general public so majority of people wanna run more stable code, to lean to believe in obvious and expected, to trust something more, to not be continuosly interrupted so they could focus on what actually matters to them. Instead of promoting more stable code, you promote potentionaly broken code to general public, which is by definition wrong thing to do most of the time

[Divergent1]

If you look around and read a bit you will find that most sys admins, that run debian are in fact running sid, not stable. They do it because of security , and up steam bug fixes. debianxfce is probably correct. the amount of show stopper bugs is pretty small in reality, the fear of them is high, as shown in this thread. I recall a day where updating the kernel could be an adventure, those days are far over, but still remembered .

[Djhg2000]

If you look around and read a bit you will find that most sys admins, that run debian are in fact running sid, not stable. They do it because of security , and up steam bug fixes. debianxfce is probably correct. the amount of show stopper bugs is pretty small in reality, the fear of them is high, as shown in this thread. I recall a day where updating the kernel could be an adventure, those days are far over, but still remembered .

As someone who is using both Stable and Sid on an almost daily basis, hand have been for many years now, this does nor match my experience. Stable (with the Debian security repo) often get security updates at about the same time as Sid, and although rare, Sid does break slightly at times while Stable lives up to its name. Take for example PulseAudio. The version in Sid currently has broken LADSPA support (LADSPA_PATH got mangled in a rewrite just before 12.0, already fixed upstream). Meanwhile the Stable version works just fine.

As for the term stable, in software development it usually means no known critical bugs. It doesn't mean it won't ever crash, it doesn't mean there are no bugs, it just means that as far as they know it's good enough to represent the code quality which the developers are aiming for.

What the AMD development tree probably does is have more mature support for AMD hardware. Things like reset support in AMDKFD to recover from GPU crashes or more complete code paths. This makes it appear to be more stable and to some degree that would be correct, however the rest of the drivers are only periodically up to date (then the tree is rebased on a newer kernel) and may have undiscovered stability issues.

[Vistaus]

Problem is, in Linux stable rarely means actually "stable". It's more like you choose an arbitrary release and decide to call it stable (e.g. look at the current LTS kernel or the current LTS Plasma).

Actually, that goes for all kind of software. Look at Android 8.0, which was called stable but so full of bugs that even manufacturers like Samsung, BlackBerry and Nokia decided to postpone their work on the upgrade until a future, less buggy release (i.e. 8.0.1 or 8.1, depending on the manufacturer). Or Windows 10 with that one so-called "stable" upgrade that caused BSOD's on quite a few computers. Or that one iOS "stable" upgrade that locked quite a few people out of their phones.

[Vistaus]

If you look around and read a bit you will find that most sys admins, that run debian are in fact running sid, not stable. They do it because of security , and up steam bug fixes. debianxfce is probably correct. the amount of show stopper bugs is pretty small in reality, the fear of them is high, as shown in this thread. I recall a day where updating the kernel could be an adventure, those days are far over, but still remembered .

debianxfce, is that you using a second account?

[tildearrow]

A reminder for the AMD graphics users, mainline kernels do have partially implemented and buggy amdgpu driver. It is lottery if it is stable. Use amd-staging-drm-next or latest wip kernel from here: https://cgit.freedesktop.org/~agd5f/linux/

My distribution uses a AMD kernel: https://www.youtube.com/watch?v=fKJ-IatUfis

As of now mainline kernels have fully implemented amdgpu driver. When I tried the amd-staging-drm-next kernel last year, random freezes were a real pain for me.

[xiando]

Guys look! A FUD peddler!

His story regarding AMD bugs in the mainline kernel does hold water. radeontop -c indicates that I have 8 GB GPU RAM on boot but I magically get more over time. Just last week I had 12 GB RAM on my GPU. Free RAM!!! YES AMD Fine Wine indeed. The sad part is that someone came along and STOLE MY FREE RAM later on. That's TOTALLY UNACCEPTABLE. I need to have traps next to my desktop to catch all them RAM-stealing creeps!!!!

AMD is aware of this issue, btw.

4.18.0-rc3-agd5f+ doesn't have this problem. Well, it does, sort-of. GPU VRAM varies between 7960 and 8060M on that one. So it's not .. perfect. But it also doesn't vary wildly and grow to unrealistic amounts over time.

Not sure why you call reality "FUD" mister TemplarGR. If reality scares you then you've got a problem - because you're stuck with it. You should grow up and learn to accept and embrace reality. You do not have to be such afraid, you can learn to master your fear. Try to be shapeless, formless, like water. When you pour water in a cup, it becomes the cup. When you pour water in a bottle, it becomes the bottle. When you pour water in a teapot, it becomes the teapot. Water can drip and it can crash. Become like water my friend.

[smitty3268]

Not sure why you call reality "FUD" mister TemplarGR.

I'm not sure FUD is really the right term here, but the reality is that when debianxfce says that the mainline driver is a "partially implemented and buggy amdgpu driver" that's correct - but it's equally correct that the updated bleeding edge kernels he's always advertising are also partially implemented and buggy. That's the nature of a gpu driver - they are never feature complete or bug free.

Whether it has more or less bugs is an interesting question, and worth considering. I'd tend to argue that these days the stable kernels are good enough for most people and possible risks of get less tested code isn't really worth it - but if you're being bugged by some missing feature or particular problem then by all means going for an updated kernel may make sense.

I'd only say that you should know why you are doing that, and not just basing it off a whim or random internet comment. (And that debianxfce has a long history of, uhmm, questionable posts that make a lot of people simply disregard everything he says out of habit. And I don't blame them for doing so)

[xiando]

I'd only say that you should know why you are doing that, and not just basing it off a whim or random internet comment.

I absolutely agree. AMD responses (and they do tend to respond) to problems (with any of the kernel trees) is Can U Bisect Bro and Here's some fine brand new patches you can apply. My old mother uses a GNU/Linux distribution on her computer. She's happy with using it for browsing websites and what little she does with it but she has no idea what a kernel is and she sure as hell can't bisect. No way I'm putting anything but stable long-term software on that computer.. it's not like it's updated unless I visit her anyway.

Of course.. if you do know what bisect means then it's probably worth considering using AMD's kernel tree. But that too is a trade-off. Something debianxfce fails to mention is that they don't sync/pull mainline that frequently. This means newer AMD code on top of older mainline kernel code (=possible bugs already fixed in mainline).

[unixfan2001]

I mean. A couple years ago there was an NVIDIA driver that made GPUs overheat. WIP for the win though!