A Run Down Of VT Switching On Linux

[duby229]

This is, in some ways, about increasing modularity, Vim. Yes that increase in modularity means that certain things you used to be able to be assumed to available by default no matter what, may not be. Modularity is good, but yes it can come at some expense-- in this case a learning curve for 'the new way.'

I point you to xkcd: http://xkcd.com/1172/ Every change breaks someones workflow Instead of shouting from the heavens to "Make no more changes!" Just accept change as an inevitable part of life. Evolution teaches adapt or die... Take a lesson from it.

The question is, and this is what I think a lot of devs fail to take into consideration, how many peoples workflow gets broken by inconsiderate changes? Is it 1% or is it 90%? Pretty much every dev I know personally is incapable of conceptualizing quality control through to the end product. (either due to ignorance or bias) (devs seem to tend to think that their way is the only good way) (if you take two devs with differing opinions, chances are they are both thinking that their way is the only good way)

[droste]

Pretty much every dev I know personally is incapable of conceptualizing quality control through to the end product.

Are you a developer? Have you ever tried creating a product which pleases everybody? It's simply impossible for a slightly larger application, because you reach a point where user wishes are mutually exclusive.

[duby229]

Are you a developer? Have you ever tried creating a product which pleases everybody? It's simply impossible for a slightly larger application, because you reach a point where user wishes are mutually exclusive.

That's true, but is it 1% or is it 90%? That's what a lot of devs don't consider. That's why should quote whole posts instead of taking one sentence out of context.

[mrugiero]

so why keep this dinosaur in the kernel? i leave it to you

Don't leave it to me, because my opinion is it shouldn't be in the kernel. But I acknowledge my opinion is based just on a personal preference, and not in facts.
The reasons you gave still leave the door open to "why not a rewrite/redesign it in kernel, instead of reaping them?".

Revoke() is already implemented on BSDs, and I believe on Solaris too. So these people disagree.

If you have very complex scenarios, you should be able to use such a complex userspace system compositor to handle them. But the kick is you shouldn't kill the simple functionality for the people who want it at the same time.

The question is, who will maintain that, if the user space solution gets wider use? Unmaintained code bit rots.

It's a terminal emulator in the kernel. Terminal emulators are UI, and all the other terminal emulators (which are also all better than linux-console) are in userland. The kernel handles drivers, it has no reason to go handling UI, or processes (that's the job of init). The fact that it's in the kernel also makes it inflexible, because as mentioned you're not going to merge font rendering libraries etc. into the kernel, which means that linux-console is going to be forever limited. That is also a problem, because distributions usually just use that, instead of normal, useful userland terminal emulators (otherwise there are conflicts, because the TTY system is not up to the task).

This is the kind of reason I was looking for.

[Ericg]

That's true, but is it 1% or is it 90%? That's what a lot of devs don't consider. That's why should quote whole posts instead of taking one sentence out of context.

Well lets think about this for a second... What are the uses for a computerized system, using Linux, that dont have to worry about init at all?

Dvd players? Launch apps, need init.
Car systems? Launch apps, play music, bluetooth, etc, need init
Laptops? Need init
Desktops? need init
Servers? Need init
Supercomputers? Need init
Smart phones? Need init
Tablets? Need init
Routers? Need init

Those are just what I came up with off the top of my head in about 10 seconds of thinking about it. So lets answer your question duby, since you did pose it. Is it the 1% or the 90% where now requiring init will be 'different' than what they are used to? I would argue that this will only be a REAL "change" for the 1%

[duby229]

I do have some reservations about it, but I do agree with you that this particular change doesnt look like that many people will even be aware of it. If it's done right it should be mostly transparent. My comment was intended to be generic, because the post I was responding to was generic.


I don't like quoting single sentences out of context, but this is the line I was responding to...

I point you to xkcd: http://xkcd.com/1172/ Every change breaks someones workflow Instead of shouting from the heavens to "Make no more changes!" Just accept change as an inevitable part of life. Evolution teaches adapt or die... Take a lesson from it.

change just for the sake of change isnt often a good thing. and the devs who perpetuate that are often ignorant or biased.

[Ericg]

I do have some reservations about it, but I do agree with you that this particular change doesnt look like that many people will even be aware of it. If it's done right it should be mostly transparent. My comment was intended to be generic, because the post I was responding to was generic.


I don't like quoting single sentences out of context, but this is the line I was responding to...

Fair enough, but accidental / deliberate or not.. You did actually raise a good point to be made. Who will care about this? Not most people. This is the same issue that was raised in the "Fedora: Orphan non-KMS drivers." Do we purposefully limit the ENTIRE community because of the needs or desires of the 1%? Or do we realize that there will always be SOMEONE who will be affected negatively by ANYTHING, and we just make sure that the negativity is limited when the time comes?

[duby229]

Fair enough, but accidental / deliberate or not.. You did actually raise a good point to be made. Who will care about this? Not most people. This is the same issue that was raised in the "Fedora: Orphan non-KMS drivers." Do we purposefully limit the ENTIRE community because of the needs or desires of the 1%? Or do we realize that there will always be SOMEONE who will be affected negatively by ANYTHING, and we just make sure that the negativity is limited when the time comes?

I don't see anything wrong with targeting the 1% if that was the point. But if the point is thta everyone should have use something, but only the 1% finds it useful, then that I have a problem with. I don't think that is the case in this particular instance though.

[Ericg]

I don't see anything wrong with targeting the 1% if that was the point. But if the point is thta everyone should have use something, but only the 1% finds it useful, then that I have a problem with. I don't think that is the case in this particular instance though.

What I was trying to say was:

There's not a problem with targetting the 1% but, like here, we run into a problem where the 1% don't like something...but the other 99% have great ideas that they can use with what the 1% doesn't like. Do we limit ourselves because the 1% doesn't like something, or do we just accept that you can't make everyone happy and move forward?

[Vim_User]

This is, in some ways, about increasing modularity, Vim. Yes that increase in modularity means that certain things you used to be able to be assumed to available by default no matter what, may not be. Modularity is good, but yes it can come at some expense-- in this case a learning curve for 'the new way.'

This is not about having to learn a new way, this is about increasing maintenance work and potential bugs, doubling the count of packages that are to maintain and test.

Evolution teaches adapt or die... Take a lesson from it.

Evolution also teaches that more sophisticated systems are more prone to break and that sometimes the simpler systems live while the complicated die. When we are at taking lessons already.