OSNews

Ctrl+Alt+Backspace is disabled by default (what?!?). thats been disabled in OpenSuse to i think, an is also disabled in Fedora11

Hmm, so in this case Ubuntu is just following. Either way, I don't really like the idea of that. How easy is it for someone who doesn't even know about the command to "accidentally" hit that combination, anyway? It's pretty well out of reach, I think, unless they meant Ctrl+Alt+Del and hit Backspace on accident. Not to mention, killing the X server, etc. has some very useful uses. It's possible to revert this change, but still not good as a default IMO.

It's not disabled (At least not in openSuSE) you just have to press CTRL+ALT+Backspace twice, within 5 seconds I think :-)
I'm actually pretty happy about it because of lack of patience I acidentially hits it a bit too often :-) the extra 5 seconds make you think once more if you really want to do this :-)

Ctrl+Alt+Backspace is disabled by default (what?!?). thats been disabled in OpenSuse to i think, an is also disabled in Fedora11

I have OpenSuSE running on my G5 and nope, ctrl+alt+backspace has not been disabled. Works as expected.

It's from upstream, x.org, you can re-enable it in the config (that by default does not exist) if you want.

Ctrl-alt-backspace is a X.org change and has nothing to do with Ubuntu (or other distributions). You can re-enable it by adding:

Option "DontZap" "off"

to the ServerFlags section of xorg.conf.

I believe they changed this because of the number of bug reports about people accidentally killing X (which can cause data loss).

Most Operating systems(Ubuntu since Hardy I believe) have stopped using xorg.conf at all. Because of that, it has become very difficult to modify a single option without breaking everything else.

At least to me it sounds like a very bad idea.

Times I clicked ctrl-alt-backspace without meaning it: 0
Times I clicked ctrl-alt-backspace because everything else was unresponsive or very broken: 10+

Disabling Ctrl+Alt+Backspace is a very bad idea. I find this very irritating. If they want to make it accident-safe, they should give us some type of time-delay feature for instance holding down the Ctrl+Alt+Backspace key combination for 5 seconds before it goes ahead. How do you re-enable the expected behavior anyway?

Edited 2009-03-27 08:10 UTC

Times I clicked ctrl-alt-backspace because maybe nothing more than Xfce froze, but I didn't realize it was disabled so I came to the conclusion that the kernel locked and hard restarted: 4+

If you really want CTRL+ALT+BACKSPACE functionality, why not do CTRL+ALT+F1 to get to a virtual console and then pkill the xserver from a different text-mode login? Does this not work anymore?

Usually, however sometimes when you kill the X server from a console it doesn't release the console it was running on and keeps that console in graphics mode, but will not re-use it the next time the X server is launched. Not really a big deal I suppose, but it's not exactly a clean shutdown either. Plus, some display managers don't handle that very well and won't always relaunch the X server the way they're supposed to.

Do you know if that (i.e. X not releasing the console) is going to get better as kernel modesetting becomes more broadly applied?

No idea, it doesn't strike me as something kernel mode setting would fix. Rather, it seems that the console release is part of a shutdown procedure in the X server that is activated when you press ctrl-alt-backspace, and sometimes is not activated when killed from the console, probably depending on what signal is sent to it among other things--I'm not an Xorg developer, so can't say what other conditions may determine it. For instance, a SIGTERM will usually, but not always, allow the release of the console, whereas a SIGKILL will not (no surprise, seeing as SIGKILL is designed to immediately terminate the process without any proper shutdown).

Well, that's not really CTRL+ALT+BACKSPACE functionality. That's switching virtual terminals, logging in to a text console, and running a command line under sudo, after providing a suitable password, to kill the X server. What's the difference? Ask my nontechnical users. :-)

It's not needed often. But they know that if all else fails, they can CTRL-ALT-BACKSPACE. This is an "improvement" that I will definitely be reverting.

Edited 2009-03-30 00:02 UTC

If the dumbing down bothers you, just use Debian.

Here's a free tip: if you don't like it use another distro.

Root is still very much available if you want it;I think that the sudo option is actually more suitable for most users (and uses) in any regard.

Unless I misread you, you do agree that rm -rf / is not really a feature worth having.

Finally, it is clear that CAB is still available for users who want such things. Considering that most users don't even know that it exists and that accidentally triggering it can cause you to lose your session, it is no wonder that some people think that turning it off by default is actually a good thing.

