Slashdot Mirror

First of all Vulkan support in the drivers are in a very early stage so things might change, AND the benchmark that you posted where for AMD GPUs, the nVIDIA ones painted a completely different picture: https://www.phoronix.com/scan....

Informative? Really mods? I'm sorry to burst your bubble but on both OpenGL and Vulkan Linux loses to Windows. This makes sense as more than 95% of the budget on Linux is spent on server development and servers? Really don't have much of a need for 3D acceleration.

Wish it weren't so but you are throwing away a good chunk of your hardware performance if you choose Linux for gaming.

Informative? Really mods? I'm sorry to burst your bubble but on both OpenGL and Vulkan Linux loses to Windows. This makes sense as more than 95% of the budget on Linux is spent on server development and servers? Really don't have much of a need for 3D acceleration.

Wish it weren't so but you are throwing away a good chunk of your hardware performance if you choose Linux for gaming.

One bit is very interesting to me:

A significant redesign to CPUFreq and P-State for allowing the kernel's scheduler to better communicate changes to the CPU frequency scaling drivers

Source: http://www.phoronix.com/scan.p...

It used to take some 30 ms for Intel CPUs to turbo-boost from a power-saving state (P-state). For CPUs in laptops, like the Core M series, this was noticeable when gaming. The latest-gen CPUs (Skylake) support very quick (1 ms) switching between P-states, and from what I gather, this kernel version now supports this. This means slight power savings and quick reaction from-and-to powersaving ("race to sleep").

Apparently it's very hard to get this right, because from what I read, the Microsoft surface tablets had a lot of trouble in this area.

I am several days late because I have been playing Tomb Raider on my Linux machine.

Yup, I feel your pain. It was an anxious wait until RadeonSI hit the opengl 4.2~4.3 milestone in Mesa.

(To all the other regular /. readers: sorry for the deep insider joke).

LOL! Yeah right

I don't really get the need for the attitude, if there existed zero evidence for it then I wouldn't mention it, however as you said in my case "don't believe that's intentional" maybe the same can be said about the harshness in your comment. But I assume it was, but you kinda covered it up by kinda stating being too harsh may not be valid because my "lies" wasn't intentional so whatever.

Over to the posts.
The stuff I've seen HAS BEEN lower performance on SteamOS. As for WHY that's is the case I don't really care. The main reason reason people would be against switching OS would likely be lack of applications, in this case the games they are or want to be playing, the second reason for gamers would likely be for lower performance if they switched. Lower performance may cut it for some ideologists but it won't cut it for the majority which focus about THE GAMES and not the operating system.

There's what is now old tests of early versions of SteamOS, maybe I really shouldn't use those.
Here's one on Arstechnica from 13th November 2015, it shows performance for ValveÂs own Source-based games:
http://arstechnica.com/gaming/...
SteamOS 2.0 vs Windows 10:
Portal: 107.1 vs 146.2 FPS
Team Fortress 2: 89.2 vs 114.3 FPS
Left for Dead 2: 49.1 vs 50.1 FPS
DOTA 2 (Source 2 version?): 60.0 vs 70.6 FPS.

They also cover Metro: Last Light Redux:
Min settings, SteamOS 2 vs Windows 10: 40.0 vs 50.5 FPS
Max settings, SteamOS 2 vs Windows 10: 4.2 vs 9.5 FPS
and Middle-earth: Shadow of Mordor:
Lowest, SteamOS 2 vs Windows 10: 61 vs 95.5 FPS
Low, SteamOS 2 vs Windows 10: 55.3 vs 87.0 FPS
Medium, SteamOS 2 vs Windows 10: 42.1 vs 63.3 FPS
High, SteamOS 2 vs Windows 10: 39.2 vs 50.7 FPS
Very high, SteamOS 2 vs Windows 10: 35.9 vs 46.9 FPS
Ultra, SteamOS 2 vs Windows 10: 14.6 vs 34.5 FPS

Phoronix, 6th August 2015, test performance of Ubuntu OpenGL vs Windows 10, http://www.phoronix.com/scan.p...:
OpenArena, slight lead for Ubuntu, at most by 12.4%.
Xonotic, massive lead for Windows, at most 344.9% faster.

Arma III about the same in the clip you pointed out I'd say, but maybe I would had preferred the Linux version anyway because it's the slowest parts of the game-play which matter the most.
Googled for Total War on Steam OS and Windows and found this of TW: Attila which shows better performance on SteamOS: https://www.youtube.com/watch?...

16th November 2015, SteamOS vs Windows 10:
https://www.youtube.com/watch?...
Geekbench: Winner Windows 10.
Unigine Heaven: Winner Windows 10 (46.5 vs 48.8 FPS.)
Borderlands 2: Winner Windows 10 (34.1 vs 38.6 FPS.)
Metro: LL: Winner Windows 10 (37.5 vs 42.3 FPS.)
Alien: Isolation: Winner Windows 10 (46.8 vs 54.2 FPS.)
Shadow of Mordor: Winner Windows 10 (~42 vs ~47 FPS.)

8 February 2015, CS:GO:
https://www.youtube.com/watch?...
Kinda a wash, either side leads at times.

