If this is your first visit, be sure to
check out the FAQ by clicking the
link above. You may have to register
before you can post: click the register link above to proceed. To start viewing messages,
select the forum that you want to visit from the selection below.

I would say DRIVERS... as it seems that vendors don't take so seriously the Linux...
Also, another problem that I faced recently: I have an ASRock m/board (H67 chipset) and because some bug(*) of the BIOS , the system could not properly resume after suspend, the support insisted that there is no problem 'under windows' !!
Ridiculous but this is the reality ,most m/board vendors does not even give an f for Linux.

Another issue that I have is the NTFS implementation is poor, you cannot even defrag/repair NTFS volumes...
(for various reasons I have to work with external NTFS HDDs, so a lot of times I need a PC with windows to repair/defrag the MTFS filesystem)

(*) finally the bug fixed automagicaly, as they updated the BIOS and added Ivy Bridge support...

Draftsight is only 2D and lacks simulation capabilities +its 32bits only and beta at the moment. There are things like Salome, Code aster, Open cascade but nothing is close enough to the commercial packages. Someone might say that something like this is extremely specialized etc. but IMO once people get easy access to cool tools awesome occurs.

It is not enough to have a driver, that only can print one or two resolutions with bad colours.
We need GOOD printing. And we need good printing support throught the stack. With nice preview and everything.

Seriously, linux printing is a suckfest. Everything else is bearable or even great.

Linux has no software for sharing and processing video/frames between applications (at least not like the example below, Sython). If we had a framework like this for linux, many applications could utilize it, as well as new applications could be built around it. It would basically be Jack-audio-connectin-kit for video. Something that is DE agnostic would be ideal. there are obvious uses like VJing, but i think it could be used in other ways, such as video editing / post-processing, screencasting, video-monitoring systems, VoIP - if paired up with something like Opus. Syphon for MacOSX is like this, and there are examples of applications that are built around it, if you look on the right hand side;

I think if we had some sort of Syphon-like framework for linux, that has decent documentation and a stable API) there would be a potential for lots of different types of applications to utilize, both in the home, mobile and working environments.

4) As with the package format just decide on one main toolkit. Offer the rest but have one single officially marketed and be the main toolkit for new developers to use. I don't even care which one it is as long as there is just one.

If you are talking about GUI toolkits, technically there are two: GTK and QT. Most desktops/windows managers out there use one or the other. There are also shell environmental variables which tells you which UI is up, and then execute an interface according to it.

But if you are talking about package format (the packaging itself)... That is not gonna happen.

Even PackageKit that was a nice (not my preferred implementation) way to provide a unified interface layer to package management failed miserably. The distributions that include it only use the GUI, while delegating command line packaging straight to the native one (apt, yum, etc). Most PackageKit back-ends were submitted by contributors more than people directly related to package managers in their target distributions. Like I said before, sadly companies don't care for standardization.

How badly packaging is on Linux:
1. RPM... wait, there is not 1 RPM, there are 2 RPMs lol. RPM 4.x and RPM 5, developed by independent groups.
2. DEB... only one format, but Ubuntu packages may or may not work in Debian.
3. TAR.GZ... used by some distributions (Arch, Slack), but again probably incompatible due to system differences.
Also used by sources. No way to know from outside for which distro is or if it contains source, binary or both.
4. ebuild... It's not even a binary, is a set of rules to compile a package ala BSD ports
5. PISI... Pardus format, probably made cause of the 2 RPMS mayhem, and DEB designed to required manual packaging
(read that somewhere... silly idea in an automated world), while xml are easy parsable automatically.

Thank you

Thank you Michael and Phoronix readers.

I've found some interesting projects on the Linux Foundation site(in the High Priority list), I'll see if my coordinator accepts them.
The one with "Automatic transcription" even seems very easy, except the fact that doesn't matter how much work will be put in it, it will never be perfect because of the complexity of Speech Recognition. It will always give wrong transcriptions like Youtube's caption does.

This! There were a few attempts here and there, but nothing usable ever materialised. And the proprietary ones usually don't support Linux as well as cost way into thousands of dollars.

Blender showed that it's possible to make a good alternative to proprietary 3D modelling programs, so a proper CAD tool should also be possible to create.

