Forgot your password?

Comment: Re:Same'ol firmware separated from kernel module a (Score 5, Informative) 142

by raxx7 (#46554173) Attached to: AMD Develops New Linux Open-Source Driver Model

Not sure what you're thinking..

A Linux graphics card driver has 3 components: the kernel module, the X module and the libGL/CL/etc implementation.
There are two AMD driver for Linux -- the proprietary one and the open source one, each with it's own 3 components.

The proprietary one offers better OpenGL/OpenCL performance and features (eg, OpenGL 4.4 instead of 3.1), as well as official certification for a number of applications.
But it also tends to suffer from system integration issues, at the kernel and X level. Sometimes, they work poorly for basic things, they don't work with the latest kernel or X for a while, etc.

So, what looks here is that AMD wants to reduce the proprietary to the libGL/CL component and leverage on the open source for the kernel driver. Maybe X driver too, eventually.

Comment: Re:Not going to happen... (Score 1) 242

by raxx7 (#46393113) Attached to: Walmart Unveils Turbine-Powered WAVE Concept Truck

Yes, trains are diesel-electric.
However, it's not done for fuel efficiency; it's done for reliability.
Mechanical transmissions, like those used in cars and trucks, are too complicated and fragile at the levels of power and torque of a locomotive.
Even hydraulic transmissions are hard to get right at these power levels (pretty much only Voith managed to).

So, in the end, locomotives in general use diesel-electric. You do find a lot of diesel rail cars with hydraulic and even some mechanical.

In rail, specially on american freight rail, reliability trumps fuel efficiency by a long shot.
The diesel engines used in american freight locomotives are much less fuel efficient than most other industrial diesel engines of comparable power.
The operators would rather leave them running on idle for days than shutting them down on cold weather or fitting an APU.
They are, however, cheap to build, cheap to maintain and very reliable.,

Comment: Re:like conceeding that air is necessary (Score 4, Insightful) 279

by raxx7 (#46247357) Attached to: Ubuntu To Switch To systemd

Users rightfully do not care about what init system they use, as long as it works.
But making it work requires time and effort from some people. And we don't live in a world of infinite resources.

By announcing they're switching Ubuntu from Upstart to systemd, Ubuntu aligned themselves with the majority of the developer comunity and Ubuntu reduced the ammount of effort they and others developers have to put in to make it work efficiently as you said.
Ubuntu will not have to write and debug Upstart configuration files for services, they can just the share the same systemd files as Debian.
GUbuntu and KUbuntu developers will have less trouble to make Gnome Shell and KWin, which are moving towards somewhat depending on systemd, work on a Ubuntu derived distribution.

And that means they can actually spend time fixing other stuff.

Comment: Re:Beware journald... (Score 1) 379

by raxx7 (#46213115) Attached to: Debian Technical Committee Votes For Systemd Over Upstart

jackd is not a jack of all trades.
It's a specialized application, with a very specific purpose, that it does very well.
Making a general purpose sound server requires a different set of compromises.

"Fixing" those things in jackd means, at best, extra code to support features that are not primary goals for jackd. At worse, it means sacrificing some of jackd's critical features, such as low latency at the expense of everything else.

It Lennart tried to fix jackd, then the proverbial wrench would be thrown at his head by the jackd developers.

Comment: Re:Beware journald... (Score 2) 379

by raxx7 (#46206911) Attached to: Debian Technical Committee Votes For Systemd Over Upstart

No, jackd and pulseaudio try to solve different sets of problems.
They don't compete even the slightest. If you think otherwise, you're completely off base.

jackd is not a generic sound server, doesn't want to be and hates anyone who thinks it should be one.
jackd is a virtual patch panel for audio. It let's you take audio sources (input hardware or applications) and connect then to audio sinks (output hardware or other applications). And it does so while striving for absolute minimum latency.

But it's ill suited for general purpose.
jackd needs to be configured manually, with some detail. Eg, since jackd does not sample rate conversion, you need to select a rate.
jackd does not support hot plugging of hardware, you need to restart it.
jackd of course, will not automagically redirect your audio when you plug in your USB headset.
jackd does not provide per-application volume control.
jackd has no bluetooth support and, AFAIK, it doesn't really like the alsa bluetooth plugin.
jackd is CPU intensive.
jackd is sensitive to misbehaved applications. ...

Comment: Re:How X/Wayland work (Score 3, Informative) 204

by raxx7 (#46168381) Attached to: Gnome 3.12 Delayed To Sync With Wayland Release

You're 90% right, but the devil is in the details.
The X protocol allows applications to send drawing commands like "draw a line here, circle there, text with this font over there". You can also store pixmaps to the server and then reference them.
But these drawing commands can't draw anti-aliased shaped, so in the late 1990s X applications were either pushing lots of pixmaps or pushing so many tiny drawing commands it was worse than pushing pixmaps.

Then came XRender. XRender is based on pixmaps/gylphs, but also provides masking/blending operations on them.
This allows for better re-use of server stored pixmaps, which allowed for anti-aliased applications with less network traffic.
All in all, it's pretty slick.

But history is repeating itself and application developers are again going back to pushing lots of pixmaps. Qt developers concluded that, for local clients, their client-side renderer was *much* faster than the XRender based one and at some point made it the default for Qt4. For Qt5, they didn't bother with a XRender based one.

To top it off, whether it's XRender or brute force pixmap, modern X applications send so many commands they need a lot of bandwidth.Also, most X applications were never written to tolerate high latency connections, even though the protocol is asynchronous.
So, remote X tends to work poorly over the Internet, leading a lot of us to use tools like VNC, NX or Xpra.

The Xpra server runs as specialized X server and X compositor in the remote system, where the X application is to be run. Then it takes the contents of the X application's windown, scans for changed parts, compresses and sends it over to the Xpra client, which then draws the application window in the local system.
Since the X application is talking to a local X server, there's no latency there. And the diffiing/compressing ends up requiring less bandwidth than sending the raw X commands.

So, history has shown twice supporting drawing commands is a fool's errand, Wayland only supports pushing pixmaps. And only through shared memory, a Wayland compositor and a Wayland application must always to be on the same machine.

But there isn't anything stopping anyone from implementing a Wayland compositor that does what the Xpra server does. So, that's pretty much plan "A" for running Wayland applications remotely.

Comment: Re:On Wayland.. (Score 1) 204

by raxx7 (#46163895) Attached to: Gnome 3.12 Delayed To Sync With Wayland Release

Yes, it's possible. All you need is to implement a compositor which is actually a Xpra-like server.

And yes, it's been worked on. Support to have Weston (Wayland reference compositor) work as a RDP server has been merged.
Not sure if it supports rootless (applications only, no desktop) already or it's rooted (full desktop). But RDP does allow for rootless.

Comment: Re:NO! That's misleading (Score 1) 128

by raxx7 (#46065949) Attached to: Wayland 1.4 Released — Touch, Sub-Surface Protocol, Crop/Scale Support

No, you are misleading.

If you take a look at Wayland source code, you'll see stuff like Copyright © 1988-2004 Keith Packard and Bart Massey. quite often.

As for pushing back work to the toolkit developers, the Qt developers made the software (client side) backend the default back in Qt 4.4, because it was so much faster than the XRender based one for local clients.
And for Qt5, they simply didn't bother to implement a XRender based one.

Comment: Re: (Score 1) 611

by raxx7 (#45862127) Attached to: Bill Nye To Debate Creationist Museum Founder Ken Ham

Yes I could. Or that we're just a dream of some creature.

But that doesn't mean science is pointless.
The point in science is to have repeatable experimental results and produce reliable knowledge to advance our understanding and life.

If a christian-like God exists, then he his apparently content in letting us use the scientific process to find how the Universe he built works.
He clearly doesn't screw around with the laws of physics on a daily basis. Scientists worth the title who also happen to believe in a God are as skeptical of physics defying events as any one.

But again, we have no scientific proof that he exists or not. The christian concept of God, of a sentient all power being, makes it impossible to have such proof.

Comment: Re:Waste of Time (Score 1) 611

by raxx7 (#45853059) Attached to: Bill Nye To Debate Creationist Museum Founder Ken Ham

I'm an atheist.
However, your argument is wrong.

If there's a God, like the christian one, he is conscious and all powerful. He can do whatever he wants, including making the Universe work as if he did not exist. He can subvert any experiment you can can come up to test his existence.
The end conclusion is that it is scientifically impossible to prove that God exists or doesn't exist.
Stating that God probably does not exist is not science.

Don't take this the wrong way, but I think people who, like you, try to use this kind of pseudo scientific argument to state that God does not exist are just giving science a bad name.

Comment: Re:Daniel Stone core X.o dev on what's wrong with (Score 1) 340

by raxx7 (#45814159) Attached to: X.Org Server 1.15 Brings DRI3, Lacks XWayland Support

It has been implemented for Windows server, AFAIK.
But saying rootless RDP is network transparent is a hell of an abuse of the term "network transparent".
Which of course is the root of all this drama. People confuse rootless remote applications with network transparency and they jump in anger when they hear Wayland isn't network transparent.

Comment: Re:Can we have a discussion - not a slagging match (Score 4, Informative) 340

by raxx7 (#45812041) Attached to: X.Org Server 1.15 Brings DRI3, Lacks XWayland Support

No, this is Slashdot, you can't have a serious discussion.
It's full of idiots who don't like shiny new things, idiots who adore shiny new things and both types of idiots love to shout at each other.

Ok. Seriously.
Wayland is a new architecture for the Linux graphics stack.
It merges the role of the display server and the window manager/compositor into one piece, called the Wayland compositor.
It is envisioned that writing a Wayland compositor is not more complicated than writing a X window manager/compositor.
Buttet point: We will not have A Wayland compositor, but serveral of them to choose from: Weston, Enlightenment, Mutter/Gnome Shell, KWin.
This is made possible because a) Linux now has a proper graphic driver stack and b) the Wayland protocol is much simpler.

The new model and the simplified protocol will allow
A) better control of the input (keyboard, mice). Currently, the X window manager/compositor do not have absolute control about the input. Besides posing some security risks, it makes it hard to implement some behaviors sanely. Things as simple as being able to mute the sound when you have a full screen application running are hard to do.
Wayland compositors, of course, get all the input and then they forward them to applications as they see fit.

B) better performance (except OpenGL full screen applications which already mostly bypass X). This will come from a number of place.
- Reduced number of rountrips (W app/W compositor/kernel instead of X app/X server/X compositor/X compositor/kernel).
- Better implementation (the server isn't the fastest cookie in the world, but the protocol is so complex it's hard to do better)
- On embedded platforms (phones, tablets, Raspberri Pi) the compositor can be written to exploit hardware compositing capabilites (there's no good way to expose it though the X server).

Additionally, the Wayland protocol fixes several issues, some of which could be fixed with more extensions, some need breaking.
- Artifacts/tearing. X doesn't specify when the data sent by applications is drawn on the screen, so sometimes you get artifacts as the server or compositor draw the contents of a window in the middle of an application drawing. Wayland fixes this by making every frame perfect.
- Saner input model. The currently used X input extensions are too complicated (by the authors own admission), as they need to maintain backward compatibility with the X Core input model.
- Saner dynamic reconfiguration (resolution, orientation). Again, by authors admission, XRandR is too complicated.
- Binding versioning. Currently, if you have an application built upon components who support different versions of an extension (ie, input), it's a russian roulette on how it will pan out.

Bullet point: despite all the drama going on on Slashdot and other sites, the simple truth is that the majority, if not all, of the developers who actually put in time and effort to maintain and upgrade the server, the X window managers we use, the application toolkits, etc seem convinced Wayland is the way forward and are putting in the time and effort needed to make it happen.

Wayland is not network transparent. And despite the drama, that's OK. Nobody cares about network transparency.
People (including me) do care about having rootless remote applications. We care to have something that works at least as well as "ssh -X".
For the short/medium term, Wayland desktops will run a X compatibility server (XWayland) and most Wayland capable applications will have a X fallback mode. So "ssh -X" will just keep working.
For a longer term solution, when we get Wayland only applications, we'll need to implement something like NX or Xpra for Wayland. Which is OK too, because for many of us, it's better than running X over the network.
Despite the capabilities of the X protocol, most X applications are in fact too bandwidth intensive and latency sensitive to run remotely outside LANs. And their developers can't be arsed to do it otherwise. That's why we use things like NX and Xpra in the first place.

Comment: Re:How well does XWayland work? (Score 1) 340

by raxx7 (#45810729) Attached to: X.Org Server 1.15 Brings DRI3, Lacks XWayland Support

I can't even remember what trying to use X under Windows was like. $DEITY bless memory loss.

For Mac OS X, you have XQuartz. It consists of a modified server and a custom window manager and from what my Mac OS X wielding colleagues say, it works pretty well. I don't think it suffers of any of the issues you mention.

XWayland is expected to work seamlessly as well.

Badges? We don't need no stinking badges.