Basically, from the evidence you provide, I can't see the logical connection to your conclusion that Ubuntu is heading in the same path as Windows and moreso that they will end up in a situation exactly similar to the one in Windows.

Please back up your claim that 'most users don't even know that it exists.' This is a pretty common feature of X we're talking about here, and I don't think most Linux users (even Ubuntu users! though this is an upstream issue) can be classified as that clueless.

I'm still having problems using Jaunty. Every time I switch on my bluetooth headphones pulse crashes and cannot be restarted properly without logging out and back in. I agree this is getting very old.

I agree the Pulseaudio problems are getting very old. Pulse has a lot of potential, but imho it just is not ready for prime time yet and probably won't be for a while. They need to buckle down and make stability a top priority; I don't care if I can send an audio stream to a different computer or device if it's an iffy proposition whether the audio will even play correctly in the first place. I'd rather have the thing play properly than all this ridiculous amount of networking functionality set on top of a less-than-solid core. The networking functionality is cool and everything, presenting some interesting possibilities for home entertainment systems, and the per-application volume feature is also nice and is one of the few features that actually works well. But I'd rather they ditch all that for stability, then put all these features back into play.

Try:

$ sudo apt-get remove pulseaudio

It aleviates all the audio problems that I have seen, eliminates all the perceptible latency, has resulted in *zero* reduction in functionality that I can detect, and has saved a little memory as an added bonus. I highly recommend it. For whatever reason, adopting Fedora technologies always seems to be bad news for little gain.

Why did we "need" pulseaudio, again? None of the reasons I heard ever made any sense.

Edited 2009-03-27 17:14 UTC

Unless, of course, your sound card either does not do hardware samplerate conversions, or does it poorly. Quite a number of onboard audio chips have this issue, and without an audio server such as pulse, this introduces various artifacts and pops into the audio depending on what your card's hardware parameters are versus what the currently playing sound is. ALSA's facilities for dealing with this problem are minimal, and that's being generous.
Pulse's purpose is to be the layer between the driver and the application, handling all conversions and mixing in software as well as providing application-specific audio streams. I really believe it has enormous potential and eventually we'll wonder what we did without it. Remember, ALSA was crap once too--still is, at least as far as the API goes, but at least it's stable. Pulse's major problem is that it's just not ready to be used by default in mainstream oses--it has latency issues, can be unstable, and some applications just out right don't work properly with it due to its ALSA plugin and OSS wrapper being incomplete. They should have given it another year, at least, before forcing it into the mainstream distros, or at the very least made it an optional configuration choice. It's a nice concept, it's just not ready, they should have let the Fedora users deal with it for a while longer .

Yes. A few people with inferior chipsets have a problem and the rest of us get to suffer for it. During OS installation or boot up, if a faulty sound chipset is found, Pulseaudio should be loaded. Otherwise not.

It's just common sense. Some people have cancer. That doesn't mean that we should all be subjected to radiation treatments and chemotherapy.

When pulse is finally ready for primetime, which looks like its going to be a while, I wonder how many people will even need it? Why drag everyone through years of pain trying to "solve" a temporary hardware problem, experienced by some, by band-aiding over it with a perpetually unstable piece of Fedora software?

Edited 2009-03-27 19:16 UTC

I bet to differ, but it's much more than a few bad chipsets. It is, unfortunately, most integrated chipsets these days. They don't have true hardware mixing, if any, and ALSA's Dmix has troubles of it's own--it has poor conversion quality, retains the audio buffer for longer than it should resulting in a delay before audio is actually stopped, and introduces clicks into the audio even on some of the better chipsets. The only chipsets immune to these problems are those that have hardware mixing, and they seem to be growing more rare by the day.
I think whether you need or even want Pulseaudio depends on what you're doing with audio. Personally, I like the app-specific volume controls and the fact that audio stops playing when it's supposed to, rather than Dmix ridiculous approach to it. I think the better solution would've been to go with OSS once it became open source and work on its drivers--it had a much better API and a much better software mixing algorythm. Unfortunately, since ALSA is such a piece of crap, we need to put another daemon on top of it since no one seems to want to take care of this in the ALSA driver itself. In fact, the kernel developers don't want Dmix enhanced, claiming it doesn't belong in kernel space and should be handled by Pulseaudio.
If Pulseaudio doesn't get better, Linux audio will always be in a sorry state unless some serious rethinking is done on the driver level.

