161–170 of 284 posts
Earlier quoted context omitted.
That's a lot of strawmen you managed to build here :/
That list really is sourced from Alex' email.
This is yet another situation where I (as a user) am being held hostage [1]. The net result of attitudes like these is that I can't have a working multi-monitor desktop Linux setup, because everything is hopelessly broken and requires many hours of tinkering just to kind-of sometimes work. I find it sad. [1] Apple has been excelling at this recently, too, with the forced move to USB-C and dropping of the headphone ja…
I take issue with the held hostage hyperbole, though. Yeah, you're inconvenienced by the OS/hardware options you have available. Your freedom of movement is not at stake. Your life is not at risk. I know it's fashionable to take poetic license and raise the stakes for everyday inconveniences, but let's keep things in perspective. Nothing's preventing you from using your old phone, or switching to another platform, or buying a couple of inexpensive dongles (very inexpensive relative to the hardware you've chosen to buy into).
Earlier quoted context omitted.
The claim that AMD, a company with gross profit in the $1 - 2 billion range, does not have the resources to support a dedicated development team that can do a good job on upstream-able code is just farcical. That's a question of corporate priorities, not resources, and gets precisely to the critique of corporate culture that was in question. > There's only so much time in the day; we'd like to make our code perfect,…
The funny thing is, had they followed some of the subclassing practices already in the kernel, it sounds like they could have had cleaner, more easily testable code with what from what I can tell tends to giv them a pretty unified interface. The belie, however, is an appalling response really: I realize you care about code quality and style, but do you care about stable functionality? Would you really merge a bunch o…
From a hardware and driver development standpoint, I think that makes a decent amount of sense. Hardware is often weird and quirky, so making sure you handle all the edge cases in two different codebases is a lot harder than doing it once. Certainly too much work for a handful of people who just want to plug their code into Linux.
Stability here is on the driver/hardware interaction, not the kernel/driver boundary, which is what the kernel folks seem to care about, naturally.
Earlier quoted context omitted.
Infused them with money? If you are talking about the legal settlement then this is a very charitable description on what happened from Intels side. https://en.wikipedia.org/wiki/Advanced_Micro_Devices,_Inc._v... .
Your link is broken, below is the correct one. More importantly, Intel wants AMD to stay alive and keep vaguely competing with them since they avoid significantly worse anti-trust rulings in the future (here is a current one[1]) due to there being no active x86-64 competitors. Additionally, think about Google, Amazon, MS Azure and all the other big players who push large volume on Intel's higher end SKUs, what do you…
This is yet another situation where I (as a user) am being held hostage [1]. The net result of attitudes like these is that I can't have a working multi-monitor desktop Linux setup, because everything is hopelessly broken and requires many hours of tinkering just to kind-of sometimes work. I find it sad. [1] Apple has been excelling at this recently, too, with the forced move to USB-C and dropping of the headphone ja…
KDE usually screws up when I plug a monitor into my notebook, but Xfce doesn't.
It's not a kernel issue.
KDE has a guy, he's singlehandedly awesome, yet of course a bit strange when it comes to interacting with mortals, who works on "these" things: https://blog.martin-graesslin.com/blog/2016/09/to-eglstream-...
And see, that it's NVIDIA that's currently holding back the year of the multi-monitor Linux desktop, because they're not supporting Wayland, like the others (Intel, AMD, Android).
Earlier quoted context omitted.
The claim that AMD, a company with gross profit in the $1 - 2 billion range, does not have the resources to support a dedicated development team that can do a good job on upstream-able code is just farcical. That's a question of corporate priorities, not resources, and gets precisely to the critique of corporate culture that was in question. > There's only so much time in the day; we'd like to make our code perfect,…
You've confused revenue with profit. They are not the same thing. AMD has been losing money for most of its existence and almost went bankrupt on a number of occasions. This renders your points completely invalid.
Earlier quoted context omitted.
The claim that AMD, a company with gross profit in the $1 - 2 billion range, does not have the resources to support a dedicated development team that can do a good job on upstream-able code is just farcical. That's a question of corporate priorities, not resources, and gets precisely to the critique of corporate culture that was in question. > There's only so much time in the day; we'd like to make our code perfect,…
AMD doesn't have "gross profit in the $1 - 2 billion range". They have about $1B in revenue per quarter and have had negative profits (i.e. they lose money) for quite some time now. They were on the verge of bankrupcy about a year ago. Maybe Zen can turn their fortunes around, but they're correct in that they don't have the resources for a dedicated development team right now.
[1] http://ir.amd.com/phoenix.zhtml?c=74093&p=irol-fundIncomeA
> Is all we care about android? I constantly hear the argument, if we don't do all of this android will do their own thing and then that will be the end. Right now we are all suffering and android barely even using this yet. If Linux will carry on without AMD contributing maybe Linux will carry on ok without bending over backwards for android. Could someone here fill in the details for the uninitiated? Do the kernel…
Android is important, because it's successful, despite how crude it is. And the Kernel maintainers - basically as a modern-day abstracted version of self-preservation - want to see the mainline kernel in/on Android devices, and so they are thinking about __why__ Android had to fork. (Had to? Or were they just that stubborn and time-limited?)
Earlier quoted context omitted.
They do already have clear interfaces that do this. Some modules have less clear interfaces, but if you followed what they were saying they actually said that it would have been easier if they had subclassed some of the code and followed the way that most folks were writing atomic code. And there was a function with the bane "validate" that didn't, well, validate . In a bit of code that rung alarm bells.
> And there was a function with the bane "validate" that didn't, well, validate so what? you still dont seem to grasp the concept of plugins. Plugin = the 3rd party developer can do whatever he wants and it doesnt hurt the core product.
The point that has been made over and over in these threads is that if you want to develop Linux code then you can't just stick a development team to work in complete isolation from everyone else in the Linux development community and expect to be able submit grand unifying architectures you designed to make it easier for your company but that make it harder for everyone else.
If you want to do this, then you really need to work within this particular community to effect change. For instance, there apparently are some standard idioms that have emerged from within the atomic code. The way AMD have done things is different enough to confuse the core maintainer, and he has reasonably said that he doesn't want to accept a commit like this. Hence his comments about the HAL and a massive middleware layer.
The bottom line is: AMD want to merge this into the kernel's main tree. But if they want to do this, they have to get through the maintainers, and the maintainers have to consider the whole picture and notjust your team, no matter how hard they have worked on their code.
The AMD team seem to have worked in a silo, not released to the CI servers and from what I'm reading broke stuff that others then fixed. So when the AMD guys did a big release all at once like this, then they got told - politely! - that their code wasn't up to scratch.