This. I can give you a list of DNF promises that were broken as long as my arm just off the top of my head. Also, Duke3D didn't end on a cliffhanger.

Half-life is not the same, the only thing we've ever been told is that the story isn't finished - the only broken "promise" is the "episodic gaming" idea - short games, regular releases - which others have done successfully. They should just finish the goddamn story already. It's really not that hard.

...and this is where our opinions part ways. Steam is their cash-cow now, so they don't actually need to do HL3, and they just don't give a shit about the fanboys who got them where they are. Valve have learned that in the corporate world giving a shit is a disadvantage - their plan is to crap on you over and over again until people get fed up with it and abandon steam. They'll only release HL3 when they need to. Basically this is as close as you're ever going to get to Gabe actually admitting "We just don't give a shit anymore".

You're not the only one.

Github's issue tracking system is damn good, and you can give it a fairly simple, configurable interface via Huboard. Set up an empty private github repo (private repos are not free but they're very affordable) for your issues, get a huboard (also not free, also cheap-as-chips) account, and away you go.

I know, I know, you said 'non engineers', and you think I'm mocking you, but that's not the case. While it's true that I'm using this solution to track issues for a technical project (and git repo), I've had a couple of fairly non-technical people lodging issues via huboard without problems for over a year now. It just works, and it's damn easy.

One awesome side-effect is that since it's tracking github issues, you can also use github's issue tracker if you are a technical person, so e.g executive level people tend to use the huboard interface (or they reply to the emails they get from github), and I tend to use the github interface. Everybody is happy with it.

I don't know all the details about your specific needs but I think that huboard is probably configurable enough that you could make it work for you. I would certainly recommend at least checking this combination out - it's cheap and works well. If you contact huboard they might even give you a free trial so that you can properly check it out, or it might even be free for public github repos, I forget exact details. But the huboard guy was very reasonable to deal with in my experience when I set it up.

Aha, helpful!

To be clear, though, I'm not just talking about xine playing DVDs, I've never had any problem playing anything with xine. But then most HD stuff tends to be h264. I might have to go find something encoded with VC-1 and try to play it in xine, see if it handles it.

Thanks muchly for the info, it's nice to just be told the answer every once in a while!

It's a 1G GeForce 8800 GT. Getting old now but still very capable - as I said it runs things like Metro Last Light just fine, there aren't many games available for linux that it struggles with, borderlands is the only one I can think of of the top of my head where I've had to turn detail down. I'm using nvidia drivers. xine uses vdpau and runs brilliantly, so vdpau is available and works. And yeah, I know enough to stay well away from compiz, I'm using xfwm with compton for compositing.

I did investigate at the time but didn't come up with anything. It was a while back now, not long after the "netflix html5 linux" articles appeared on the web. It might be worth another look now that things have had some time to mature.

Fair enough, I did get my rants crossed there.

So netflix doesn't offer any way to actually buy movies then? I guess that makes them entirely unsuitable for me.

As discussed above, no it doesn't.

What I really want is to be able to buy a digital copy. Like going to a store and buying DVDs, but without the whole "getting up from the couch" part.

Or you have a separate hifi system. But now I'm just arguing semantics for the sake of it. My point is that I'm not interested in spending money on redundant hardware.

I don't need them either to just watch movies, play music, etc, but I like them (especially wireless ones) and use them often. This machine just happens to also double as a real computer - dev environment, web browser, all kinds of stuff. Coding from my couch is great. To each his own.

It depends on what you want to use it for. I tend to actually multitask. The big screen helps with this, leave a documentary running in a window and look up a wikipedia article, pause deadwood and reply to a slashdot post because you've got nothing better to do. To me, unitasking environments invariably feel restrictive. But again, to each his own. ;)

...which reduces the demand for Linux support, making it even less likely than it is, doing everybody a disservice in the long run. And it's not like I don't have the experience I want already, I just can't buy that experience. Plus, complaining is fun! :P

Fair point. If it actually worked well enough to be an acceptable movie watching experience, this is probably doable.

Yeah, I don't know what's going on other than neither chromium or firefox will play any video at a decent framerate. On a machine that will run things like Metro: Last Light just fine. I did try to look into it a while back when it was new, but gave up after several hours or google futility. IIRC It did seem to indicate that it was using html5 when I looked into it. It plays okay if I'm just watching youtube videos, maybe ~20fps, but it's noticeably glitchy compared to a proper video player / DVD and not suitable for home cinema.