I'm getting tired of constantly repeating the same thing... there are two native linux programs that are 100% compatible with the DWG2010 specification and work in a way that is very familiar to AutoCAD users: BricsCAD and DraftSight. They are both closed source and BricsCAD is commercial, but still only costs about 1/10th of the price of AutoCAD. That said, an Open source equivalent would surely be very welcome!

After a few years of Windows 7, I decided to move back to Linux as my primary OS. I knew not everything would go smoothly, but I had hoped things had continued improving. For the most part, they had. I chose Ubuntu 12.04 as my distro, and things went fairly smoothly. Unfortunately, some applications and files had garbled/corrupted audio. Based on my previous experience, I guessed this was due to PulseAudio. I uninstalled PulseAudio via the software center and have not had an audio corruption issue since. However, without pluseaudio, there are NO GUI CONTROLS for ALSA. This Gnome Mixer is the best I could find, and it is terrible.

There is NO GUI to even set default playback or capture devices. Did I mention it is 2012? This is just a colossal failure for Linux.

What a GUI might look like:

Or WHATEVER.

Now, you might say, well PulseAudio does all these great things... it is the future. But if it does not output actual audio, what is the point?

There are numerous things wrong that can be fixed, so here's a short list:[*]Politics among Open Source and Closed Source.

Seriously. When you get right down to it, you have extremists that want only closed source software, radicals who want only open source software, and you got everyone in the middle that just wants everything to work.

Yes, Alan Cox, I'm talking about you in the radical group. You, and both ends of the spectrum who bang on the tables "ONLY THIS NOTHING ELSE" will get no response out of me except for "SHUT UP YOU MORON, IT'S NOT WORKING!"

Er, with your Apple bit being a valid rant, this is just stupid.

You use opensource because you love opensource and it's license. I can understand that everyone in the middle is 'stuck' in the middle and can't fully transition yet, but Alan and co are not radical, but ideal.

If your answer, as Micheal's answer was "I choose not based on license" then ... seriously, stop. Stop using Linux, stop using opensource software, you obviously don't quite get it.

This is like claiming to be an environmentalist, saying 'being green is cool'. Even separating trash properly (a small step, which is good yes) but then still go out and buy power from coal plants, because it's cheap. Why even bother? Just to bang the hot hippie chick?

The main reason to use Linux, is the license. If it's not, go use *BSD or even OS X, which is like linux/BSD, but nice and closed. Use some OSS programs because they do what you want and be quiet.

About re-implementing yet another protocol for chat/voice etc, I would say initially that that is a bad idea. xmpp works fine. Obligatory XKCD: http://xkcd.com/927/

Instead, as suggested before, a CLIENT for the voice libs, xmpp libs SIP libs would be much more needed.

BUT!

Originally Posted by darkcoder

<snip>
How badly packaging is on Linux:
1. RPM... wait, there is not 1 RPM, there are 2 RPMs lol. RPM 4.x and RPM 5, developed by independent groups.
2. DEB... only one format, but Ubuntu packages may or may not work in Debian.
3. TAR.GZ... used by some distributions (Arch, Slack), but again probably incompatible due to system differences.
Also used by sources. No way to know from outside for which distro is or if it contains source, binary or both.
4. ebuild... It's not even a binary, is a set of rules to compile a package ala BSD ports
5. PISI... Pardus format, probably made cause of the 2 RPMS mayhem, and DEB designed to required manual packaging
(read that somewhere... silly idea in an automated world), while xml are easy parsable automatically.

Ignoring 3-5, There's currently two package standards. Stubbornness goes a little stronger then evolution here I'm afraid. Both proponents say, their package format is superior. Also there's an entire userland/infrastructure around them. I'd propose, yet a nother packaging standard, that takes all pro's from dep/rpm, drops all con's from them and unites the two in one. Call it DPM and have a standard package format for mainstream distro's for once, so that the Red-Hat camp and derivatives and Debian camp and derivatives (ubuntu).

If the above can't be done, then the below is really what is needed and can be academically interesting.

- Hardware video decoding using graphics shaders / OpenCL:
For those graphics cards which have no built-in hardware support, or that we can't get it working for one reason or other (nouveau, radeon), it would be nice to have an alternative which does not rely on the CPU. Bonus points if it supports 10-bit h264, because no hardware decoder that I know of supports it. Also it would be interesting to accelerate WebM/VP8: there has been some work towards this, but no results yet, I think.