Slashdot Mirror

True, though it could be done at the distro level, which appears to be the author's plans (the person who wrote this script works for Red Hat, and discussed elsewhere in the thread what Red Hat's plans are for rolling out systemd, which will handle this). Then things would be appropriately updated by the maintainers rather than relying on users to keep their .bashrc synced with infrastructure changes.

You seem to be pretty bad at counting.

According to this page, libjpeg is not guaranteed to be binary compatible between releases.

Same for this Wayland heresy getting started over at Ubuntu. The Computer is the Network, the Network is the Computer. Just words to em, merrily breaking X and the idea of network transparency, not because it will perform better but because the ignorant fools don't realize X's network transparancy isn't the cause of the performance issues they are trying to solve. But mostly because they probably don't personally use apps remotely and don't even realize that they are tossing one of the greatest ideas in computing history down the shitter.

If you're going to throw such statements around, you better get your facts straight. The Wayland developers never blamed the networking protocol for the problems of X, but rather the fundamental architecture of X. In fact, Wayland has been built with networking in mind since nearly the beginning.

Wayland architecture

User friendliness is about being simple, not having more colors or fancy widgets - see Windows Vista as an example.

The way I see it, if Linux were to win in the consumer market, what it needs to do is not more, but less - and do those "less" things 100X better than Apple, Google or Microsoft.

The mess with X is actually being addressed, with project Wayland. The philosophy behind Wayland is exactly simplification - most people don't need that network transparency logic, so re-factor it out and keep the core simple and fast. It's a different architecture than X and so it's gonna take time to get the whole UI software stack to work on that, but Ubuntu is behind it.

Configurations and integration between services in a Linux machine is still a pain in the ass, and sadly, I'm not seeing any project addressing that yet. I used to be an open source dev but now I have a tech company to manage. But that's where I'd really like to see progress on the FOSS front.

Finally.. I think the FOSS community may be setting their target too low with Windows, and the "I don't care about consumer market/we already own the server space" crowd are simply ignoring reality. Apple and Google are beating the shit out of Microsoft's products lately - Windows and Office are pretty much still there because of inertia. Having to compare Linux to Windows, is already implying Linux is in a very bad shape in the consumer market. On a higher level, none of the current high profile players (Google, Apple, Microsoft, Amazon - who's on the server side!!, even Facebook) or products (e.g. iOS, Android, Chrome, ...) are truly independent players like Mozilla Foundation or the Linux kernel community. So, it's really not a time to be content with Linux share on the server side and bash M$, Apple, etc. as proprietary... FOSS still has a long way to go and improve.

The Wayland site has a good exposition of how Wayland and X differ at the architectural level. This also clearly explains (and diagrams) what happens when X runs as a Wayland client.

Looks like a breath of fresh air in the Linux rendering space, and someone with enough momentum behind them to drive it.

The Wayland site has a good exposition of how Wayland and X differ at the architectural level. This also clearly explains (and diagrams) what happens when X runs as a Wayland client.

Looks like a breath of fresh air in the Linux rendering space, and someone with enough momentum behind them to drive it.

Don't trust anything you read on Phoronix. Go read directly from the source: http://wayland.freedesktop.org/architecture.html

Ha, first line of that wikipedia article:

Wayland is a lightweight display server for the Linux desktop. Started by Kristian Høgsberg, one of Intel OSTC member,[1] the software's stated goal is "every frame is perfect, by which I mean that applications will be able to control the rendering enough that we'll never see tearing, lag, redrawing or flicker"

Last screenshot on the Wayland site:
http://wayland.freedesktop.org/clutter-flowers.png

Oh well, sounds interesting. Hope they have a good time reinventing all the network transparency and other features...

Wayland is a protocol for a compositor to talk to its clients

That seems to contradict you. It is from the Wayland homepage. As best I can understand Wayland moves the compositor into the server and delegates as much functionality to standard libraries (e.g. OpenGL ES).

I've never heard of Wayland before so if I've wrong please correct me. I just want to understand.

Here is the website and the wikipedia entry.

I think Linus will include DRM in the next kernel.

Bad analogy: That's not baseless. In addition, there's already DRM in the standard Linux kernel.