It's worked just fine for me for playing all kinds of videos, SD and HD, and music, in every format imaginable, for about 15 years now. I'd even call it "ideal" - I the same buttons on my remote mapped various functions on multiple applications via LIRC, so everything behaves consistently and works wonderfully. It looks really nice plugged into my projector and running at 1080p, and it sounds great running through my surround sound system. In fact it's better than any other experience I've ever had - you can't smoke in a cinema, and being able to skip the copyright warnings on DVDs is worth a lot - people marvel at this ability the first time they see it, and the lack of it chafes me hugely whenever I watch a movie at a friend's house. Hugs to the xine devs. It even still plays all my old VCDs (though these do look a bit blocky these days and have been mostly replaced by DVDs now).

So your advice is that I go out and spend money to buy new, additional, dedicated hardware to do something that I already have dedicated hardware for? Yet another device to sit next to a machine perfectly capable of doing the same job, taking up power and precious space on my desk? More cables to add to the cable soup behind my desk and more things to plug into the already-crowded input ports on my projector and hifi? I don't see any problem with that logic. I don't suppose that you happen to work for this Roku crowd?

You mean apart from the lack of LIRC support, massive resource use, and pathetic framerate these "hardware accelerated" (yeah, right) solutions provide?

This has been making the rounds of all the tech sites in the last couple of days.

And yet here I am unable to use netflix on my dual core 3ghz machine intel machine with 8gb RAM, being labelled "thief" because I choose not to settle for a substandard experience and because I'm not interested in re-downloading Alien every time I want to re-watch it, all because Netflix can't be bothered releasing a Linux client.

It's nice to see they have their prorities straight.

Before anybody suggests it: browsers are for viewing web pages, not playing videos.

hehe, life is like that sometimes. Fair enough, a valid use! Just to clarify, I'm guessing you must be plugging these 3 devices into 3 different line-outs, and letting pulse manage the volumes separately based on which output / channel (i.e left/right) you're talking to? If not, how does pulse figure out which device it's talking to and thus which volume level is appropriate?

I'm struggling to wrap my head around a single instance, I don't think I want to know about multiple instances! ;)

I was thinking to myself before that 'bass boost' must be the bane of your existence. Voice and data at the same time? neat! Though now that I think about it, it seems obvious.

That is one impressive setup. Weather stations, remote controlled rotating antennas, wow! I'm not going to pretend I understand what all those components are.

aha, that makes sense.

I'm with you, what's important is getting the job done. Audiophile snobs love to give me shit because I prefer FL Studio over Reason and Cubase. It's not hardcore enough for some, no street cred. Whatever, it does the job.

I wouldn't be suprised - the one thing I do know about hams is that they're innovators and inventors. Though "mid-2000s" seems relatively recent for you guys. :) But maybe not for people with multiple devices.

Yeah OK, pretty much what I thought. So you actually have a valid reason for actually choosing pulseaudio! Nice to meet you!

It has been really really refreshing to talk to a pro-pulseaudio person who is interested in rational debate and actually discussing the issues! :)

but you very clearly did not.

Aaaah, right, so end users don't matter! now I understand where you're coming from completely!

Wow, this is some strange new definition of the word "choose" of which I was previously unaware! Been working for the NSA, have we?

Why would I bother trying to understand such a distorted perspective, where 'it was forced upon me' is equivalent to 'I chose it'?

Wow, you demonstrate your ignorance very succinctly here, assuming that the applications even know that they're using pulseaudio in the first place. Perhaps you should read up on how this stuff actually works? Hint: almost nothing "falls back" on alsa, it uses alsa as its primary API and pulseaudio subverts that. OSS? have you even tried using an OSS app in the last 5 years? If you had, you'd realise that it's not this trivial, at all. Why don't you get back to me when you have Unreal Tournament 99 running on a modern distro?

Aah, right on cue: here come the ad hominem attacks based on no information at all and containing a bunch of assumptions. You must be a lennart supporter! Or perhaps even a pulseaudio dev? Do you work on systemd too?

* What names did I call the developer?
* What attack vector did you use to log into my machines and determine that they're all running pulseaudio and that I haven't made the choice for myself long ago? (hint: I think you must have been looking at the wrong IP, because your conclusions are deeply flawed)
* Thanks for edumacating me! Here I was thinking that things I have learned through years of personal experience constituted "knowing how my computer works". I'm glad that you have shown me the error of my ways! From now on, I'll just cancel all my tech magazine/website subscriptions and read lennart's blog instead - I'm sure it contains everything I need to know to "figure out how to use Linux".

This is laughable on so many levels. So what you're basically saying here is "that software you've been relying on for daily use for 10 years now, you don't really need it". Because you know so much better than these users you have nothing but contempt for.

Don't worry, I'm sure your little project will crash and burn sooner or later because of your attitude, and then we can all get back to using sane systems. In the meantime, I'll be over here using the alternatives and watching on in fascination as you give me example after example of how to drive users away. ...go on, say it: "We're not interested in how many people use our software", I dare you...

Your attitude towards your users and anybody who has a different opinion is contemptible. This is why people like Linus refuse to work with you.