Well, I tend to buy inexpensive MBs and I have not noticed any problems. Do you have some list of problematic chipsets? "Most integrated chipsets" is a pretty broad claim to make without some evidence to back it up.


I've never noticed any of this on my boards.


No pulseaudio running here. And I just now adjusted the volume of NASA TV running in Totem, without affecting the volume of the Magnatune Compilation album running in my Epiphany. Paused Totem, and the sound stopped when it was supposed to. All on my Low end Intel G43 chipset board. No clicks. No pops. No delays. No distorion. No poor conversion quality. None of these FUD points are observable here. I used to have problems. But all the latency, skips, distortion, and mysterious instances of sound just going MIA for no apparent reason magically disappeared when I ousted Pulseaudio from the OS.


Sound, after years of turmoil, had finally stabilized very nicely, and had worked stably, well, and reliably for most of us for a couple of years before PA showed up on the scene. The solution is NOT to rip everything out and start over with OSS. It is to remove the malignant growth that is PA and go back to the stable and functional configuration we had before, and which I have now.


Linux audio is only in a sorry state right now because of pulseaudio.

Let's just dump it and be free of it!

Edited 2009-03-27 20:05 UTC

I have all the anicdotal evidence you could want, which is all you can really find on this issue, as some people's needs regarding audio are greater than others. Here, for the record, is a list of all the chipsets I've had these issues with:
* All chipsets based on the Ensoniq 1370 and 1371 architecture
* Realtek: ALC650, ALC880, ALC882, ALC1211
* nVidia nForce: nForce 3 all chipsets
* All Via vt82xx chipsets
That's all I can think of right now, I didn't keep a running list over the past several years though perhaps I should have. These are the ones I've run into most recently (ens1370 is rarely used anymore, except in VMware where that is the chip that is emulated).

I've never noticed any of this on my boards. "
I suppose that depends on what your needs for audio are. I certainly notice Dmix's latencies, though if you're only playing music or flash videos I suppose you wouldn't notice much.

No pulseaudio running here. And I just now adjusted the volume of NASA TV running in Totem, without affecting the volume of the Magnatune Compilation album running in my Epiphany. Paused Totem, and the sound stopped when it was supposed to. All on my Low end Intel G43 chipset board. No clicks. No pops. No delays. No distorion. No poor conversion quality. None of these FUD points are observable here. I used to have problems. But all the latency, skips, distortion, and mysterious instances of sound just going MIA for no apparent reason magically disappeared when I ousted Pulseaudio from the OS. "
You know, just because you don't notice something doesn't make it FUD, though you do seem to call on that word when you're getting desperate to prove something you cannot. For the record, since you do not understand what I'm referring to, I'm not referring to applications like Totem that can adjust their volume independently. I'm referring to those that cannot, ever get annoyed by a web video that blasts your ears out, for example? Or a game that doesn't have volume controls? It is these applications to which I refer, and for which application-specific volume controls and mutes are useful.

I said would have been not would be. I fully realize this isn't the optimal solution now, it's too late for that, and now we have to do what we can to correct it. Tell me, why does audio in Windows or Mac OS X work so well? I'll tell you: because they have a full software mixing solution. Pulse is not ready, I've said that over and over again, and Ubuntu should not have included it as default yet. But I'd rather see progress than stagnation, and ALSA is stagnating under its own complexity and limitations some of which are imposed by the kernel developers.
In either case, I can see we're not going to agree on this, so let's agree to disagree, ok?

Just use KDE4, no pulseaudio in sight

I'll kill you later.

Rational or not, it is nevertheless a major attractive feature that KDE does not include nor require Mono.

See "Microsoft vs TomTom" for hints as to why this might be so.

http://ldn.linuxfoundation.org/blog-entry/microsoft-vs-tomtom-aband...

Edited 2009-03-27 02:27 UTC

You think MS will eat my kids? I think you need help.

