Lag != Latency. Lag is the time between two things that should be synchronised, but are not. Latency is the time taken between something going in to a black box, and it coming out.
If there is a buffer of 20 seconds, and I completely fill that up right at the start, the data going in will have between 0 and 20 seconds latency. The lag is completely different and as we have no idea what we're supposed to be synchronised with, I cannot comment about what lag could or could not be in this case.
It's this general misunderstanding that means that statements like: "I simply cannot understand how you could think high latency is certainly good, thats simply never ever the case." so completely wrong.
I'm not suggesting that games etc should have a ridiculously high lag between a visual event/user input and a sound event. Clearly this wants as close to lag=0 as possible. But you should really also consider that for many applications and use cases, latency IS a good thing due to the power savings it introduces, and thus the longer battery life.
Power consumption in alsa: In order to enable this mode you need to disable interrupts and then deal with the filling of the audio buffers via some kind of timer mechanism. This approach also requires that the whole mixing buffers are rewritten when needed (this is across all applications). This needs some kind of central process to manage all the audio from all applications, or a "sound server". The likelihood of this even occurring has to be offset with the overhead of remixing etc etc. but the tradeoff is generally fine unless you are skipping forward/back in audio tracks all the time etc.
The argument about writing for the most common path is not one I'd personally agree with. You have to design the architecture to handle all the cases that will be thrown at it. Sure, maybe make the common case pipeline a clear run through your architecture, but you can't really do things fundamentally different in difference cases. Typically a problem occurs when something changes half way through, you cannot tear down your "special setup" and restart in "generic setup" without letting the user know with a pop and a click.
0 == no attenuation in my book, not mute. A volume of 0dB is pretty much the max it can be.
And -inf dB attenuation != mute either. My volume can be pretty near 0dB and I can still have the thing muted... If I hit mute twice, I don't want to lose track of what my volume was at! In my book, mute state handling should be totally separate to volume. How it's presented to the user via GUI tools is perhaps another question tho'.
The fact that audio cuts out when you switch to a TTY is the domain of console-kit. There used to be a way do disable it via HAL but as HAL is dead now, that no longer seems to work, but I'm sure there is another way to do it. It's basically tweaking the console kit policy.
Dude, I'm not talking about lag, I'm talking about latency. Latency is the time it takes from inserting the data into the buffer for it to be heard. Lag may be bad, but high latency is certainly good.
Mediatomb is a deamon in itself and it's a totally different use case than the UPnP support in PA, so please don't compare apples to oranges.
"next LTS (Hardy Heron) and boom... pulseaudio screwed it all up..."
Dude, Ubuntu's integration of PA in that version totally sucks. They didn't even try to get things right there and this then reflects badly on PA. Ubuntu have made a *lot* of mistakes with pulse and are continuing to do so, so please don't use this as the benchmark to judge.
We released Mandrvia around the same time with our first PA-by-default version, and it was received very well. So don't blaming the carpenter just because the stable boy left the door open while the horse bolted.
Your first sentence makes what point what exactly?
As for the ACL stuff, are you suggesting that all audio apps are rewritten to handle the ACLs and know about all the other applications that are out there so they can take appropriate action when particular events occur? Policy should not be something that has to be coded into every app, it should be centrally managed.
As for "application controlled latency is good" comment, sometimes you don't get that luxury. If you start off your stream playing on your laptops built in speakers and then have your bluetooth headset take over (it's a VoIP call so I want to use BT here), then the latency will *change*. The application cannot tell the bluetooth protocol to "be quicker". The application has to react to the latency information provided by the sound system.
And as I said, most applications seem to have this built in concept of "latency == bad", which is just bogus in most cases (media players etc.). If power consumption is the main factor (and with handhelds, laptops, netbooks and the like, it frequently *is*), then latency == good. Fewer CPU wakeups, longer battery life. Intel and others have been experimenting with large latencies of about 10-20 seconds with good results on power savings.
And with PA, "sending data from one userspace process to another" can be done with a zero-copy approach (the whole core of PA is zero-copy and lock free).
I knew as soon as I read the headline here that this article would be jumped on by numerous "alsa is fine on it's own", "Why not OSS" and "PulseAudio is buggy blah blah" type posts but I didn't think that even the general slashdot hordes were that ignorant about what the hell PA is all about. I was sorely mistaken.
PulseAudio is very little to do about "networked audio" which everyone and their dog seems to use as an example to reason "I do not need networked audio, therefore I do not need pulseaudio". It's just ignorance in the extreme.
PulseAudio as an architecture is fast becoming the defacto standard on Linux, companies such as Intel, Nokia and Palm are putting significant resources into PA just now.
OSSv4 or older flavours simply does not have the API to deal with a modern linux desktop, plain and simple. We can maybe get some of the more userspace stuff such as bluetooth or airtunes support (the support for which I added to PA myself) using some kind of CUSE support but that's only just landed in the kernel just now, and it really wouldn't be a proper solution (and guess what? it would need a daemon running anyway!!)
I'll outline some of these things here to save you killing my poor server!
More and more audio device *are* network based. Apple Airport Express devices are pretty popular these days. I have two bluetooth headsets and my hifi system also support bluetooth connections and my Playstation 3 supports uPNP. So lots of things relating to network Audio are popping up (which is nothing to do with pulse->pulse network connections which is arguably a toy, even if I do personally use it a lot!). I don't think these should be ignored. PulseAudio supports all of these devices right now (although I've not had time to try the uPNP stuff on my PS3 specifically so don't quote me on that!)
In addition, rights access and management is a big issue. Today any modern linux desktop uses console kit to keep track of user sessions. When you switch from one user to another, console-kit ensures that the currently "active" user session is set to inactive, and it triggers udev callouts to remove the currently active users ACL on the/dev/snd/* nodes. (I seriously hope no one adds their user to the "audio" group these days!). This allows a new user to log in and get access to the sound hardware because they are now the "active" user. Switching between the two sessions triggers these ACL rewrites. Something has to manage this in applications so that they don't just bail out with EPERM errors. The sound has to go to/dev/null automatically without the application being aware of what is going on. Perhaps it can cork/uncork applications that listen for such signals so that music is paused etc. This is something that cannot be done without some kind of userspace daemon handling things.
Then on to power consumption. What most people quite often fail to realise is that Latency is Good. If you can pump 20 seconds worth of audio into a buffer and then switch off until you're woken up 19.5 seconds later then this is great for power consumption. You need to disable hardware interrupts and use kernel level timing constructs to deal with this, and automatically reduce your wakeup time on the event of an underrun to reduce the likelihood of a future underrun occurring. You also have to have accurate timing information reported such that a/v applications can handle things like lipsyncing etc. (and remember that hoping for a low latency audio output is
Right, hopefully this will sink in and dispell a few other myths.
One of the ways to get increased battery life is to use PulseAudio. Right, now that some of you are doing the characteristic snorting and thinking up a derisive comment for a reply I'll explain.
Glitch Free mode in PulseAudio is a new technique that disables the audio hardware interrupts and uses kernel-based timers to feed data into the sound card. It's called "glitch free" because if it detects an underrun it will automatically decrease the time it waits before it wakes up again. This has the effect of reducing the power efficiency at the expense of lowering the likelihood of another underrun occurring. By disabling the interrupt and using higher latencies you can massively reduce the CPU wakups and thus increase battery life.
Using this approach you can get much better power efficiency, but it doesn't end there. Applications have to be written with the concept of "latency is good" rather than the "we must have small latency" mindset that is currently quite popular (although quite often totally incorrect) Take a media player for example. You can decode 10seconds of audio and pump it into a large latency system pretty damn quickly (realtime streaming doesn't apply here but buffering is still needed there anyway).
Yes, this approach is new and yes it pushes the ALSA drivers to their limit and exposed many bugs (no other ALSA application has pushed the drivers as hard as PulseAudio and such low level bugs are therefore to be expected). This has lead to some people to be critical of PulseAudio but such people will eventually eat their words (or rather they will change history and claim they never said it was a bad idea, just that it wasn't ready yet etc. etc.).
While I don't want to comment incorrectly, I beleive the default Ubuntu setup disables PA glitch free mode by default. Perhaps you should turn it on?
Certainly on my system it doesn't use/etc/hosts (it may use it as a fall back I guess, not looked). In my env it completes from ~/.ssh/known_hosts and ~/.ssh/config. Altogether more sensible IMO.
As a small company who has recently been through the self assessment procedure, I can say that the guidelines are very poorly designed in many cases.
For example, on the instructions page (https://www.pcisecuritystandards.org/saq/instructions.shtml) there is a link to SAQ Validation Type 1 form (A) and describe the type of applicant thus: "Card-not-present (e-commerce or mail/telephone-order) merchants, all cardholder data functions outsourced. This would never apply to face-to-face merchants."
But in form A part 2c it states: "Merchant does not store, process, or transmit any cardholder data on merchant premises but relies entirely on third party service provider(s) to handles these functions;"
By answering yes to this question, a merchant is saying that they will not transmit the details on (i.e from, to or within) their premises. This would mean that e.g. a mail or telephone operator could not *transmit* the card details to a third party service provider. i.e. they cannot use the PAN in any way (they *can* store it on paper - so orders by mail are OK), but the requirement very specifically says "Merchant does not... transmit any card holder data on merchant premises". If I cannot transmit this information on my premises I cannot send it out to our service provider for processing etc.
This does not make logical sense. In theory, I could process payments via a PDQ machine directly connected to the phone line system and as the phone company is a "third party service provider" this could be argued to be compliant, but if I send it via e.g. an HTTPS website to an application hosted by our hosting company, this is technically going through our internal network before going through the wider internet (albeit encrypted via SSL) to our third party service provider. This is clearly "transmission on merchant premises".
I'm probably interpreting things quite pedantically (but isn't that what you're supposed to do with this kind of security thing?), but the guidelines and forms are riddled with these ambiguities and contradictions.:(
Maintenance release is not a good indicator
on
The State of X.Org
·
· Score: 1
If you follow xorg development, I wouldn't say that there is any problem. The main issue at the moment is that there isn't a huge amount of resource to look after the stable releases.
The head of the git tree is quite interesting and there are lots of interesting branches too. Things like DRI2 and MPX are really coming along as is kernel level mode setting.
Sure it's in a bit of glut just now, but that's just because all the developers are more interested in the future and working towards it rather than doing small incremental changes.
Dammit. You beat me to it! I was just scanning the posts to see if someone had put up a "the matrix is real" type post as the same though crossed my paranoid mind;)
The discovery of penicillin is usually attributed to Scottish scientist Sir Alexander Fleming in 1928, though others had earlier noted the antibacterial effects of Penicillium such as Ernest Duchesne who documented it in his 1897 paper however it was not accepted by the Institut Pasteur because of his young age.
The development of penicillin for use as a medicine is attributed to the Australian Nobel Laureate Howard Walter Florey.
So I guess you could say it was a Frenchman or a Scotsman depending on your view point. Either way "European". Props to the Aussies for making it useful tho';)
And it is here that I should point out that Bell was Scottish (born in my own fair City of Edinburgh) which makes him European (tho' arguably not at the time!). That's the trouble with everything that's got a modicum of thought/intelligence behind it - Americans' always think that they invented everything when it's clear to all those who looked, that the Scots invented the modern world. Telephone, Television, Penicillin and all the rest of it.
Try peeing higher than that:p
(Now I grant you you may have been referring to Grey, but I'm ignoring that due to the context of your Wikipedia quote).
I completely agree with you but we should say that Flash's alsa support is pretty crap. It does some weird interal thing of trying to open up lots of streams/channels/[insert correct terminology here] and quite quickly breaks things when used with pulse audio (via alsa's pulse plugin). Fortunately, Fedora (and other distros like Mandriva) also ship a package called libflashsupport which uses the extension mechanisms of flash to add direct support for pulse, esd and openssl to flash player/plugin. Gotta be annoyed at adobe for the gaff but happy with them for the extensibility!
Dmix is just a "sound server" by a wrapped up name and "inside alsa". Lot's of people have been slamming PA for adding "another sound server" when it's not even necessary due to the fact that dmix inside alsa can do the job without a sound server. When people wake up and realise that dmix is a sound server and it runs in userspace, they will realise that pulseaudio is a lot better and offers far more features.
AFAIK, the guy who wrote/maintains dmix also does the packaging for pulseaudio on suse, so it's not like he's fundamentally opposed ot the idea of pulse. If he isn't why should you???
Skype uses ALSA for a long time on Linux. If you're not even going to look at the audio prefs. dialog in apps how the hell are you going to know the current state of affairs with linux audio?
I don't understand this whole screed of comment about "what if my internet goes down - I wont be able to work", "It'll be slow to load", "I can't see how they'll implement Photoshop in Flash and make is nice" and all the rest.
They guy said 10 years, 10 YEARS!!! That's a lifetime in IT. Online delivery of applications will be a WHOLE DIFFERENT BALL GAME then. I doubt very much Photoshop will be any different to how it is now, but it will be delivered via the Web. It will not doubt be possible to run it in offline mode and all sorts (perhaps for several days at a time) without having to check back with Adobe HQ.
I don't use Adobe stuff anyway (I'm a Linux bod) but I don't really see a problem with what they are suggesting. You just have to have a little bit of imagination as to how it will roll out in a decade from now.
If they are going to develop a really good IM for Facebook (which I'd quite like) then they really nned a libpurple plugin no? That way it would work with e.g. Pidgin and Adium...
IIRC the name "Joomla" roughly means "community" in I think Swahili. This was chosen at the point when Joomla forked from Mambo due to issues over the formation of a for-profit foundation to commercialise Mambo. The main developers thought that this was diverging away from community feel of the project and so the name they gave to the fork reflected this sentiment: that they really care about the community.
Rather than install the whole OS on the Flash drive, I just opted for a 32Meg Flash drive in an IDE form factor. Cheap as chips and it stores my/boot (kernel+ramdisk) and GRUB install which means it can boot strap itself to the load the full / filesystem of the RAID/LVM layer no problem.
As for the OPs question about starting with 500Gb drives and replacing them with 1Tb later, provided your final layer is on LVM you wont have any problem increasing things.
e.g. If I had three drives in RAID 5 (I'd recommend RAID 1 personally as I've had back experience of RAID 5 in the past - too many times I've had to force start a supposedly failed array). Anyway, create your partitions on the 500Gb drives and RAID them together. Then use your md device and slap an LVM Physical Volume over the top, then create an Logical Volume in that PV and format it as desired.
If you replace the drives over time then when you are done replacing you'll have another three partions. Just set these up in the same way as your other partitions and create an md1 to compliment your md0. Create a PV of that and then add that PV to your LV to increase it's capacity. All you need do then is resize your filesystem to fill the device. Depending on your FS this can all be done without umounting!!
File systems are fun! I'm currently breaking a RAID1 MD into two so I can "convert" it to LVM.... risky but fun!
Slashdot Mirror
Lag != Latency. Lag is the time between two things that should be synchronised, but are not. Latency is the time taken between something going in to a black box, and it coming out.
If there is a buffer of 20 seconds, and I completely fill that up right at the start, the data going in will have between 0 and 20 seconds latency. The lag is completely different and as we have no idea what we're supposed to be synchronised with, I cannot comment about what lag could or could not be in this case.
It's this general misunderstanding that means that statements like: "I simply cannot understand how you could think high latency is certainly good, thats simply never ever the case." so completely wrong.
I'm not suggesting that games etc should have a ridiculously high lag between a visual event/user input and a sound event. Clearly this wants as close to lag=0 as possible. But you should really also consider that for many applications and use cases, latency IS a good thing due to the power savings it introduces, and thus the longer battery life.
Power consumption in alsa: In order to enable this mode you need to disable interrupts and then deal with the filling of the audio buffers via some kind of timer mechanism. This approach also requires that the whole mixing buffers are rewritten when needed (this is across all applications). This needs some kind of central process to manage all the audio from all applications, or a "sound server". The likelihood of this even occurring has to be offset with the overhead of remixing etc etc. but the tradeoff is generally fine unless you are skipping forward/back in audio tracks all the time etc.
The argument about writing for the most common path is not one I'd personally agree with. You have to design the architecture to handle all the cases that will be thrown at it. Sure, maybe make the common case pipeline a clear run through your architecture, but you can't really do things fundamentally different in difference cases. Typically a problem occurs when something changes half way through, you cannot tear down your "special setup" and restart in "generic setup" without letting the user know with a pop and a click.
0 == no attenuation in my book, not mute. A volume of 0dB is pretty much the max it can be.
And -inf dB attenuation != mute either. My volume can be pretty near 0dB and I can still have the thing muted... If I hit mute twice, I don't want to lose track of what my volume was at! In my book, mute state handling should be totally separate to volume. How it's presented to the user via GUI tools is perhaps another question tho'.
The fact that audio cuts out when you switch to a TTY is the domain of console-kit. There used to be a way do disable it via HAL but as HAL is dead now, that no longer seems to work, but I'm sure there is another way to do it. It's basically tweaking the console kit policy.
Dude, I'm not talking about lag, I'm talking about latency. Latency is the time it takes from inserting the data into the buffer for it to be heard. Lag may be bad, but high latency is certainly good.
Mediatomb is a deamon in itself and it's a totally different use case than the UPnP support in PA, so please don't compare apples to oranges.
"next LTS (Hardy Heron) and boom... pulseaudio screwed it all up..."
Dude, Ubuntu's integration of PA in that version totally sucks. They didn't even try to get things right there and this then reflects badly on PA. Ubuntu have made a *lot* of mistakes with pulse and are continuing to do so, so please don't use this as the benchmark to judge.
We released Mandrvia around the same time with our first PA-by-default version, and it was received very well. So don't blaming the carpenter just because the stable boy left the door open while the horse bolted.
"Thank yous" gratefully received, as is beer (tho' obviously it has to be Free Beer... the cornerstone of all FLOSS work!)
Your first sentence makes what point what exactly?
As for the ACL stuff, are you suggesting that all audio apps are rewritten to handle the ACLs and know about all the other applications that are out there so they can take appropriate action when particular events occur? Policy should not be something that has to be coded into every app, it should be centrally managed.
As for "application controlled latency is good" comment, sometimes you don't get that luxury. If you start off your stream playing on your laptops built in speakers and then have your bluetooth headset take over (it's a VoIP call so I want to use BT here), then the latency will *change*. The application cannot tell the bluetooth protocol to "be quicker". The application has to react to the latency information provided by the sound system.
And as I said, most applications seem to have this built in concept of "latency == bad", which is just bogus in most cases (media players etc.). If power consumption is the main factor (and with handhelds, laptops, netbooks and the like, it frequently *is*), then latency == good. Fewer CPU wakeups, longer battery life. Intel and others have been experimenting with large latencies of about 10-20 seconds with good results on power savings.
And with PA, "sending data from one userspace process to another" can be done with a zero-copy approach (the whole core of PA is zero-copy and lock free).
I knew as soon as I read the headline here that this article would be jumped on by numerous "alsa is fine on it's own", "Why not OSS" and "PulseAudio is buggy blah blah" type posts but I didn't think that even the general slashdot hordes were that ignorant about what the hell PA is all about. I was sorely mistaken.
PulseAudio is very little to do about "networked audio" which everyone and their dog seems to use as an example to reason "I do not need networked audio, therefore I do not need pulseaudio". It's just ignorance in the extreme.
PulseAudio as an architecture is fast becoming the defacto standard on Linux, companies such as Intel, Nokia and Palm are putting significant resources into PA just now.
OSSv4 or older flavours simply does not have the API to deal with a modern linux desktop, plain and simple. We can maybe get some of the more userspace stuff such as bluetooth or airtunes support (the support for which I added to PA myself) using some kind of CUSE support but that's only just landed in the kernel just now, and it really wouldn't be a proper solution (and guess what? it would need a daemon running anyway!!)
As a PA developer and supporter, I've written up various articles explaining what PA is all about before and posted similar comments to mailing lists etc.
You can read some of them here:
http://colin.guthr.ie/2009/08/sound-on-linux-anti-fud-calm-certainty-and-confidence/
and
http://thread.gmane.org/gmane.comp.kde.amarok.devel/15356
I'll outline some of these things here to save you killing my poor server!
More and more audio device *are* network based. Apple Airport Express devices are pretty popular these days. I have two bluetooth headsets and my hifi system also support bluetooth connections and my Playstation 3 supports uPNP. So lots of things relating to network Audio are popping up (which is nothing to do with pulse->pulse network connections which is arguably a toy, even if I do personally use it a lot!). I don't think these should be ignored. PulseAudio supports all of these devices right now (although I've not had time to try the uPNP stuff on my PS3 specifically so don't quote me on that!)
In addition, rights access and management is a big issue. Today any modern linux desktop uses console kit to keep track of user sessions. When you switch from one user to another, console-kit ensures that the currently "active" user session is set to inactive, and it triggers udev callouts to remove the currently active users ACL on the /dev/snd/* nodes. (I seriously hope no one adds their user to the "audio" group these days!). This allows a new user to log in and get access to the sound hardware because they are now the "active" user. Switching between the two sessions triggers these ACL rewrites. Something has to manage this in applications so that they don't just bail out with EPERM errors. The sound has to go to /dev/null automatically without the application being aware of what is going on. Perhaps it can cork/uncork applications that listen for such signals so that music is paused etc. This is something that cannot be done without some kind of userspace daemon handling things.
Then on to power consumption. What most people quite often fail to realise is that Latency is Good. If you can pump 20 seconds worth of audio into a buffer and then switch off until you're woken up 19.5 seconds later then this is great for power consumption. You need to disable hardware interrupts and use kernel level timing constructs to deal with this, and automatically reduce your wakeup time on the event of an underrun to reduce the likelihood of a future underrun occurring. You also have to have accurate timing information reported such that a/v applications can handle things like lipsyncing etc. (and remember that hoping for a low latency audio output is
Right, hopefully this will sink in and dispell a few other myths.
One of the ways to get increased battery life is to use PulseAudio. Right, now that some of you are doing the characteristic snorting and thinking up a derisive comment for a reply I'll explain.
Glitch Free mode in PulseAudio is a new technique that disables the audio hardware interrupts and uses kernel-based timers to feed data into the sound card. It's called "glitch free" because if it detects an underrun it will automatically decrease the time it waits before it wakes up again. This has the effect of reducing the power efficiency at the expense of lowering the likelihood of another underrun occurring. By disabling the interrupt and using higher latencies you can massively reduce the CPU wakups and thus increase battery life.
Using this approach you can get much better power efficiency, but it doesn't end there. Applications have to be written with the concept of "latency is good" rather than the "we must have small latency" mindset that is currently quite popular (although quite often totally incorrect) Take a media player for example. You can decode 10seconds of audio and pump it into a large latency system pretty damn quickly (realtime streaming doesn't apply here but buffering is still needed there anyway).
Yes, this approach is new and yes it pushes the ALSA drivers to their limit and exposed many bugs (no other ALSA application has pushed the drivers as hard as PulseAudio and such low level bugs are therefore to be expected). This has lead to some people to be critical of PulseAudio but such people will eventually eat their words (or rather they will change history and claim they never said it was a bad idea, just that it wasn't ready yet etc. etc.).
While I don't want to comment incorrectly, I beleive the default Ubuntu setup disables PA glitch free mode by default. Perhaps you should turn it on?
... an iPhone version of Rate-my-Poo?
"Checks" indeed. Grow up NA - the word is Cheques!
The question is... if I hadn't seen your post, would you still have been beaten?
Certainly on my system it doesn't use /etc/hosts (it may use it as a fall back I guess, not looked). In my env it completes from ~/.ssh/known_hosts and ~/.ssh/config. Altogether more sensible IMO.
Also make sure you get the programmable scripts http://www.caliban.org/bash/#completion_download to pimp your completion. Can't live without it.
As a small company who has recently been through the self assessment procedure, I can say that the guidelines are very poorly designed in many cases.
For example, on the instructions page (https://www.pcisecuritystandards.org/saq/instructions.shtml) there is a link to SAQ Validation Type 1 form (A) and describe the type of applicant thus:
"Card-not-present (e-commerce or mail/telephone-order) merchants, all cardholder data functions outsourced. This would never apply to face-to-face merchants."
But in form A part 2c it states:
"Merchant does not store, process, or transmit any cardholder data on merchant premises but relies entirely on third party service provider(s) to handles these functions;"
By answering yes to this question, a merchant is saying that they will not transmit the details on (i.e from, to or within) their premises. This would mean that e.g. a mail or telephone operator could not *transmit* the card details to a third party service provider. i.e. they cannot use the PAN in any way (they *can* store it on paper - so orders by mail are OK), but the requirement very specifically says "Merchant does not ... transmit any card holder data on merchant premises". If I cannot transmit this information on my premises I cannot send it out to our service provider for processing etc.
This does not make logical sense. In theory, I could process payments via a PDQ machine directly connected to the phone line system and as the phone company is a "third party service provider" this could be argued to be compliant, but if I send it via e.g. an HTTPS website to an application hosted by our hosting company, this is technically going through our internal network before going through the wider internet (albeit encrypted via SSL) to our third party service provider. This is clearly "transmission on merchant premises".
I'm probably interpreting things quite pedantically (but isn't that what you're supposed to do with this kind of security thing?), but the guidelines and forms are riddled with these ambiguities and contradictions. :(
If you follow xorg development, I wouldn't say that there is any problem. The main issue at the moment is that there isn't a huge amount of resource to look after the stable releases.
The head of the git tree is quite interesting and there are lots of interesting branches too. Things like DRI2 and MPX are really coming along as is kernel level mode setting.
Sure it's in a bit of glut just now, but that's just because all the developers are more interested in the future and working towards it rather than doing small incremental changes.
Personally I'm not overly worried.
Dammit. You beat me to it! I was just scanning the posts to see if someone had put up a "the matrix is real" type post as the same though crossed my paranoid mind ;)
Well from good ol' WP:
So I guess you could say it was a Frenchman or a Scotsman depending on your view point. Either way "European". Props to the Aussies for making it useful tho' ;)
And it is here that I should point out that Bell was Scottish (born in my own fair City of Edinburgh) which makes him European (tho' arguably not at the time!). That's the trouble with everything that's got a modicum of thought/intelligence behind it - Americans' always think that they invented everything when it's clear to all those who looked, that the Scots invented the modern world. Telephone, Television, Penicillin and all the rest of it.
Try peeing higher than that :p
(Now I grant you you may have been referring to Grey, but I'm ignoring that due to the context of your Wikipedia quote).
I completely agree with you but we should say that Flash's alsa support is pretty crap. It does some weird interal thing of trying to open up lots of streams/channels/[insert correct terminology here] and quite quickly breaks things when used with pulse audio (via alsa's pulse plugin). Fortunately, Fedora (and other distros like Mandriva) also ship a package called libflashsupport which uses the extension mechanisms of flash to add direct support for pulse, esd and openssl to flash player/plugin. Gotta be annoyed at adobe for the gaff but happy with them for the extensibility!
Dmix is just a "sound server" by a wrapped up name and "inside alsa". Lot's of people have been slamming PA for adding "another sound server" when it's not even necessary due to the fact that dmix inside alsa can do the job without a sound server. When people wake up and realise that dmix is a sound server and it runs in userspace, they will realise that pulseaudio is a lot better and offers far more features.
AFAIK, the guy who wrote/maintains dmix also does the packaging for pulseaudio on suse, so it's not like he's fundamentally opposed ot the idea of pulse. If he isn't why should you???
Skype uses ALSA for a long time on Linux. If you're not even going to look at the audio prefs. dialog in apps how the hell are you going to know the current state of affairs with linux audio?
Jeeze,
I don't understand this whole screed of comment about "what if my internet goes down - I wont be able to work", "It'll be slow to load", "I can't see how they'll implement Photoshop in Flash and make is nice" and all the rest.
They guy said 10 years, 10 YEARS!!! That's a lifetime in IT. Online delivery of applications will be a WHOLE DIFFERENT BALL GAME then. I doubt very much Photoshop will be any different to how it is now, but it will be delivered via the Web. It will not doubt be possible to run it in offline mode and all sorts (perhaps for several days at a time) without having to check back with Adobe HQ.
I don't use Adobe stuff anyway (I'm a Linux bod) but I don't really see a problem with what they are suggesting. You just have to have a little bit of imagination as to how it will roll out in a decade from now.
If they are going to develop a really good IM for Facebook (which I'd quite like) then they really nned a libpurple plugin no? That way it would work with e.g. Pidgin and Adium...
IIRC the name "Joomla" roughly means "community" in I think Swahili. This was chosen at the point when Joomla forked from Mambo due to issues over the formation of a for-profit foundation to commercialise Mambo. The main developers thought that this was diverging away from community feel of the project and so the name they gave to the fork reflected this sentiment: that they really care about the community.
As for the exclamation mark, well I have no idea!
Rather than install the whole OS on the Flash drive, I just opted for a 32Meg Flash drive in an IDE form factor. Cheap as chips and it stores my /boot (kernel+ramdisk) and GRUB install which means it can boot strap itself to the load the full / filesystem of the RAID/LVM layer no problem.
As for the OPs question about starting with 500Gb drives and replacing them with 1Tb later, provided your final layer is on LVM you wont have any problem increasing things.
e.g. If I had three drives in RAID 5 (I'd recommend RAID 1 personally as I've had back experience of RAID 5 in the past - too many times I've had to force start a supposedly failed array). Anyway, create your partitions on the 500Gb drives and RAID them together. Then use your md device and slap an LVM Physical Volume over the top, then create an Logical Volume in that PV and format it as desired.
If you replace the drives over time then when you are done replacing you'll have another three partions. Just set these up in the same way as your other partitions and create an md1 to compliment your md0. Create a PV of that and then add that PV to your LV to increase it's capacity. All you need do then is resize your filesystem to fill the device. Depending on your FS this can all be done without umounting!!
File systems are fun! I'm currently breaking a RAID1 MD into two so I can "convert" it to LVM.... risky but fun!
If you mean setting up RAID on the root disk then it is indeed possible. I've done it several times.
I'd say this is nothing special..... just the "Norm".