Interesting. I wish you had rhapsodised about the tech more!

I confess that I did skim those docs a bit, and I know nothing about ham, so I'm willing to accept this as a valid point / use for pulseaudio (congrats, the first one I've ever seen!). I'd be interested to know more about how it works, given that it's all the same program (isn't the "remember volume" stuff per-program, so wouldn't it just remember the last-used fidigi volume? How does that work with multiple app instances? or are you switching between multiple outputs/soundcards? As I said, I could never get that particular feature to work, and I tried). I guess I'll have to go back and not skim this time, there goes a couple of hours researching something I'll never use ;)

Curious - is this a feature of the radio, or is it caused by the DAC in the soundcard? My real question is: "would a better sound card reduce this problem at all? (obviously it's never going to go away completely)".

uncompressed? with pulseaudio?!? I assume it needs to be uncompressed/lossless if you're feeding it into fidigi (or maybe not, given noise-resistant codecs)? But wouldn't some kind of FLAC streaming system be much more bandwidth-efficient? Are these basically working as repeaters, letting you get more range? That's a neat idea.

I'm not convinced that you couldn't get the same or better results for all this using ALSA or some other existing tech (or maybe hardware), and hams don't represent the majority of people, but I'm willing to concede that doing so would probably require a lot of custom code in the app, hence time, effort, and maybe initial configuration / hardware expenditure and so in this example it's a "path of least resistance" and an acceptable compromise if it does what you need and that therefore there is a group of people out there who have actively chosen pulseaudio for justifiable reasons. I'd be very interested to know how it worked before pulseaudio came along - lots of manual adjustments with alsamixer? had the thought of adjusting the volume / having profiles in-app been considered?

Audio production is what I'm interested in (we're not the majority, either), so I rarely adjust soundcard or software volume (in fact, I work to stop that from ever happening in order to minimise distortion - amplification should be done by [good] hardware, not software, this is what I wanted the 'remember volume' feature for), I move a slider on my mixer to set volume. Latency is important, and software mixing rather than using my good sound card is complete evil. So in my experience pulse is the devil. When I asked the pulseaudio people why they chose to do software mixing even though my soundcard does hardware mixing, I was basically told that this is an edge case, they don't care about that scenario, pulseaudio isn't intended for me, and I shouldn't be using it. And don't get me started about the CPU usage the software mixing requires, or the time I tried to use pulseaudio on an 800mhz duron machine (5% CPU at idle, ~20% playing audio).

I'll leave you with this little nugget from my .bashrc (unnecessary these days since I purged pulseaudio):

function fucking pulseaudio needs restarting again i guess you must be using fl studio in wine() {
        echo -e "\nKilling pulseaudio (nice)..."
        pulseaudio -k
        sleep 1
        PID=`ps aux | grep [Pp]ulseaudio | awk '{print $2}'`
        if [ -n "$PID" ]; then
                echo "Fat lot of good that did!"
        else
                echo "OK!"
        fi
        echo "Starting Pusleaudio..."
        pulseaudio >/dev/null 2>&1 &
        #echo -e "OK\n"
        ps aux |grep [Pp]ulseaudio
}