In the highly unlikely even that you are correct (they would literally have to rewrite OSX from the ground up to make it into the kind of locked sown system you're talking about)

Not exactly. Mac OS X 10.5 (Leopard) and later is already capable of checking the signature of an executable to know whether elevated privileges granted to an old version of an app should propagate to the new version of the same app. (See Code Signing Guide.) Currently, it works on a key continuity management basis: privileges from one version of an app propagate to another version if and only if they are signed with the same key. But this infrastructure could easily implement a policy to deny execution if the CA chain doesn't go up to Apple.

then I won't buy it. Problem solved.

Then what would you buy instead? I'm a fan of small form factor; what make and model of PC running Windows or Linux do you recommend to replace a Mac mini?

There are env variables. See example under “Settings”: http://www.freedesktop.org/wiki/Software/xdg-user-dirs

This is what the developer wrote in the commit message:

Thanks to a very clean and well-though design done from scratch,
the Direct3D 10/11 APIs are vastly better than OpenGL and can be
supported with orders of magnitude less code and development time,
as you can see by comparing the lines of code of this commit and
those in the existing Mesa OpenGL implementation.

As somebody who only has little OpenGL coding experience I can't really comment on this.

There's a workaround for 2.10 here.

The nouveau NVidia drivers are now way mature enough to deploy on a consumer OS. If you want it to move faster and become stable, contribute to the development at http://nouveau.freedesktop.org/wiki/. The RT2700 drivers seem to be a Kernel issue. See http://kernel.org/ for information on how to contribute. Ubuntu usually ships with recent kernels.

I don't really know what your problem is, but Canonical is not your nanny. They are a distribution company. Their main focus is to merge Linux based software into a nice, somewhat polished consumer distribution, and I think they do very nice work with that. Especially considering that they only employ 350 people altogether.

Now if they get profitable some time in the next years (with their business/cloud support, music store and upcoming appstore), they can hire more employees, and focus on other things too. So if you don't feel like contributing with development time, you can also buy products in their stores and support them so they get more resources and do other stuff too.

Finally: stop bitching around without moving a finger / dollar. You won't change anything with that.

I wonder if there's an opensource project to create and manage extended attributes on supporting filesystems?

http://www.freedesktop.org/wiki/CommonExtendedAttributes

But you're likely to get better results from having filenames be a field in a DB, and let all the metadata live in other DB fields..

ps: here's a CPAN entry that manipulates extended attributes: http://search.cpan.org/dist/File-ExtAttr/lib/File/ExtAttr.pm

It looked to me that there was a reason why xgl was removed.

Fedora and Red Hat provide Free Software in their repositories. It's trivial to install the non-Free drivers (and their associated hidden bugs) supplied by NVIDIA.

In addition to that Debian, Red Hat and Novell and Intel and other honest players have spent huge amounts of time coding up Free drivers with the Nouveau project (free NVIDIA drivers), Intel drivers, and ATI/AMD drivers

Sounds like the only one saying a big FUCK YOU is your self.

Fedora and Red Hat provide Free Software in their repositories. It's trivial to install the non-Free drivers (and their associated hidden bugs) supplied by NVIDIA.

In addition to that Debian, Red Hat and Novell and Intel and other honest players have spent huge amounts of time coding up Free drivers with the Nouveau project (free NVIDIA drivers), Intel drivers, and ATI/AMD drivers

Sounds like the only one saying a big FUCK YOU is your self.

Dave Airlie denies being under Red Hat mind-control in http://lists.freedesktop.org/archives/dri-devel/2010-July/001855.html It's good to see that the Red Hat drones working on the kernel are allowed (or atleast claim) to be kernel developers first and corporate slaves second.

What do you mean it's not British?

Linux has VA-API, the one true standard for hardware accelerated video decoding on Linux. Adobe should just use that and not struggle with the various proprietary vendor-specific APIs (VDPAU, XvBA, etc).

I haven't tried a GIT build recently, but as of my last attempt, multi GPU was still broken. Xorg Bug 25593

May I introduce you to http://freedesktop.org/? Their specifications mean that these "disparate groups" don't actually have to work together to interoperate.

Frankly, that's Adobe's fault, not ours.

It could be our fault if you wanted it to be:
http://www.gnu.org/software/gnash/
http://swfdec.freedesktop.org/wiki/

It's also about command space. Say you have 64k per command buffer, and flushes are ungodly expensive. Now say that immediate-mode verts need to get placed directly in the command buffer, and VBO renders cost roughly 50 dwords per 16m verts. A wise maths person might conjecture that the maximum number of verts one might expect to submit quickly in immediate mode is about 10, yes?

http://cgit.freedesktop.org/mesa/mesa/tree/src/gallium/drivers/r300/r300_render.c#n141

Evince is fast, efficient, easy to use, has all the necessary features

Except the ability to scale down images using a not completely naive algorithm, or developers who would be able to fix an issue like this within a timeframe of four years.
(http://bugs.freedesktop.org/show_bug.cgi?id=5589)

This is incorrect. I own an i740 graphics adapter and, unfortunately, it is unsupported:

http://dri.freedesktop.org/wiki/Intel

There's a driver for the card, but it's 2D only, and hasn't been improved in any way for the last 10 years or so. Of course, the card 3D performance is so weak that software acceleration on a modern CPU would probably be faster, however I was hugely disappointed when I wanted to get some 3D acceleration on one of my old Pentium 2 PC. And if you want a cheap card with no 3D or unusable 3D and free drivers, I'm pretty sure there are better options available.

• xserver-xorg-video-ati 1:6.12.6-1
• libdrm2 2.4.18-2
• libgl1-mesa-dri 7.7-4 (and the other mesa stuff)
• linux-image-2.6.32-trunk-amd64 2.6.32-5

I can play tremulous, urbanterror, and openarena normally, but nexuiz crashes the X server and the commercial ETQW and quake4 crashes missing some higher OpenGL functionality, so YMMV.
It is my opinion that this risky "develop everything anew" Gallium3D strategy will pay off, because the AMD/ATI, Intel, Nouveau and VMware teams can then bundle their efforts on the exciting higher-level "state tracker" layers (such as more recent OpenGL with GLSL for games, and OpenCL!, and maybe some kind of video acceleration or at least DCT also if they agree on which one) and only need to write modesetting and Gallium driver compiler stuff themselves.
But nobody can say for sure if all the temporary instabilities and incompatibilities will all be behind us at the end of 2010. It's good enough for me :-)

When do you think Linus Torvalds will get sued?
He installed the Gstreamer ugly plugins
https://bugzilla.redhat.com/show_bug.cgi?id=439858#c19
and ugly includes MPEG-LA patents
http://gstreamer.freedesktop.org/data/doc/gstreamer/head/gst-plugins-ugly-plugins/html/
and users have patent liability:
http://weblogs.mozillazine.org/roc/archives/2010/01/h264_licensing.html

Replying to myself - just checked and it seems to be on the list

If you configure (And you should) the Packman repository

I second that. Packman is a must have repository.
Given weird IP laws, there is a lot of stuff which Novell isn't allowed to ship inside openSUSE (MP3 support, DVD support, etc...). Packman is *the* place to get all the stuff one needs (in addition to providing a nice location for some more up-to-date software and software which weren't available in the main repo).

Though one gotcha with openSUSE 11.2 : the latest opensource drivers for ATI and nVidia aren't included out-of-the-box (no nouveau at all, and the out-of-the-box radeonhd had problems supporting my 3800 AGP, though it works perfectly with older cards), so no automagic updates of kernel along with corresponding video drivers.
Will probably come with the next release (11.3)
Until then, you'll probably have to :
- either use the proprietary drivers and assist your friends re-installing them in case of kernel update
- or use the opensuse repositories with latest opensource drivers (might require also the latest kernel which is updated quite often)
- or use something like the vesa 2D-only driver with vesa or shadowbuffer 2D-acceleration. (it's much faster than XP's vesa driver and *IS* actually usable for a user wanting only browsing web & checking mail)
- or hope the target newbie user have intel-based gfx cards (real intels, not powervr-rebranded-as-intel).

Good thing: Since 11.2, Novell tried introducing continuous update into openSUSE (so you can also "dist-upgrade" 11.1->11.2 the way you do it with Debian/Ubuntu/Mint/etc.)

The only advantage I see for Ubuntu is a much bigger and visible community around it.
(Easier to find ubuntu-specific answers when googling around)

Seconded, looking at the Mesa repository it seems as if people are working very hard to get those new drivers working.
By the way, is there any plan for a radeon r600 gallium driver or is that after r300g is done?

Why not cook up your own teleconf software? We use gstreamer which has all the 'good stuff' with x264. Check: http://gstreamer.freedesktop.org/data/doc/gstreamer/head/gst-plugins-good-plugins/html/gst-plugins-good-plugins-gstrtpbin.html . The pipeline mentioned there works surprisingly well even over high latency networks and all it takes is a shell script to launch it. Add farsight to it and you have multi-party video conf too!!

The nv driver doesn't support interlace at all and the developers refuse to implement it.

Interlace support for G8x and up:
http://cgit.freedesktop.org/xorg/driver/xf86-video-nv/tree/src/g80_display.c#n434
Interlace support for pre-G80:
http://cgit.freedesktop.org/xorg/driver/xf86-video-nv/tree/src/nv_dac.c#n169

The nv driver doesn't support interlace at all and the developers refuse to implement it.

Interlace support for G8x and up:
http://cgit.freedesktop.org/xorg/driver/xf86-video-nv/tree/src/g80_display.c#n434
Interlace support for pre-G80:
http://cgit.freedesktop.org/xorg/driver/xf86-video-nv/tree/src/nv_dac.c#n169

Just check the feature matrix

3D features are not really supported, but except that, most of the basic things seem to be supported - KMS, KMS-based FB, suspend/resume, dual head/randr, 2D, video...

Use nouveau instead of nvidia, and do Xorg -configure, and you should be golden. The big thing is that nvidia won't do multicard with non-nV hardware.

Taken from the nouveau Wiki

• Dual-head support can be configured thru the RandR1.2 and interface and should hopefully work
• 3D support is worked on using Gallium3D and can be quite usable, butAt the moment, the nv50 (GeForce 8 and up) gallium driver can actually run compiz to some extent already.

(emphasis mine) That kind of wording doesn't lead me to believe they have any idea what they're doing, or that I should expect any kind of usability of reliability out of it.

The virtual desktop in X is up to the driver to implement, it may or may not be software. In the case of the drivers for the intel 915/945 chips, there's a hardware limitation that prevents the virtual screen size from being greater than 2048x2048 (try it yourself). If I'm reading the bug reports right, newer drivers may work around this.

http://lists.freedesktop.org/archives/xorg/2009-July/046683.html
https://bugs.launchpad.net/ubuntu/+source/xserver-xorg-video-intel/+bug/383345

Though fedora emphasizes 'su' style privilege escalation which has no granularity, 'sudo' style gives the granularity required.

Um. You didn't research this very thoroughly, did you?

The whole basis for the introduction of this issue is the use of PolicyKit, which is massively more flexible and fine-grained than su *or* sudo. Both su or sudo can only run entire processes as a different UID, and have fairly limited authentication method choices. PolicyKit allows far more fine-grained granting of escalated privileges; that's the whole point of using it in PackageKit, the main PackageKit GUI process runs as an unprivileged user and PolicyKit is used to grant escalated privileges only to a subsidiary process which actually does the package installation. PolicyKit also allows far more flexibility in terms of the exact type of authentication required for any given action.

Basically, PolicyKit has all the flexibility sudo has, and far far more. Seriously, go do some reading.

According to the feature matrix, they are already done with 2D support, video playback, dual head, Xrand, KMS and suspend/resume for all the chips, which are the neccesary functions for a functional gnome/kde desktop (minus compiz), so it's not suprising that distros are starting to include it.

I notice in the release notes they're using the Nouveau driver for NVidia cards. I've been meaning to check the status of that driver for a while now -- but is this common in distros yet? (I'm a sysadmin mostly working on servers, so I'm a little out of touch. :-)

You really do not want to go there. The initial release of PolicyKit happened in 2007. The patent was filed in 2005. If PolicyKit does indeed match the claims of the patent, then all it means is that it violates the patent. It's definitely not prior art. Mentioning PolicyKit in this context just makes the matter worse, not better - you may just as well add a "so sue them" to every one of your posts.

http://hal.freedesktop.org/docs/PolicyKit/

http://hal.freedesktop.org/docs/PolicyKit/

http://hal.freedesktop.org/docs/PolicyKit/

http://hal.freedesktop.org/docs/PolicyKit/

http://hal.freedesktop.org/docs/PolicyKit/

http://hal.freedesktop.org/docs/PolicyKit/

1. Yes/no.
2. See above. Nobody cares about Shockwave, though.
3. Yes.

It's called Gnash. See http://www.gnu.org/software/gnash/
There's also a few others, such as http://swfdec.freedesktop.org/wiki/ . Gnash is probably better.