As for Vulkan:
17 February 2016: http://www.anandtech.com/show/...
Fury X:
OpenGL: 51.8 FPS
Vulkan: 56.9 FPS (beta)
DX11: 97.8 FPS
980Ti:
OpenGL: 62.6 FPS
Vulkan: 65.8 FPS
DX11: 91 FPS

Not on topic but somewhat related I think the performance using DX12 in Gears of wars was worse too? Or was it just that AMD cards performed worse with that version? (It is a GameWorks title.)

As I said with completely new games and engines from people who know what they are doing that may change but as is anyone who owns The Talos Principle who were exited about Vulkan support and who hopped for even bet

Even better

Actual link to the Odroid C2 vs Raspberri Pi 3 comparison:
http://www.phoronix.com/scan.p...

It's not really true. What's true is that there is no working OSS driver for Mali. PoC has been done (ISTR Quake 3 running) but there's nothing you could actually count on. Most of the driver is closed-source, and provided by ARM only to Mali licensors. The wrapper bits are open source.

It's also true that more effort is put into Android video support than Linux support because the majority of the Mali customers are running Android.

I don't really care about gaming whether on Linux or anywhere else, but when it comes to Nvidia performance on Linux, it's been on par with Windows for a long time. So "blow out of the water" is a gross exaggeration in the general case. (YMMV and all that).

Additionally, a previous Phoronix article stated they only got remote access for testing this thing - so at present this is basically the equivalent of a Kickstarter promise.

That would be this article?

How do you make the equation "only getting remote access" EQUALS "the equivalent of a Kickstarter promise."?