Meanwhile, have you read the license terms for some parts of .NET, such as Windows.forms? (Hint: unlike C# and CLI, Windows.forms is not an ISO standard, and was never offered as such).

http://en.wikipedia.org/wiki/Windows.Forms

PS: AFAIK, Xubuntu also does not include Mono.

Edited 2009-03-27 02:39 UTC

Why?

Currently, on standard GNOME Ubuntu, Mono enables the following applications: Banshee, TomBoy Notes, GNOME Do, Beagle and F-Spot.

Amarok, BasKet Notes, Krunner, Strigi and Digikam have those applications well covered.

Ergo, no need whatsoever for Mono.

none of those mono apps are installed by default on any gnome install i've seen and that includes using meta packages. (granted i only use debian so i'm not aware of other distro's)

there are also non-mono gtk alternatives for those applications so just because there are apps with mono dependencies it doesn't mean you have to use them when you use gnome. just remove it and move on with your life.

Edited 2009-03-27 04:59 UTC

Then don't use Windows.Forms

There are many OSS widgit toolkits for C#.

One cannot avoid any potential issues by "not using Windows.Forms" if one has Mono installed, because a Windows.forms implementation is inside Mono 2.0 whether one uses it or not.

Sure you can. Really, your hatred and FUD tactics about Mono are getting old fast. Whether there is a Windows.Forms implementation inside Mono is irrelevant if you don't use it. Even should Microsoft demand its removal, it won't matter to your application if you didn't develop with it now will it?
Microsoft could not win any kind of law suit against the basic Mono core itself, as the C# language and CLR have been approved as an open standard by ECMA. If they didn't want anyone else implementing it, they shouldn't have submitted it as a standard.

Agreed, what's the problem, Mono is perfectly free/open source software.

Mono applications are slow as hell, that's the problem.

Mono is FOSS that uses patented MS technology. Some of that has been standardized under OSI but *much of it has not*. Even the OSI stuff only stipulates that it be licensed under RAND ("reasonable and non-descriminatory") terms which means they could charge which would be the end of mono and applications using it.

To the later poster saying anti-mono is irrational, the only thing that is irrational is people like you defending it without knowing what they are talking about.

The only official guarantee they have that .net technologies will not be restricted in the future is an informal post on a mailing list by one of the senior c# developers.

There have been many detailed write ups on this but it seems like the real crazies have won this shouting match.

It is not irrational to *observe* (not opine) that MS is a predatory company and dealing with them is dangerous.

There I agree.
Richard Stallman:
Mono is a free implementation of Microsoft's language C#. Microsoft has declared itself our enemy and we know that Microsoft is getting patents on some features of C#. So I think it's dangerous to use C#, and it may be dangerous to use Mono. There's nothing wrong with Mono. Mono is a free implementation of a language that users use. It's good to provide free implementations. We should have free implementations of every language. But, depending on it is dangerous, and we better not do that.

There I agree.
Richard Stallman:
Mono is a free implementation of Microsoft's language C#. Microsoft has declared itself our enemy and we know that Microsoft is getting patents on some features of C#. So I think it's dangerous to use C#, and it may be dangerous to use Mono. There's nothing wrong with Mono. Mono is a free implementation of a language that users use. It's good to provide free implementations. We should have free implementations of every language. But, depending on it is dangerous, and we better not do that.
"

Your quoting Stallman only makes me want to use it.

... with an indemnity from Microsoft when it is run on SLED or Windows.

Run it anywhere else ... then Microsoft claims patents on parts of it, and royalties due to them.

ummm... dude... he wasn't being political about it. mono *is* unneeded for kubuntu. sheesh. how many qt/kde apps require mono? rawr!

Synapse, a start of the art instant messaging client is a good example of a Qyoto program written in C#:

http://synapse.im/

Of course you are perfectly free not to use it. And you are also free to change, modify and redistribute the code because like Mono, Qyoto and Qt, Synapse is Free Software.

I completely fail to see any problem with attracting existing C# programmers to the joys of the Qt and KDE apis. Once they learn those apis, they are free to code in other languages like C++, Python or Ruby if they want, and are less reliant on the Microsoft 'eco-system' than they were.

The real issue is Novell's motivation for tying Gnome to Mono in the first place when several of these programs started as Python or C and were CHANGED TO Mono for non-engineering reasons. This the same issue as ESR vs. RMS from earlier this week. The same issue of "Open Source vs. Free Software". ESR and "Open Source" is about happy feelings of competition and fairness, and public "outrage" will keep companies from being "bad". RMS and "Free Software" is about the cold, hard reality of the legal & business landscape... no good deed goes unpunished.

The issue is why are they forcing everybody to use Gnome with Mono... it may be Free Software by itself, but to get enough pieces to be like .Net will never happen. It's quite handy that THEY have a "not to sue" deal with Microsoft, so they can chase cars all day... but what about the rest of us?

It's time to look at KDE again now that QT is LGPL which was the only reason so many distros dumped KDE years ago to try to sell closed-source apps on Gnome without expecting people to pay for QT. KDE 4 is new and powerful and a blank slate waiting for the community to build a "Linux" identity and not just clones of other GUIs.

Synapse, a start of the art instant messaging client is a good example of a Qyoto program written in C#:

http://synapse.im/

Of course you are perfectly free not to use it. And you are also free to change, modify and redistribute the code because like Mono, Qyoto and Qt, Synapse is Free Software.

I completely fail to see any problem with attracting existing C# programmers to the joys of the Qt and KDE apis. Once they learn those apis, they are free to code in other languages like C++, Python or Ruby if they want, and are less reliant on the Microsoft 'eco-system' than they were.

Lots of people are scared of Mono and I'm not going to comment on whether that's rational. But the original poster called Mono "un-needed". Presumably the apps in the default Gnome Ubuntu desktop need Mono but the apps in the default Kubuntu desktop don't. As far as I know there are relatively few KDE apps using Mono at all. So it probably is un-needed in a KDE-based distro.

I didn't really see any fear in the original statement

If the user needs Mono for an app they want it will get installed when they install that app, from the same packages that Gnome Ubuntu uses.

Lots of people are scared of Mono and I'm not going to comment on whether that's rational. But the original poster called Mono "un-needed". Presumably the apps in the default Gnome Ubuntu desktop need Mono but the apps in the default Kubuntu desktop don't. As far as I know there are relatively few KDE apps using Mono at all. So it probably is un-needed in a KDE-based distro. I didn't really see any fear in the original statement If the user needs Mono for an app they want it will get installed when they install that app, from the same packages that Gnome Ubuntu uses. "

Sort of.

Only just now Novell are working on Mono bindings for KDE/Qt. These bindings would allow a KDE/Qt application to call the Mono library functions. So far, the KDE team and Nokia are not interested.

One could theoretically install Mono from the base Ubuntu, but why on earth would one want to download and install 50MB+ of problematical packages just to get something like Gnome Do running, when there are perfectly as functional alternatives "native" to KDE (in this case, Krunner)?

As for the GNOME desktop, it also does not strictly require Mono. Nevertheless, Mono and a couple of Mono applications (I think maybe TomBoy Notes and Banshee or FSpot) are included by default in standard Ubuntu (GNOME).

Edited 2009-03-27 02:58 UTC

I am pretty sure Novell is not making C# bindings for KDE/Qt. They seem to be done by the "kde-bindings team", and are hosted on kde.org.

To be fair, I don't believe qyoto is sponsored by Novell, though I'll admit I could be wrong. The C# bindings have been around for a while. They're simply a way of allowing developers to use C# as a development language, and mono is the method for implementing C# in *nix. There's no taint from MS, since by its very nature, the KDE bindings would replace any of the Winforms etc. MS cruft.

I'm not a fan of mono, simply because the mono apps I have used to this point have come close to causing my laptop to burst into flames from resource utilization, but the patent threats don't touch the standard mono implementation. They only really come into play when looking at the re-implemented frameworks that are Windows-specific. A lot of the mono stuff it GTK based or otherwise agnostic, and has nothing to do with the Windows specific (and protected) fluff. Even Fedora acknowledged this point.

I don't think providing C# bindings for KDE developers is a bad thing, if it helps encourage C# developers from experimenting with KDE. Using C# in KDE doesn't mean having to depend on all of the various libraries associated with mono and the bloat that may accompany that.




Tomboy is part of Gnome standard, so there is a mono-dependency. Of course, distros are free to choose not to include it.

Anyways, just my 2c...

Edited 2009-03-27 05:04 UTC

How does one use C# without all of the "various libraries associated with mono and the bloat that may accompany that"?

Isn't C# basically managed code, in some ways a bit like Python? Won't you therefore need the runtime libraries? Doesn't that mean installing Mono?

I'm pretty sure GCC won't compile C# for you.

While I still believe Mono to be the best way of getting into Gnome and GTK programming without having a hernia, I'm afraid you're going to have to qualify that statement with some arguments as to why being wary of Mono is irrational. Those problems people have with it have been documented enough around here so I suggest you do some reading first, and no, pointing to the FAQ doesn't answer anything.

It's something you're not good at however, and no, questioning someone's mental state does not make you right ;-).

Edited 2009-03-27 11:22 UTC

Warning, young Padawan, it is still beta. If you find bugs, do not be surprised ... report them!

You'll actually find a list of known issue at the bottom of the linked page. Is it just an impression of mine or the list is quite longer than in the past? Also, I'm not convinced by the un-interactive notification system, I'm curious to test it.

Rehdon

ATI graphics using fglrx is really broken on a X800 card
to get it working again:
boot into recovery mode drop to shell and then:
apt-get remove fglrx*
this removes the propitiatory ati driver after a reboot it will use the OS ati driver

If I'm not mistaken...because I used to own one of these. The X800 has open source drivers. It was the fastest graphics graphics card with open source drivers, and there was lots of exciting developments still going on. I have since moved to the X4500HD onboard intel.

I haven't owned the card for over a year, but I know since then R500/600 cards have been added to the driver, the main problem of missing features have all but gone OpenGL1.3 is supported and OpenGL1.4 if it hasn't already, I cannot comment on general speed although I would be surprised if that has not continued to improve. , and new features including KMS/DRI2 are part of a Open Source driver.

http://tirdc.livejournal.com/
http://airlied.livejournal.com/
http://cgit.freedesktop.org/xorg/driver/xf86-video-ati/

AMD have not provided the same level of support for their Graphics chips in Linux as Intel, but now we are starting to see the benefits with having open source drivers.

There are ways of installing the latest drivers and finding out for yourself on Ubuntu!

http://ppa.launchpad.net/tormodvolden/ubuntu/pool/main/x/xserver-xo...
http://ppa.launchpad.net/tormodvolden/ubuntu/pool/main/x/xserver-xo...

Now if only NVidia were as open, nouveau only there for 2D functions, has not progressed as quickly as I would have hoped.

Thanks for the links,
The opensource driver does work fine in xubuntu, I only had the idea that the ati one would be faster.
xubuntu is actually pretty usable today, everything gets picked up graphics/sound/tablet only some minor irritations are still bugging but I'm getting used to that.

I find them good looking and usable. One thing that annoys me though, is that they're completely passive, which means I cannot interact with them. It's done on purpose, but I find not being able to click "reply" in the notification popup when someone speaks to me, annoying at best.

One good thing though is that if you hover over a notification it freezes and fades out so you can see stuff behind it. It's also configurable so you can select the theme, duration and other stuff. At least it was last time I tried jaunty.

yes try update-apt-xapian-index without the sudo
then again with sudo and in the meantime a notification pops up saying that it crashed.

Because there are those people who hate anything and everything that may have anything to do with, once had to do with, or will have to do with Microsoft. I can understand that, really I can, given Microsoft's business practices. I don't use Microsoft products except in virtual machines, where sadly I require them for troubleshooting others' computers. I'm as outraged as anyone by their recent business with netbooks, and Windows 7 starter. But let's face the facts here.
You don't like Microsoft? You don't want to use any of their APIs with Mono? Simple solution: don't. Under no circumstances are you obligated to use Winforms, I sure as hell wouldn't want to anyway compared to most of the other bindings out there. Use GTK#, Kyoto or whatever you wish. C# is an open standard, so is the basic runtime.
You've nothing to fear from Mono. When it comes to the Microsoft .NET APIs, however, I wouldn't blame anyone for steering clear. You never know when Microsoft might come down hard on such things, so it would be best to stick with open source C# bindings.

Because they dislike simple sticky note apps that suck up more memory than their web browsers?

I'm still on 7.10 - simply because it's so stable! But maybe it's time I take a look at the newer Ubuntu and Kubuntu releases. I'm downloading the Kubuntu beta now. Last Kubuntu I tried was 5.10. :-)

It's not just you, their servers appear to be loaded down at the moment.

And I must say that after a few breakages which annoyed the hell out of me, 9.04's Pulseaudio integration is much better for the most part. I don't have a bluetooth headset though, so can't comment on the pulseaudio crashes regarding that.