(there are underscores in the function name, i.e "fucking_pulseaudio_needs..." but slashdot seems to think there's something fishy about it: I get "Filter error: That's an awful long string of letters there". Apparently normal people don't create functions with names like this.)

Le sigh.

OK, I'll indulge you by explaining how you had no point for me to miss, because you missed mine first. But I'm afraid I won't be able to restrict myself to two syllable words, so you might want to grab a dictionary (and a coffee to help wake you up) before we start. Ready? OK, here we go - strap yourself in.

My point, which you seem to have completely missed with your nonsensical "argument", which actually just restates the core of my point, is that very very few users actually choose system software at this level. You don't find users typing in 'apt-get install pulseaudio' or whatever, it's installed as default software when they install or upgrade their distro. That's why "everybody" is using it, not because they chose to. The fact that "everybody" uses it is the result of a few distro maintainers, not the users. The users couldn't care less, they just want something that works. And if they're using a laptop with a terrible integrated sound card and not doing any kind of quality audio production or working in an environment where latency actually matters then pulseaudio certainly seems to work. Except when it doesn't. The number of people who choose a distro based on the fact that it includes pulseaudio is extremely small, perhaps even zero. Users choose a distro based on look and feel, preinstalled applications/codecs, how easy it is to install, whether it works on their hardware, and perhaps most commonly on a friend or colleague's recommendation (which is also not based on the audio subsystem). They don't choose it because they want such-and-such init system or audio subsystem. They just want to get things done. If we go for the good old (flawed as always) car analogy, saying that everybody chose to use pulseaudio is somewhat like saying that everybody chose to drive cars powered by fossil fuels.

The converse, however, is not true - there are users who choose to avoid certain system software - people who go out looking for a distro which doesn't include pulseaudio (or systemd, or whatever) because they specifically don't want that software for whatever reason (like maybe it sucks ass, hogs resources, and is completely unnecessary given their particular hardware configuration).

The people who choose to use stuff like this are the exception - they're the experimenters and/or testers, they're not basic users. Granted, some of them might be developers, but they're not necessarily developing anything even remotely related to the system they've chosen to experiment with. They're simply people who said "maybe I'll check out this new sound server". And they are almost certainly not choosing to do this on their reliable, production-grade, daily-use-for-getting-audio-production-stuff-done machines, not unless they have an easy way to quickly restore system snapshots or are particularly good at solving problems. Or just plain masochistic.

Which brings me right back around to my original point, which you somehow seem to have missed entirely: Almost nobody actually chose to use pulseaudio, they had it installed by default for them because distro maintainers chose it for them, for whatever misguided reason (Like perhaps they didn't notice that that particular piece of software doesn't support a particular hardware configuration until after they'd made the choice, at which point the developers of the software in question said "we can't be bothered thinking about that, it's an edge case, who cares").

Your argument that "ALSA and OSS APIs are still there" is totally irrelevant - the OSS APIs are provided by ALSA as a backwards-compatibility thing, and ALSA is required for pulseaudio - without ALSA installed, pulseaudio won't do anything at all (OK, so perhaps it can still stream over a network, but I expect it's far more likely that you'd get an error saying something to the effect of "ALSA is not running, exiting" from the pulse daemon). So ALSA can't just go away. As is your argument about pulseaudio's "modern featureset", which if you knew anything about the subject you would know was already entirely available via other sources such as ALSA modules (dmix for software mixing, others for bluetooth) or systems like JACK (network streaming, per-application volume controls).

Or were you stuck on "developers"? Were you trying to assert that people are using the pulseaudio API more than tha ALSA API? Because that's just not accurate - ALSA is still by FAR the dominant audio API for developers to code against and many many MANY more applications support ALSA than pulse. Though ALSA does get some stiff competition in the pro-audio space from JACK. I don't think I've ever seen an example of an application where pulseaudio is the only supported audio framework, certainly not one in widespread use...oh, OK, fine - pavucontrol. But that doesn't count.

Wow, you're really not paying attention, are you?

Interesting, thanks for the link! :)

but:

Which isn't the same as saying "it's better than the alternatives". Sounds to me like this person is trying to make things easier for users and possibly himself (e.g not requiring dependencies on rarely-installed libraries/daemons, e.g jack). But that's not the same thing as building the best solution.

Question: does this software need care about latency? Because if it does then this person's opinion might carry some more weight, I'd be interested to know how they think pulseaudio compares with jack on those terms (hint: jack doesn't suck ass or waste my CPU time doing things which I can do in hardware). But I suspect that latency isn't really that much of a big deal with regard to this application, you're probably spending hundreds of milliseconds just waiting for the response from the other ham anyway, right?

And I wouldn't exactly call it a "recommendation":

That's saying "use pulseaudio if you're already using it", and implies "You're probably using it, because you've probably upgraded your distro in the last few years and thus had it installed automatically, possibly without your knowledge". This is not the same as recommending pulseaudio. In fact it reinforces my earlier sentiment.

They do say that pulseaudio has "a few interesting features":

ALSA can do that too. Or you could just get hardware that doesn't suck.

JACK (which this software also supports) can also do this, and it does a much better job of it than pulse.

ALSA and dmix, or, again, decent hardware (for extra bonus points, go research what pulse does when you have multichannel hardware. Hint: software mixing, because apparently lennart knows better than creative labs).

"man alsamixer"; JACK. Noticing a theme yet?

Yeah, I've read that it's supposed to do this, but I've never seen it actually do it on any system I've ever used. And I did try, ad nauseum. Strangely, the pulseaudio documentation doesn't (or at least didn't back when I cared) see fit to mention where this information is stored, so e.g trying to manually get a certain app to remember its volume or output to a certain device by e.g editing a config file (since it doesn't seem to remember it as advertised) wasn't something I could manage to do. And I tried, oh how I tried.

No, that's fine - it supports something other than pulseaudio, just like any sane piece of audio software does. If they want to tear their hair out messing with pulse then who am I to tell them otherwise?

Indeed, the page you linked to starts out with:

And, finally, the snark in me is forced to comment that "one" and "many" are not the same thing. If we're talking about software support, I think you'll find that ALSA is far FAR more widely used (I've said before and I'll say again: the best thing about pulse is that it can present itself as ALSA, discouraging development of pulseaudio-specific applications and ensuring that I don't switch back to windows and/or commit ritual suicide). And if we're talking pro-audio apps, where it really matters, JACK is king.

But thanks for playing! ;)