The company are reasonably well-known (I looked at them several years ago when I was considering replacing my day-to-day laptop with one whose video chip hadn't just got static-fried), and they're very open about saying that they're evaluating options for building an entry into this market (see footnote). So they probably have a total of TWO systems at the moment - the one they're experimenting on, and a second one for testing and promotions and customer evaluation. So, are they going to spend hundreds of dollars shipping one of those two systems around a series of publicity sites, giving them (say) 2 days with the machine, and several times a week having to say "we DID tell you you need a 220V power supply. What, it's not booting ... describe the output form the BIOS ..." you're talking tech support hell, and you'll have crippled your development programme.

The alternative is to set the machine up with remote access via a VPN and displaying the screens remotely on their terminals. Then all hardware issues you have your own technical people on hand. Timing and benchmarking can be carried out just as well. IF the customer has (per my example in the footnote) a data library they want to do a test on, they can send you the hard drive in advance and book a slot on the machine to run their tests next Thursday afternoon.

Hang on - have you ever actually worked on a time-shared system? One where you prepare your job set one week, and get the tapes of the run and the error logs back a few days later? That's what I think of when I hear "workstation".

Footnote
I see workstations like this hauled to site for data acquisition routinely - a few terabytes of new raw data per day, but you need to process it and incorporate it with terabytes of existing data from the surrounding area which has been subject to months of detailed evaluation and interpretation. Someone asked upthread what you'd need to use 128GB of RAM for : seismic data processing will eat that happily. And with a boat for data acquisition running about a half million dollars a day and a crew of 50-odd, you're not going to quibble at tens of kilo-bucks for a workstation or several.

https://www.phoronix.com/scan.php?page=news_item&px=Intel-KNL-Perf-In-Linux-4.5/

After the FFMPEG fork is there a Linux distro that still uses FFMPEG & Mplayer?

Firstly: Not all distro switched to avlib.
Some simply decided to stay with ffmpeg (e.g.: opensuse never switched at all)
Some changed their opinion back (e.g.: Debian went back to ffmpeg after a while)
This is mostly to avlib never really being a good an active fork, and didn't manage to attract most developper to it.
(Unlike OpenOffice.org to which most developer migrated after the fork from LibreOffice.org).

Since then the problematic leader of FFMPEG has decided to step down,
avlib has merged back to ffmpeg
and distro are back to- / or are still using- ffmpeg again.
And the guy is now a contributor. He still writes code for ffmpeg, but he's not having a final say on everything and thus fighting with everyone to have his "one true vision(tm)" imposed.
He has fully realized that his character clashes with some in the community, has seen the disastrous result on having avlib forked (the linux ecosystem split across two different forks, none of which becomes a clear leader and each laging behind the other on some important features), and decide therefor to step down for the greater good of the community.

source: Phoronix

According to a comment on Phoronix ( http://www.phoronix.com/forums... ), the cause is a goto:

"And the funny thing is? The guilty line is a fucking GOTO. Everyone using this atrocious coding practice should be shot in the head." ("magika")

User "stevenc" adds: "It's a pretty common pattern of trying to emulate Objected Oriented Programming in C. Try to construct one or more 'objects', otherwise fall back to one or more 'destructors' at end of the function. They'd even implemented their own reference counters within the struct (object) and had function pointers (methods); both of which allowed this to be an exploitable bug. In OO languages these are implemented in the language/interpreter/compiler and usually done right. "

Now please contrast the desire to have C++ features without using C++ with this post: http://article.gmane.org/gmane...

At least one "substandard" programmer has a lot of egg on his face right now...

A large portion of the submitter's words were stolen verbatim from the second link without any attribution.

Judging from the users input and my own experience Plasma 5.5.3 still works and feels like an early beta other than a final product which has seen several minor releases.

I don't know what happened to the KDE project but surely something was lost during the transition from KDE 3.5.x to KDE 4.x/5.x.

I backed the Pine A64[+] at the 2GB, $29 level. If it pans out, that is a crazy stupid low price for that much machine. The only part of it that is less than ideal specs-wise is the GPU, but I don't really care about that. It would be daft to not get at least the $19 1GB model, since the plus has the DSI, touch panel, and camera ports as well and it's nice to leave yourself the option. Plus (ha ha) trying to get stuff done in 512MB is occasionally frustrating. It is Allwinner, so meh. But with ongoing pressure from the community, they may make slow improvement which is better than no improvement at all.

The $15 version might be useful for building your own AP, I guess. If Master mode works properly on the wifi chipset, that is.

It's been in the kernel for a few months and it's constantly being updated and fixed. They're actually doing a pretty good job of it honestly. The catalyst driver still doesn't use it, but they will soonish. Mesa uses it and it works really well actually. This is the earliest article I could find, more recent ones have mesa 11 benchmarks where the Radeon driver has almost caught up to the catalyst in some areas. http://www.phoronix.com/scan.p...

Except that wouldn't really be a great experience because AMD's drivers are still terrible on Linux.

That is unfortunate.

OTOH, a distribution aimed at PS4 would have the benefit of working against fixed hardware. They don't need to take odd combinations into consideration. "Works on my setup" isn't going to be as much of a problem then.
Will probably not mean that much for the drivers, but if they think they can improve anything they don't have to worry about the changes breaking something else.

Except that wouldn't really be a great experience because AMD's drivers are still terrible on Linux.

Both of the current PC-like consoles use AMD GPUs derived from the GCN 1.0 family. The PS4's is roughly somewhere in between a Radeon HD 7850 and 7870, where the XB1's is harder to compare due to the memory configuration being rather unique (fast ESRAM cache but slow DDR3 main memory). It has less cores and a third the memory bandwidth but clocks higher.

Considering that even nVidia's optimization on Linux isn't as good as it is on Windows, most benchmarks I've seen show SteamOS delivering 50-80% of the framerate seen with the same hardware on Windows, you'd be giving up a LOT by trying to run SteamOS on a PS4 rather than just building a cheap gaming PC.

Since the flaw being exploited will likely be patched soon after it goes public, if not before, the better plan if one wanted to switch from PS4 to something else would be to hang on to your potentially exploitable console and keep it offline until someone releases an exploit. If Sony is able to fix the hole with a patch any unpatched boxes immediately jump up in value, like we saw with the Xbox 360 and PS3. That of course means giving up online features and possibly new game releases for a while, but if you're one of those users who doesn't game online and/or uses it mostly as a Bluray player that might not be a big deal. You can then use the money to build a budget gaming PC that'll beat the pants off of any of the consoles.

Yet isn't it funny that when you use code compiled with GCC instead of ICC you get these results? This is why you can't base shit on a single or even couple game benchmarks anymore, there is just too many ways to grossly affect the outcome. If you gave me the code to a popular game and let me control the compiler? I have ZERO doubt that I could make a 2003 Sempron beat an i7, its all about making sure the code supports the advanced features of the chip you want to win, while ignoring those features in the chip you want to lose, easy peasy. And that isn't even addressing just shitstain code written by a "works for me!" dev that doesn't est shit on anything but their own rig, which I really get the feeling is Wargaming in a nutshell.

And just for the record I play their World Of Warships as does my wife and despite her being on a Phenom II 925 from 6 years ago? Plays great with high framerates. BTW just FYI the biggest booster you can give to that game? Put it on an SSD as its code is really poorly optimized and even on the fastest HDD it'll lag, like Tera its shit code and "Hey my chip plays really shit code slightly faster!" is really not a selling point in my book.

Large applications can take -forever- to compile, even if its not a clean compile.

Many complaints about slow compiles are due to dysfunctional workflow. You should be using precompiled headers, and set up your makefiles for multiple cores. But most importantly, you should be using TDD to develop and debug code outside of the application. So instead of compiling and linking the entire application repeatedly as you track down a bug, you only integrate after all your unit tests are written and passed in isolation.

But, anyway, it isn't clear that Gcc actually compiles faster than Clang. Here are some benchmarks, and the results are mixed. Sometimes Clang is faster, sometimes Gcc is faster. For a large app, they would likely be about even in compile time. But Clang would likely generate better code, and almost certainly generate more helpful errors/warnings/analysis.

I can't see any rational reason to prefer Gcc.

Translation: "network tran--I mean speed is a feature that most of our users don't need, so it's not in our development plan"

No. Clang produces faster code. What TFA means is that GCC compiles faster. But if slightly faster compiles are that important, just turn off the optimizer, or buy a faster computer. How much time does a modern developer spend waiting for the compiler to finish? For me, it is less than 1%. Far more important is the better error messages, warnings, and static analysis from Clang. Those save me way more time than the speed of the compiler.

When opponents to sth have to lie through their teeth, hoping that noone will go read and understand their links, they're immediately disqualified in my view.
You clearly are not qualified to understand what you're talking about, but at least you made the work to fool people that won't ever read the links provided because they're not qualified either. Unfortunately for you, some people will read them. And they'll see your lies, which explains why you posted as AC.

Let's run down the list of "why":

- Systemd contains an unchecked null reference pointer that segfaults PID 1.
Lennart Poettering states he won't fix it
https://bugs.freedesktop.org/s...

No, systemd doesn't have such a thing, and LP never said what you're saying. The link show a very non civil hater (the systemd devs kept their cool), that wants the devs to tackle at high priority an unsupported setup, which became badly handled by systemd because of a kernel change. One thing that is legitimate, is that systemd should at least gracefully quit when in such an unsupported setup. Which has been done and fixed by the systemd devs. They asked for a patch from the guys who insist on using an unsupported setup, and of course, never got anyhting, and had to do it themselves. Classic "the setup you told me won't work, that's what I want to use, or systemd is crap". Why a sysadmin would do that, I can't understand.

- Systemd and Gnome allow bypassing gnome-shell password prompts granting root
Left unfixed for over a year
http://www.phoronix.com/scan.p...

Another big lie, systemd has nothing to do with this problem, it's only Gnome Shell that is the problem in some distro setups, and that was introduced because users were locked out of their desktop. To sum it up, Gnome-shell made a kludge to remove the security systemd provides, so as not to lockup users.

- Systemd segfaults during upgrades of itself, combined with the new log files that can't be retrieved Mr Poettering says are required to fix the bug, but he will not provide any method for Systemd to generate the logs he demands from it.
https://bugzilla.opensuse.org/...
https://utcc.utoronto.ca/~cks/...

Yet, the true sysadmins that reported it managed to provide logs and debug the systemd-208 version, which is the version we're talking about here, which is an arbitrary version that some distros took as a supported one in their distro. LP never said anything of what you're lying about here, especially as what you say makes no sense when PID one segfaults, then the core deump is important, and that's one of the thing that has been provided by competent sysadmins, not by incompetent whiners. This bug has been fixed in the 208 version used by this distro, using true debug means recommended by systemd devs or distro maintainers, not your nonsense. The upgrade was also fixed by the distros, as they were in charge of supporting the version, with the help of systemd devs.
And yes, it happened once with a systemd version, that it crashed on live updating itself.

- Systemd distros can not boot if no ethernet link is present
https://lists.debian.org/debia...

Actually that's not true at all, it will boot just fine. It's just a clueless user there that tuned his laptop with an antiquated configuration that is static instead of dynamic, and perhaps that's Debian's fault. There must be a long timeout, but eventually, he would have arrived to emergency console.
Systemd is dynamic if you use its native tools, not if you use the compatibility static tools of Debian. But it boots

If you're allergic to trimming your neckbeard and running a modern init, just switch to *BSD where they adopted the features that people are whining about decades ago. ;)

Haters hate, but do they know why? Do they have a choice? Do they have Free Will, or were they born unable to tell the difference between choosing software they want to run, and being forced to run software that... they chose?

Let's run down the list of "why":

- Systemd contains an unchecked null reference pointer that segfaults PID 1.
Lennart Poettering states he won't fix it
https://bugs.freedesktop.org/s...

- Systemd and Gnome allow bypassing gnome-shell password prompts granting root
Left unfixed for over a year
http://www.phoronix.com/scan.p...

- Systemd segfaults during upgrades of itself, combined with the new log files that can't be retrieved Mr Poettering says are required to fix the bug, but he will not provide any method for Systemd to generate the logs he demands from it.
https://bugzilla.opensuse.org/...
https://utcc.utoronto.ca/~cks/...

- Systemd distros can not boot if no ethernet link is present
https://lists.debian.org/debia...

- Systemd distros can not boot if using certain DNS servers
https://bugs.debian.org/cgi-bi...

- Systemd distros can not boot if using certain NTP servers
https://github.com/systemd/sys...

- Enabling the kernel "debug" command line option results in boot storage being filled with thousands of dmesg log entries per second from Systemd, and a non-booting system results
https://bugs.freedesktop.org/s...

- Systemd disables SysRq keys to ensure data loss after any of the many many instances it is coded to fail under
https://lists.debian.org/debia...

Phoronix comes to the same conclusion:
http://www.phoronix.com/scan.php?page=article&item=amd-crimson-linux&num=1

Looks like all the graphs on Page 7 has an incorrect TK1 label instead of the correct TX1 ?
http://www.phoronix.com/scan.p...

With nVidia getting serious about low power devices the next few years are going to be very interesting as AMD, Arm, Broadcom, and Intel all duke it out.

I can't wait till OpenCL is supported as well.

Here you are... https://www.phoronix.com/scan....

One of my primary suspects for the difference is the video card - how well optimized are the Linux drivers?

On an absolute scale, probably not as well-optimized as the Windows one. But Nvidia's Linux drivers have consistently been better-performing than AMD's versions. Intel's Linux drivers have had problems, too, and their dependence on Mesa has meant that a lot of recent OpenGL features haven't been exposed. Plus Intel's hardware is significantly slower than AMD or Nvidia's offerings.

One of my primary suspects for the difference is the video card - how well optimized are the Linux drivers?

On an absolute scale, probably not as well-optimized as the Windows one. But Nvidia's Linux drivers have consistently been better-performing than AMD's versions. Intel's Linux drivers have had problems, too, and their dependence on Mesa has meant that a lot of recent OpenGL features haven't been exposed. Plus Intel's hardware is significantly slower than AMD or Nvidia's offerings.

One of my primary suspects for the difference is the video card - how well optimized are the Linux drivers?

On an absolute scale, probably not as well-optimized as the Windows one. But Nvidia's Linux drivers have consistently been better-performing than AMD's versions. Intel's Linux drivers have had problems, too, and their dependence on Mesa has meant that a lot of recent OpenGL features haven't been exposed. Plus Intel's hardware is significantly slower than AMD or Nvidia's offerings.

Just remember the cardinal rule which is if you don't know which compiler they used the test is worthless as Intel to this day uses the Cripple code in their compiler and pays benchmark companies to use it with predictable results. You let ME write the conditions on the compiler I can make a Sempron from 03 beat the latest i7, don't make the test worth a fuck.

If you want to see how the chip REALLY stacks up without cripple code? Just look at these Linux benchmarks and surprise! Remove the cripple code and you have The FX8 competing with i5 and i7 and the A10 beating i5...wow, isn't it amazing how much just not rigging the fucking benchmark does for the scores? Its a fricking miracle.

The trouble with Wayland, or rather why I'm deeply suspicious of it is that some of the claims from the devs about wayland and X11---and bear in mind they're X11 devs too---are flat out wrong at best and deeply deveptive at worst. Why the need for a FUD attack? If Wayland is better it ought to win on merit, not FUD.

Tahe for example this article: http://www.phoronix.com/scan.p... [phoronix.com]

Going through one at a time.

1. Extensions are what X11 calls API updates. Wayland will get API updates too, so this is not an advantage of wayland beyond version 1.0.

1. A, B, C: Almost all extension version updates add new API calls and keep the old ones. Sending Foo 2.0 calls to Foo 2.2 works just fine. Not to say that versioning isn't a problem, but then fixing the API is apparently bad for X but nothing else.

2. Well core X11 is super simple and a tiny setup of Xinput 2. This leaves essentially 2 input systems left of any complexity, 2.2 and 2.0, and as far as I can tell 2.0 isn't actually separate from 2.2. So, basically X has one major input system which actually looks kinda similar to the Wayland one.

3. That's a misunderstanding of "mechanism not policy"

4. So Xorg and Xfree86 got a bit crazy and then got refactored. Apparently historical cleanups are a bad thing? This happens in any project of any age.

5. Apparently it's impossible to add a new API call for synchronisation because from (1) that X11 isn't allowed api updates unlike every other system.

6. Yeah OK, fonts are not great.

7A A badly designed chunk of Xorg is apparently a problem with X11 now. Oh and it's been fixed so it's not a problem at all. But apparently every misstep in one implementation of an X server fixed 5 years ago is a reson it's bad now.

7B That was pure fud in 2013 when it was written. Xrandr and monitor hotplugging has worked flawlessly for years.

7C Huh? There's been xrandr front ends for years which remember certain layouts. Hell, Arandr, the nice GUI point and click one in all the repos remembers layouts just fine.

7D That smells like bullshit to me. Unless the second monitor is a separate screen (X11 term for something little used now) they it'd be impossible for one to have compositing and one not. I've not heard of anyone using screens in years.

8 Yeah and real toolkits are poorer for it. The window tree is a really nice thing when you have latency. Because with tree'd systems the server remembers which sub-sub-sub window a mouse click went to, and you could ignore the absolute position. With a treeless system all you have to go on is the position.

With latency, if you click, then the display updates then it processes the click, your click goes not where you want, but where the GUI is now. This I find happens more often than I'd like in web "apps". With tree based systems, sure the widget moved, but the assignment of the click to the window was latency free, so your click ends up correctly on the now-moved widged.

IOW tree based systems are superior. Many toolkits abandoned it for compatibility with non tree based systems. What we have now is actually fundementally worse in high latency environments.

9 Yes this is finally a genuine, no-nuance flaw.

10 C this is not correct if you have a compositing window manager, because it can do whatever it likes with the final display.

10 D their solution is to make the compositor do all this shit in Wayland. That could be done equally well in X. Sure, the current convention has a small flaw, but X11 now supports the Wayland way too.

10 E just use the features of the compositing window manager. It intercepts all key presses and windows anyway.

So without getting into the merits or demerits of Wayland, it's disappointing to see the devs engaging in a colossal FUDstorm.

No one asked Henry Ford to make cars, either.

And you know what? No one asked the Stanley Motor Carriage Company to make cars either.

Simply being new doesn't mean it's better. The trouble with Wayland, or rather why I'm deeply suspicious of it is that some of the claims from the devs about waykand and X11---and bear in mind they're X11 devs too---are flat out wrong at best and deeply deveptive at worst. Why the need for a FUD attack? If Wayland is better it ought to win on merit, not FUD.

Tahe for example this article: http://www.phoronix.com/scan.p...

Going through one at a time.

1. Extensions are what X11 calls API updates. Wayland will get API updates too, so this is not an advantage of wayland beyond version 1.0.

1. A, B, C: Almost all extension version updates add new API calls and keep the old ones. Sending Foo 2.0 calls to Foo 2.2 works just fine. Not to say that versioning isn't a problem, but then fixing the API is apparently bad for X but nothing else.

2. Well core X11 is super simple and a tiny setup of Xinput 2. This leaves essentially 2 input systems left of any complexity, 2.2 and 2.0, and as far as I can tell 2.0 isn't actually separate from 2.2. So, basically X has one major input system which actually looks kinda similar to the Wayland one.

3. That's a misunderstanding of "mechanism not policy"

4. So Xorg and Xfree86 got a bit crazy and then got refactored. Apparently historical cleanups are a bad thing? This happens in any project of any age.

5. Apparently it's impossible to add a new API call for synchronisation because from (1) that X11 isn't allowed api updates unlike every other system.

6. Yeah OK, fonts are not great.

7A A badly designed chunk of Xorg is apparently a problem with X11 now. Oh and it's been fixed so it's not a problem at all. But apparently every misstep in one implementation of an X server fixed 5 years ago is a reson it's bad now.

7B That was pure fud in 2013 when it was written. Xrandr and monitor hotplugging has worked flawlessly for years.

7C Huh? There's been xrandr front ends for years which remember certain layouts. Hell, Arandr, the nice GUI point and click one in all the repos remembers layouts just fine.

7D That smells like bullshit to me. Unless the second monitor is a separate screen (X11 term for something little used now) they it'd be impossible for one to have compositing and one not. I've not heard of anyone using screens in years.

8 Yeah and real toolkits are poorer for it. The window tree is a really nice thing when you have latency. Because with tree'd systems the server remembers which sub-sub-sub window a mouse click went to, and you could ignore the absolute position. With a treeless system all you have to go on is the position.

With latency, if you click, then the display updates then it processes the click, your click goes not where you want, but where the GUI is now. This I find happens more often than I'd like in web "apps". With tree based systems, sure the widget moved, but the assignment of the click to the window was latency free, so your click ends up correctly on the now-moved widged.

IOW tree based systems are superior. Many toolkits abandoned it for compatibility with non tree based systems. What we have now is actually fundementally worse in high latency environments.

9 Yes this is finally a genuine, no-nuance flaw.

10 C this is not correct if you have a compositing window manager, because it can do whatever it likes with the final display.

10 D their solution is to make the compositor do all this shit in Wayland. That could be done equally well in X. Sure, the current convention has a small flaw, but X11 now supports the Wayland way too.

10 E just use the features of the compositing window manager. It intercepts all key presses and windows anyway.

So without getting into the merits or demerits of Wayland, it's disappointing to see the devs engaging in a colossal FUDstorm.

Example: esr.ibiblio.org/?p=1310

---------

Should sexist opensource developers have their projects censored or removed?

Recently an opensource game release story was removed due to the game developer's open sexism(0) and harrasment(1) of women in tech.

A story posted by the editor of the popular Phoronix linux news site about a release of an Open Source videogame was later manually removed(2). The reason cited was the game developer's unacceptable views on social issues such as gender equality (3).

The release story was titled "Xonotic-Forked ChaosEsqueAnthology Sees New Release - Phoronix" and can be accessed via the google cache(4).

With the recent inclusion of a code of conduct(5) for those wishing to contribute to the Linux Kernel some questions now need to be asked and answered about the inclusion of code from people who are known to engage in or promote socially unacceptable attitudes or harrasments of those whom the free-software movement would prefer to attract in their place:

* Are the social or political views of an author of free software relevant to that software's inherent quality?
* Should the beliefs of an opensource developer weigh when when evaluating whether a piece of opensource software is worthy of any publicity or public notice?
* Should men with unpopular or "forbidden" views be excised from the opensource movement and "not allowed" to contribute, in a manner similar to that which is done in employment?
* Has the free/opensource software movement changed in these respects since its founding? If so is this a positive change?
* Should there be gatekeepers to opensource that decide who may and who may not contribute. Should abusive developers be "blackballed" to maintain proper social order and controls?

and

* What are the consequences of not doing this

Citations:
(0) Past related incident: http://esr.ibiblio.org/?p=1310
(1) http://geekfeminism.wikia.com/...
(2) Removed story URL: http://www.phoronix.com/scan.p...
(3) http://www.phoronix.com/forums...
"Fortunately, the article has been removed now."
"Thanks everybody for speaking up."
(4) https://webcache.googleusercon...
(5) Linux "Code of Conflict"
http://whatwillweuse.com/fodde...

Example: esr.ibiblio.org/?p=1310

---------

Should sexist opensource developers have their projects censored or removed?

Recently an opensource game release story was removed due to the game developer's open sexism(0) and harrasment(1) of women in tech.

A story posted by the editor of the popular Phoronix linux news site about a release of an Open Source videogame was later manually removed(2). The reason cited was the game developer's unacceptable views on social issues such as gender equality (3).

The release story was titled "Xonotic-Forked ChaosEsqueAnthology Sees New Release - Phoronix" and can be accessed via the google cache(4).

With the recent inclusion of a code of conduct(5) for those wishing to contribute to the Linux Kernel some questions now need to be asked and answered about the inclusion of code from people who are known to engage in or promote socially unacceptable attitudes or harrasments of those whom the free-software movement would prefer to attract in their place:

* Are the social or political views of an author of free software relevant to that software's inherent quality?
* Should the beliefs of an opensource developer weigh when when evaluating whether a piece of opensource software is worthy of any publicity or public notice?
* Should men with unpopular or "forbidden" views be excised from the opensource movement and "not allowed" to contribute, in a manner similar to that which is done in employment?
* Has the free/opensource software movement changed in these respects since its founding? If so is this a positive change?
* Should there be gatekeepers to opensource that decide who may and who may not contribute. Should abusive developers be "blackballed" to maintain proper social order and controls?

and

* What are the consequences of not doing this

Citations:
(0) Past related incident: http://esr.ibiblio.org/?p=1310
(1) http://geekfeminism.wikia.com/...
(2) Removed story URL: http://www.phoronix.com/scan.p...
(3) http://www.phoronix.com/forums...
"Fortunately, the article has been removed now."
"Thanks everybody for speaking up."
(4) https://webcache.googleusercon...
(5) Linux "Code of Conflict"
http://whatwillweuse.com/fodde...

Sounds like one more reason to vote with your wallet and buy AMD to me, You can even get an AM1 board which supports coreboot for just $30 which will let YOU have the code so you can be assured of exactly what is and is not enabled on your system!

I've built several systems with the Am1 chips, make great HTPCs and office boxes, hell you can even do light gaming on them like Skyrim and CoD:AW if you don't mind turning down the effects.

.... I can see some bullshit DRM like thing happening in the future.

Actually AMD already confirmed a week ago that they are making a Direct Rendering Manager driver for Vulkan

The sources are still under NDA, but this was information is public thanks to AMA with LunarG. You can read it here: http://www.phoronix.com/scan.p...

Fastest will probably be 'Servo', which is the new browser engine by Mozilla.

It's a parallel browser engine, it can render multiple parts at the same time:
https://www.phoronix.com/scan....

It's also written in Rust a language probably less prone to security issues than C++ (which all the other engines are written in).

A general article about Servo:
https://lwn.net/Articles/64796...

Thank goodness LLVM is already on par with GCC

What makes you think that? Recent benchmarks show llvm/clang well behind across the board. At least it compiles faster.

and getting better much faster than it is (does GCC development consist of anything other than backporting LLVM's features these days?)

That is precisely the killer advantage of GPL over BSD license. There is no shame whatsoever in porting code if it is good. Rather, it is the professional thing to do. However it is a gross exaggeration to say the GCC team does only that.

>> Linux market share is a mere rounding error

It's at 1.7% as of last year. Compared to Windows' 85.5% share (about 50x more), the author's quip about Linux market share being a rounding error is correct.
https://www.phoronix.com/scan....
(Several other similar studies are also mentioned.)

LibreOffice won the developers so it gets many more fixes
https://phoronix.com/scan.php?...

To fix this would require moving the HID key value translations into the kernel keyboard driver, rather than having it (mostly) in user space in all three instances (X, Weyland, console).

Or just remove in-kernel VT consoles completely, and replace them with a user-space implementation.

http://www.phoronix.com/image-...
Now I know why people ask if my gnome desktop is Windows fucking 10.
sure They didn't copy this from gnome shell or any other desktop, because microsoft is a big giant group of smart people who can come up with their own ideas.

Just FYI but by simply changing from the Intel Cripple Compiler to GCC? You "magically" get AMD chips costing a third of the price trading blows with i5s and i7s, wow, isn't that amazing? And if you use real world applications (instead of benchmarks that use the Cripple Compilers) we again see the exact same results with AMD chips costing a third of the price trading blows with Intel chips. the AMD better on multithreaded and the Intel better on single thread, as one would expect.

So what can we take away from this? Its quite obvious, one company has been allowed to rip people off by manipulating the market with rigged tests (because if the tests were legit they would have to price their products more competitively with AMD) and if you ignore the rigged benches you'll find that $130 AMD competes quite well with that $300 Intel.

I've been able to back this up with what I've seen at the shop, with the i5s and i7s that have come in trading blows with the much cheaper FX8xxx chips. In fact I was so impressed by the performance of the FX8 chips when it came time to upgrade my own system I chose the FX8320E, it trivially OCs to the higher 8350 while using less power when I don't need the extra speed, and it blows through transcodes and games like a boss. Final cost for it, an R9 280, 16Gb of RAM, and a really nice Asus gamer board? $516 shipped. The kind of system you'd put together on the Intel side for that money would be along the lines of an i3, not even in the same class.

my question as a linux user is this: two years ago NVidia, after Linus flipped the bird, swore theyd make up for shortcomings in their open source driver. Has this manifested? does the linux open source driver for NVidia trumph the AMD open source radeon driver yet?

Seem like they support a later OpenGL version and more OpenGL features at least:
http://www.phoronix.com/scan.p...
"Nouveau's NVC0 Gallium3D driver for GeForce GTX 400 "Fermi" GPUs and newer has all of OpenGL 4.0 and is even advertising OpenGL 4.1 compliance as shown by the screenshots I took with a GeForce GTX TITAN on Mesa Git this morning. The Intel i965 DRI driver just has a few extensions to enable for OpenGL 4.0 support as does the AMD Radeon R600/RadeonSI Gallium3D drivers. The Softpipe and LLVMpipe software rasterizers are much further behind and will probably be a number of months before these drivers handle OpenGL 4.0."

As far as performance goes the support for Maxwell (the latest GPU generation) seem to be shit, older ones seem to be doing quite well with 15-70% or so of the performance of the close drivers:
http://www.phoronix.com/scan.p...
http://www.phoronix.com/scan.p...
http://www.phoronix.com/scan.p...

For more recent AMD cards the open-source driver is even worse relative their catalyst driver than Noveau was vs Nvidias and I guess their catalyst driver isn't as good as the Nvidia one either so go figure:
http://www.phoronix.com/scan.p...

Xonotic 0.8 1080p High:
GTX 680 Nvidia driver: 269 FPS
GTX 680 Noveau: 105 FPS.
R9 285 Catalyst: 207 FPS
R9 285 Mesa: 44 FPS
GTX 750Ti Nvidia driver: 201 FPS
GTX 750Ti Noveau: 19 FPS.

So in that one I'd say the GTX 750Ti + Noveau is doing even worse than the R9 285 + Mesa one.

R9 285 with Catalyst seem to be doing quite well there.

But step back one generation and the Kepler GTX 680 owns them all.

my question as a linux user is this: two years ago NVidia, after Linus flipped the bird, swore theyd make up for shortcomings in their open source driver. Has this manifested? does the linux open source driver for NVidia trumph the AMD open source radeon driver yet?

Seem like they support a later OpenGL version and more OpenGL features at least:
http://www.phoronix.com/scan.p...
"Nouveau's NVC0 Gallium3D driver for GeForce GTX 400 "Fermi" GPUs and newer has all of OpenGL 4.0 and is even advertising OpenGL 4.1 compliance as shown by the screenshots I took with a GeForce GTX TITAN on Mesa Git this morning. The Intel i965 DRI driver just has a few extensions to enable for OpenGL 4.0 support as does the AMD Radeon R600/RadeonSI Gallium3D drivers. The Softpipe and LLVMpipe software rasterizers are much further behind and will probably be a number of months before these drivers handle OpenGL 4.0."

As far as performance goes the support for Maxwell (the latest GPU generation) seem to be shit, older ones seem to be doing quite well with 15-70% or so of the performance of the close drivers:
http://www.phoronix.com/scan.p...
http://www.phoronix.com/scan.p...
http://www.phoronix.com/scan.p...

For more recent AMD cards the open-source driver is even worse relative their catalyst driver than Noveau was vs Nvidias and I guess their catalyst driver isn't as good as the Nvidia one either so go figure:
http://www.phoronix.com/scan.p...

Xonotic 0.8 1080p High:
GTX 680 Nvidia driver: 269 FPS
GTX 680 Noveau: 105 FPS.
R9 285 Catalyst: 207 FPS
R9 285 Mesa: 44 FPS
GTX 750Ti Nvidia driver: 201 FPS
GTX 750Ti Noveau: 19 FPS.

So in that one I'd say the GTX 750Ti + Noveau is doing even worse than the R9 285 + Mesa one.

R9 285 with Catalyst seem to be doing quite well there.

But step back one generation and the Kepler GTX 680 owns them all.

my question as a linux user is this: two years ago NVidia, after Linus flipped the bird, swore theyd make up for shortcomings in their open source driver. Has this manifested? does the linux open source driver for NVidia trumph the AMD open source radeon driver yet?

Seem like they support a later OpenGL version and more OpenGL features at least:
http://www.phoronix.com/scan.p...
"Nouveau's NVC0 Gallium3D driver for GeForce GTX 400 "Fermi" GPUs and newer has all of OpenGL 4.0 and is even advertising OpenGL 4.1 compliance as shown by the screenshots I took with a GeForce GTX TITAN on Mesa Git this morning. The Intel i965 DRI driver just has a few extensions to enable for OpenGL 4.0 support as does the AMD Radeon R600/RadeonSI Gallium3D drivers. The Softpipe and LLVMpipe software rasterizers are much further behind and will probably be a number of months before these drivers handle OpenGL 4.0."

As far as performance goes the support for Maxwell (the latest GPU generation) seem to be shit, older ones seem to be doing quite well with 15-70% or so of the performance of the close drivers:
http://www.phoronix.com/scan.p...
http://www.phoronix.com/scan.p...
http://www.phoronix.com/scan.p...

For more recent AMD cards the open-source driver is even worse relative their catalyst driver than Noveau was vs Nvidias and I guess their catalyst driver isn't as good as the Nvidia one either so go figure:
http://www.phoronix.com/scan.p...

Xonotic 0.8 1080p High:
GTX 680 Nvidia driver: 269 FPS
GTX 680 Noveau: 105 FPS.
R9 285 Catalyst: 207 FPS
R9 285 Mesa: 44 FPS
GTX 750Ti Nvidia driver: 201 FPS
GTX 750Ti Noveau: 19 FPS.

So in that one I'd say the GTX 750Ti + Noveau is doing even worse than the R9 285 + Mesa one.

R9 285 with Catalyst seem to be doing quite well there.

But step back one generation and the Kepler GTX 680 owns them all.