Either way you do this, Kernel level or Userspace, you're grouping tasks in the scheduler. The theory is, you take all your GUI programs & schedule them as independent tasks, and then lump all your non GUI software as a single task.
I think you have it backwards, neither the kernel or userspace code mentioned here is effecting GUI apps, they remain lumped into one group. It's only giving things that have their own TTY (ie a terminal window) their own cgroups. As such it's only provides advantage in certain cases (when a process is launched in a terminal).
I think the 'userspace' method makes more sense. Not because the particular userspace implementation here is great (it more or less just does the same as the kernel implementation) but because a userspace implementation may be better placed to understand what the user is doing and assign groups accordingly using information other than just the TTY. Perhaps it could promote a process focussed in X to it's own group, or an app running in full screen mode. Perhaps it could lump minimised apps in with other non-critical things. They are all just ideas pulled out of the air but I'm not sure the kernel itself would have the necessary information to make such decisions.
It's GUI users that have the most to gain from improved interactivity but it should be fairly obvious that grouping based on TTY isn't going to bring much advantage to them. Both versions of the code here suggest that improvement is there in the kernel waiting to be leveraged, it's just a matter of someone making the improvement generally applicable.
so those of you who've experienced broken sound in recent years
In recent years?
Has Linux ever had a stable sound system? My recollection is a neverending series of different sound related components (OSS, ALSA, ESD, aRts, Jack etc) of which the best you could say is that they worked most of the time but invariably didn't behave very well in certain cases.
Lennart seems to cop a lot of crap over Pulseaudio but as far as I can tell it's a positive contribution in an area with a lot of historical and legacy issues.
Certainly the first.
However which one is more likely to have a catastrophic results if a small error is made?
If I were telling someone who didn't know what they were doing I might opt for the second method.
Firstly, it's more likely they'll understand the process I'm asking them to enact and actually learn from it.
Secondly, they aren't going to make a small typo and delete their entire home directory.
As others have pointed out they aren't different in that instance, merely the same as Debian.
That said I don't think your question is a valid one in a general sense, only in a specific sense when you judge each individual difference on it'sown merits to see whether it's a good one or not.
If distros weren't different then what's the point of having more than one of them? Without variety there is no real choice.
The fact that Australia has politicians who are even willing to test the waters by floating such ideas says a lot by itself. It's how they wet their finger to feel which way the wind is blowing. If the idea shows support they run with it. If not, they distance themselves from it and the impression they leave is the one you express there.
From that desription the primary thing it "says a lot by itself" about is that we live in a democracy!
It also says a lot about the system in that special interest groups can be tactically valuable in elections, particularly for Senators like Conroy (the internet filter guy).
It also says that if the electoral situation in general is tight then ideas that appeal only to special interest groups will get kicked as they risk turning off the general populace.
The subject of my post asked how it effected things. My comment said I don't understand it. I did not question his personal experience or say he was wrong.
I am more than happy to admit a lack of understanding (while explaining what I do understand) in the hope that he (or someone) can enlighten me.
Unfortunately I got an ass like you replying instead.
I don't understand how 'focusing' as you describe it can be a problem. Regardless of the simulated 3d, the distance your eye focuses on is the distance from you to the screen. The 3d effect is due to your eyes getting different pictures, not because you eye is actually focussing at different ranges.
This is my main problem with 3D (live action) movies, the 3D effect is fine when you are looking at what the camera is focussed on but if you try and look at something in the foreground or background the effect is ruined because that area remains out of focus no matter how hard you look at it.
If you haven't thought about it and a "60" appears where you only anticipating 0-59 then the results could presumably be surprising!
I doubt that very many people actively consider that possibility but in most cases get away with it because it doesn't really matter to their code because they are just recording or displaying a time, rather than doing any particular calculations on it.
I think it makes absolutely no sense for most computers or programmers to have to account for leap seconds.
The reality is that computers already have to allow for their clock drifting from universal time, that's why we have NTP. There's no point getting individual computers account for leap seconds, it would be easier and less error prone if reference clocks transparently accomodate leap seconds (ie without sending a 23:59:60 to the world) and everyone else can just drift back in sync with them when one occurs.
There may be a few applications where a computer really does need to accomodate leap seconds (such as a reference clock!) but for the rest of us the additional complexity gives no advantage whatsoever.
A lump of radioactive cesium-137, for example, may decay at a steady rate overall
But is that true? I thought a more correct statement would be that Cesium-137 decays at a particular rate on average.
I'd have thought you'd expect some minor fluctuations in decay rates would be expected.
I suspect that, on average, Australia is a lot less prudish than (for example) the USA.
Our national broadcaster's "Youth radio station" for example frequently plays songs with swear words in them, including "fuck", though I think "cunt" is still "out of bounds" despite some more recent attempts and discussion.
You're not supposed to detect the browser, you're supposed to detect the engine. Presence or absence of a feature is one way, but there are lots of other ways. One particular engine might have an existing but bad implementation, but it also has a CSS parsing bug. This is how IE gets worked around most of the time. The engine detects itself, but that's not scripting.
While that is true (and very widely used) I'm not sure it's an inherently better solution.
Typically the "parsing bug" that is used in the hack is unrelated to the bug being worked around. By using the bug to get desired behaviour it elevates the bug to a required feature that can't be fixed for backwards compatibility. It also assumes a similar bug won't crop up in another user agent which doesn't need the fix.
Fundamentally I don't think it's wrong to switch based on user agent. At the end of the day the reason the user-agent header/field exists is precisely to let the server or application know what it is working with. I don't think the problem is using user-agents, rather that historically they have been used badly. Rather than being used to handle exceptions they have been used to present entirely different code paths to a select few browsers such that unexpected user-agents got a very bad experience.
Even that probably stems from the fact that in the "old days" the browsers (Netscape, IE) were so incompatible on anything but the most basic level there wasn't much alternative than vastly divergent code paths.
Yes. It is. You shouldn't detect whether you can use a feature based on the User Agent, you should detect based on the presence or absence of that feature.
How does that technique solve the problem where a feature exists but is implemented differently?
I'll not disagree with you that there is likely very little advantage to large company or government organization going to something like Google.
I suppose that may depend on how they are handling mail etc now. If different units within the org are handling their own servers then there may be a lot of redundant duplication of effort that could be cut out by moving to a single external provider.
A technology focused company, say an IT service provider, will probably have the house expertise to make the break even point a really small number.
I disagree with that because that's the sort of company I work in! We have the in house expertise but that expertise is used far more effectively in delivering services to our customers.
Having them spend any time whatsoever babysitting something as colossally dull as mail/calendar etc would be a waste of their expertise.
Slashdot Mirror
I think you have it backwards, neither the kernel or userspace code mentioned here is effecting GUI apps, they remain lumped into one group. It's only giving things that have their own TTY (ie a terminal window) their own cgroups. As such it's only provides advantage in certain cases (when a process is launched in a terminal).
I think the 'userspace' method makes more sense.
Not because the particular userspace implementation here is great (it more or less just does the same as the kernel implementation) but because a userspace implementation may be better placed to understand what the user is doing and assign groups accordingly using information other than just the TTY. Perhaps it could promote a process focussed in X to it's own group, or an app running in full screen mode. Perhaps it could lump minimised apps in with other non-critical things. They are all just ideas pulled out of the air but I'm not sure the kernel itself would have the necessary information to make such decisions.
It's GUI users that have the most to gain from improved interactivity but it should be fairly obvious that grouping based on TTY isn't going to bring much advantage to them. Both versions of the code here suggest that improvement is there in the kernel waiting to be leveraged, it's just a matter of someone making the improvement generally applicable.
In recent years?
Has Linux ever had a stable sound system?
My recollection is a neverending series of different sound related components (OSS, ALSA, ESD, aRts, Jack etc) of which the best you could say is that they worked most of the time but invariably didn't behave very well in certain cases.
Lennart seems to cop a lot of crap over Pulseaudio but as far as I can tell it's a positive contribution in an area with a lot of historical and legacy issues.
Did you completely miss the subject of this thread? (Perhaps the awful application of apostrophes caused your brain to redact it).
Approval of Unicode 1F4A9 as a TLD
Can you explain how not being Java defends them against being sued over patents?
Certainly the first. However which one is more likely to have a catastrophic results if a small error is made?
If I were telling someone who didn't know what they were doing I might opt for the second method.
Firstly, it's more likely they'll understand the process I'm asking them to enact and actually learn from it.
Secondly, they aren't going to make a small typo and delete their entire home directory.
Ha ha, good one!
Not any more.
As others have pointed out they aren't different in that instance, merely the same as Debian.
That said I don't think your question is a valid one in a general sense, only in a specific sense when you judge each individual difference on it'sown merits to see whether it's a good one or not.
If distros weren't different then what's the point of having more than one of them? Without variety there is no real choice.
Yeah, that sounds completely foolproof!
From that desription the primary thing it "says a lot by itself" about is that we live in a democracy!
It also says a lot about the system in that special interest groups can be tactically valuable in elections, particularly for Senators like Conroy (the internet filter guy).
It also says that if the electoral situation in general is tight then ideas that appeal only to special interest groups will get kicked as they risk turning off the general populace.
It's largely because all the news is bullshit.
Australia does not have an internet filter.
Nothing is happening in regards to this story
Somebody making a noise about something, even if that person is a politician in government, is not the same as them actually doing something.
The subject of my post asked how it effected things. My comment said I don't understand it. I did not question his personal experience or say he was wrong.
I am more than happy to admit a lack of understanding (while explaining what I do understand) in the hope that he (or someone) can enlighten me.
Unfortunately I got an ass like you replying instead.
I don't understand how 'focusing' as you describe it can be a problem. Regardless of the simulated 3d, the distance your eye focuses on is the distance from you to the screen. The 3d effect is due to your eyes getting different pictures, not because you eye is actually focussing at different ranges.
This is my main problem with 3D (live action) movies, the 3D effect is fine when you are looking at what the camera is focussed on but if you try and look at something in the foreground or background the effect is ruined because that area remains out of focus no matter how hard you look at it.
It isn't hard if you think about it.
If you haven't thought about it and a "60" appears where you only anticipating 0-59 then the results could presumably be surprising!
I doubt that very many people actively consider that possibility but in most cases get away with it because it doesn't really matter to their code because they are just recording or displaying a time, rather than doing any particular calculations on it.
I think it makes absolutely no sense for most computers or programmers to have to account for leap seconds.
The reality is that computers already have to allow for their clock drifting from universal time, that's why we have NTP. There's no point getting individual computers account for leap seconds, it would be easier and less error prone if reference clocks transparently accomodate leap seconds (ie without sending a 23:59:60 to the world) and everyone else can just drift back in sync with them when one occurs.
There may be a few applications where a computer really does need to accomodate leap seconds (such as a reference clock!) but for the rest of us the additional complexity gives no advantage whatsoever.
But is that true? I thought a more correct statement would be that Cesium-137 decays at a particular rate on average. I'd have thought you'd expect some minor fluctuations in decay rates would be expected.
Zing!
I suspect that, on average, Australia is a lot less prudish than (for example) the USA. Our national broadcaster's "Youth radio station" for example frequently plays songs with swear words in them, including "fuck", though I think "cunt" is still "out of bounds" despite some more recent attempts and discussion.
As for why some parts of our government occasionally seem to get on their high horse, this song from last nights TV probably explains it best.
feel very very stupid after reading that.
That's quite a feat!
While that is true (and very widely used) I'm not sure it's an inherently better solution.
Typically the "parsing bug" that is used in the hack is unrelated to the bug being worked around. By using the bug to get desired behaviour it elevates the bug to a required feature that can't be fixed for backwards compatibility. It also assumes a similar bug won't crop up in another user agent which doesn't need the fix.
Fundamentally I don't think it's wrong to switch based on user agent. At the end of the day the reason the user-agent header/field exists is precisely to let the server or application know what it is working with. I don't think the problem is using user-agents, rather that historically they have been used badly. Rather than being used to handle exceptions they have been used to present entirely different code paths to a select few browsers such that unexpected user-agents got a very bad experience.
Even that probably stems from the fact that in the "old days" the browsers (Netscape, IE) were so incompatible on anything but the most basic level there wasn't much alternative than vastly divergent code paths.
An install time check would cause problems if you changed VMs post installation.
How does that technique solve the problem where a feature exists but is implemented differently?
I suppose that may depend on how they are handling mail etc now. If different units within the org are handling their own servers then there may be a lot of redundant duplication of effort that could be cut out by moving to a single external provider.
I disagree with that because that's the sort of company I work in! We have the in house expertise but that expertise is used far more effectively in delivering services to our customers.
Having them spend any time whatsoever babysitting something as colossally dull as mail/calendar etc would be a waste of their expertise.