You shouldn't. The problem of the old installer, addressed by the new d-i, is the problem of developers, not end-users. In particular, it is too difficult to make the process of creating boot floppies automatic. That made Debian stable to always release late. Perhaps this time (or rather, the next time) they really can make it to meet expectation (in release date).
> Modularity is cool, but when the dependency > list for anti-aliased fonts in a browser is > 10 seperate projects long, 3 of which don't > get along well because they don't like each > other's licenses, then people say that $129 > for Windows makes sense.
Well, it doesn't matter. What people will/should do is just "install mozilla". That 20 other packages are needed by mozilla should be completely invisible by the user. The distribution should deal with it. Sadly, not all distribution do it right at the present time, but then it should be the problem of distributions, not the problem of modularity or X.
> The difficult part is the second stage of the installation
No, no, I don't think so. The people complained about Debian not because of tasksel. After all, tasksel is just a bit more difficult than Redhat "install type". They complained it because there are so many things that Debian don't configure, and don't provide any interface to install other than reading HOWTOs.
See how sound is unconfigured, CD-RWs can't be written to, firewall accessible only to people with a text editor and time reading the long iptable doc, and even things as basic as setting date and time has no interface other than firing date and hwclock.
Don't get me wrong, Debian is now in everything I use regularly, and I love it the current way. After all, I don't have to do a system install until the next time I buy a new computer. But it is undeniable that Debian is not the easiest thing to put into your computer.
New syscalls are constantly being added. And to avoid compatibility problems, the number of arguments, expected behaviour, etc., never change once the syscall is there. So your idea boils down to "don't change the major version number, ever", which wasted one piece of info that can be given by the version number.
> The functional and performance difference between the two approaches isn't really that huge anymore, since this CISC->RISC translation doesn't slow things down a whole lot.
This ignored one critical issue: RISC instructions are so simple that small programs compile to large binaries. This means that the code cache needs to be several times as large to hold the same amount of high level code. This is where the RISC with run-time CISC to RISC hardware translation actually out-performs a pure RISC implementation.
> It does not need to be bigger than one > page, it just is.
At least that isn't what suggested by the documentation of linuxthreads (in Debian testing). In E.5 it says the following, implying that the default stack size is really just 1 page.
E.5: Does LinuxThreads implement pthread_attr_setstacksize() and pthread_attr_setstackaddr()? These optional functions are provided in recent versions of LinuxThreads (0.8 and up). Earlier releases did not provide these optional components of the POSIX standard.
Even if pthread_attr_setstacksize() and pthread_attr_setstackaddr() are now provided, we still recommend that you do not use them unless you really have strong reasons for doing so. The default stack allocation strategy for LinuxThreads is nearly optimal: stacks start small (4k) and automatically grow on demand to a fairly large limit (2M). Moreover, there is no portable way to estimate the stack requirements of a thread, so setting the stack size yourself makes your program less reliable and non-portable.
> Finally, I do not know what the > pthreads default stack size is > (user-space? what is that?) but it is > certainly larger than one page.
Why it needs to be larger than one page? The kernel will trap access to page faults due to stack overflow, and will allocate additional stack to it anyway.
> Will it still be fast enough to > overcome the final gripe about > Mozilla, namely that it's just too > slow?"
Well... but memory footprint is still a big problem, and that is the case even for the "slim" version like Galeon which does nothing more than browsing...
Okay, where did you come up with the 64K figure, and also the 1 mega (megi) byte figure?
All Intel processors have 4KiB pages. Each Linux thread has two things of its own: its own stack, which can be as small as 1 or 2 pages if the code to run is simple enough, and also its own task_struct, which is 1 page including kernel stack for the thread. So all in all, you need 12KiB for each thread. Multiplying with the 100000 figure you get 1200000KiB or 1.144GiB, which is quite affordable for a 2GiB system.
> Windows succeeded because it was > backwards-compatible. The PC was plagued by > IRQ and DMA conflicts and still took away > marketshare from Macs and Amiga.
> Linux needs to become > backwards-compatible to Windows and > needs to run Win32 applications.
OS/2 tried that, and you know its fate. You can't win market by your own merits. You have to play by the demerit of the your competitor. I don't really consider Windows to be a competitor of Linux (or vice versa), but let's consider it is. Then you don't just need Linux to be good, you need Windows to be bad, bad enough that people want to switch.
MS has made a seriously wrong move by not making their software as free as their customers want. But as shown by statistics, this is not enough to drive people over to other solutions. And, Linux is not a good enough contender at that time, anyway. Now the goal should be to make Linux attractive as an alternative, when License 6 really get people annoyed. When this happens, people should have already decided to leave MS, so no problem if MS-Word can't run. But of course another app must be there to fill its gap, and it should be able to read MS-Word created files.
I think the problem of MS license change is not that it is now subscription based, but instead because volume pricing for enterprises disappears. If MS can let both programmes run concurrently, I see there won't be any problem, and quite a few will jump to subscription based anyway (because they plan to pay anyway).
But why everybody says that because the screen is small, the number of colors doesn't matter? It's quite the reverse: if you have a large display that your eye cannot or nearly cannot distinguish the position of two points, their colors mix, so dithering will work. In a display like Palm where everybody look at it from less than 8 inch, every dot is clearly distinguishable, and no dithering can hide the color difference.
But... gotta define "color combination" "properly" first, in a way that 12-bit display can display 58621 color combinations. I've made a few tries... they either get too large or too small, nowhere near...:p
A place where the government control most of the use of computers is the ideal place to put free software into it. Nobody can say "hey! I want my Microsoft stock value back!". Nobody can say "shit, I've just purchased twenty copies of MS Office!". And, nobody will complain "why I have to pay those tax to create the software that I already have!".
Will China keep them free? Why not? There are only benefits to keep it free. Internet control only needs to be put in the ISPs. Given the computers, their people have much more brain-power than needed to produce whatever software that the government won't want their people to be running. The "unreasonable law" and "Draconian punishments" is much better solution to the problem.
> A) disposal of the old workstations and making sure they are wiped clean of all information (there's been alot of problems with this lately),
Stupid. Most hardware runs well under Linux, and actually require less horse power in the CPU to run. For the rest, the government can develop drivers for less than 1% of the cost to keep MS for one year.
> B) training of some very brain-dead users who believe that a computer without Windows is not a computer, and
Really? Did you check out recent versions of KDE and Gnome? For 90% of the needed task, Linux does it in ways exceedingly similar to Windows. The training is only for the remaining 10%, which probably won't appear in the profit and loss account at all.
> C) everything related with dismantling an ENORMOUS existing infrastructure and getting all of the new systems to work seamlessly (which equals alot of time and $$$).
Okay, this is real. But come on... you gonna being slowly eat up by the worm or to accept the pain once and get rid of it? The only sensible answer, really, is that MS lobby is real strong.
Sh*t... that's the best place for large proprietary software house like Microsoft! Automatically every software get the "learn with no cost, but when you actually get used to it, you've got to pay" tag. This basically push people out of the free software camp...
> Maybe not yet Gnome 2, but especially XFree > 4.2 is solid enough.
I've been wondering that for long as well, until I see this page...
http://people.debian.org/~branden/sid/
Well, we already have build for hppa, i386, ia64, m68k, mips, powerpc and sparc. Well... 7 architectures... but we need 11...
Let's say "good job" to Branden rather than continuing to blame Debian for trying to get a semi-finished product "XFree 4.2" into a shape that is reasonable to be included into the main archive.
> Walking through a list of modules to install is... interesting, but anything but intuititive.
Well... I won't count that as interesting indeed. But you don't need to do that for most of the modules. As described in the installation process, you (only) need to select those which are used during the installation, which means the modules for scsi if you use a SCSI disk, and network if you performs a network installation. Anything else shouldn't be done when you see the module list: they are supposed to be automatically loaded by automatically (perhaps after some configurations of/etc/modutils). You should count *that* as unintuitive.
> people who make Debian have no obligation to cater to *anyone* besides themselves
Not quite right: you always have a big IRC channel just for installation problems, and there are discussions of more user-friendly installer in debian-devel. There is even one user friendly installer adopted from Progeny which is in the main archive. The problem is that Debian community hate to see that a fancy installer makes it impossible to install Debian to an old machine using the default installer. Well... you can say that their priority is convoluted. But that doesn't mean they talk only to themselves.
> I've not tried the Red Hat up2date equivalent or a lot of other auto-update tools, but so far, apt-get is the most impressive
In short, up2date keep you out of security bugs, but also keep you out of new features. Perhaps this is done on purpose: who will buy new versions of Redhat if they can all up2date all the packages they installed? It might also be a good idea to keep new features out of it: you won't get a new postgreSQL file format, so won't trash your database server running your web services. But it does restrict choices. This is not a problem in Debian: you choose what you want, by choosing which archive to use in/etc/apt/sources.list.
> writer is unable or unwilling to repeatedly step all the way through the mental path his directions offer
You must not be a programmer, or you'll know what a nightmare is it to keep such a manual up to date. Change a dialog to within the main window, and you start having to go through the whole manual to pick up all those references to the procedure to use the dialog. I'd rather have the programmer specifying it once, and spend the remaining time on improving the code.
And... is this Debian specific?
> # "Getting 3D Acceleration on your Debian system"
Wait until X4.2 (or X4.3, whichever supporting your 3D video card) is out?:p
Well... you have to add the module to module.conf, as an (only) additional step.
> The introduction of journaling filesystems > has greatly helped this (it happens only 1 > time in 20 on an unclean shutdown, rather > than about 1 in 4), but it's still bad.
Well... you have 20 power-plug pulling before you say goodbye to your computer? Count yourselves lucky. Power-failure happens less than once a month for me, so 20 means around 2 years. I'd say, it is reasonable to do a complete filesystem checking which cost you 10 minutes after 2 years of use.
If you trust your OS and your hardware so much, feel free to invoke tune2fs and modify that, so that you absolutely need no filesystem check before you trash your harddisk. Being a programmer myself, I know that there are surprises, things like a kernel path that nobody had ever imagine happening, etc. And I know that the longer the surprise is left there, the better the chance that my data learn to fly away from me. I'd rather play safe a bit, especially if my power go away as much as once per month.
On the other hand, if your hidden motivation is that you should be able to do shutdown by pushing the power button, don't. Filesystem is filesystem. It don't know what is happening in the user space. In particular, while the filesystem is intact, the files can go away, or turn to an unusable state. It probably won't take your whole Linux box, but your work can be trashed. Make improper shutdown infrequent.
It's a bit better: redoing transactions in the journal will never fail if the hard disk hardware is intact. Fsck can get f*cked up, and by then all your data is, well, up to manual recovery.
Okay, what stable is, really? What does it mean to release 2.6.0?
To me, 2.6.0 means "okay, this is what we can possibly get if only developers are running the code. We have tested our kernel, we have high confidence that it will work for you, but, you know, there are surprises. So do try it out, if you can. We promise that if you find problems and tell us, we will put you to the highest priority, so that you don't have to fall back to 2.4.XX."
What is 2.7.0? People says that it means "okay, now we have 2.6.Y stable, we can pretty much ignore it. Let's put it in the hand of Xyz Abc, the new maintainer of 2.6 series, and new work will be placed at 2.7.ZZ". But I don't like this view. This ignores the possibility that new thing can land directly into 2.6.XX. This happened quite frequently in 2.4.XX, actually, and it does work.
I believe the real reason for 2.7.XX is that "after some use, we find that 2.6.XX has the following stupid problems. It can also be improved if we don't do things this way, but instead do things that way. But they are so fundamental to 2.6.XX, that if we ever change it, we can no longer make the claim that we made when we roll out 2.6.0. These things really needs to be done, though, but we prefer people not to use it yet, and we developers will try to make things work again after they break, and after every developers can reasonably make the claim we made when we delivered 2.6.0, we will roll out 2.8.0, when every of you can try this new neat way of doing things. Currently, please stick with what we have in 2.6.XX."
If that reasoning can stand, then what 2.7 is for is really new API. A new one that can cause everything else to break. I'd say, once we know what new API we want to create, we should create 2.7.0, *regardless* of whether 2.6.XX is stable enough or not. It is absurd to be afraid that stablization of 2.6.XX will slow down because of the existence of 2.7.YY: preference is always given to 2.6.XX if things go wrong there. The real problem to release 2.7.0 too early is that many things get implemented too quickly, when most of the API changes are still up in the air, forcing most things to be written again, perhaps for many times. When that "up-in-the-air" problem goes away (or has settled to a point that we want to write and see what will happen if we really do things in the new way), there is no excuse not to release 2.7.0. Further delay only makes sure that the next kernel will arrive late again.
Unluckily, cost goes high only when resource depletion is near, and at that time the economy won't be able to stop the consumption. By then the only option is to kill 90% of the remaining population.
Hm... In HK, where roads are everywhere and 10 times as dense as that in US, the change happened in less than 1 year, and this happened more than 10 years ago. This actually all boils down to how persistent are the policy makers.
Slashdot Mirror
> I've never minded the old installer
You shouldn't. The problem of the old installer, addressed by the new d-i, is the problem of developers, not end-users. In particular, it is too difficult to make the process of creating boot floppies automatic. That made Debian stable to always release late. Perhaps this time (or rather, the next time) they really can make it to meet expectation (in release date).
> Modularity is cool, but when the dependency
> list for anti-aliased fonts in a browser is
> 10 seperate projects long, 3 of which don't
> get along well because they don't like each
> other's licenses, then people say that $129
> for Windows makes sense.
Well, it doesn't matter. What people will/should do is just "install mozilla". That 20 other packages are needed by mozilla should be completely invisible by the user. The distribution should deal with it. Sadly, not all distribution do it right at the present time, but then it should be the problem of distributions, not the problem of modularity or X.
> The difficult part is the second stage of the installation
No, no, I don't think so. The people complained about Debian not because of tasksel. After all, tasksel is just a bit more difficult than Redhat "install type". They complained it because there are so many things that Debian don't configure, and don't provide any interface to install other than reading HOWTOs.
See how sound is unconfigured, CD-RWs can't be written to, firewall accessible only to people with a text editor and time reading the long iptable doc, and even things as basic as setting date and time has no interface other than firing date and hwclock.
Don't get me wrong, Debian is now in everything I use regularly, and I love it the current way. After all, I don't have to do a system install until the next time I buy a new computer. But it is undeniable that Debian is not the easiest thing to put into your computer.
New syscalls are constantly being added. And to avoid compatibility problems, the number of arguments, expected behaviour, etc., never change once the syscall is there. So your idea boils down to "don't change the major version number, ever", which wasted one piece of info that can be given by the version number.
> The functional and performance difference between the two approaches isn't really that huge anymore, since this CISC->RISC translation doesn't slow things down a whole lot.
This ignored one critical issue: RISC instructions are so simple that small programs compile to large binaries. This means that the code cache needs to be several times as large to hold the same amount of high level code. This is where the RISC with run-time CISC to RISC hardware translation actually out-performs a pure RISC implementation.
> It does not need to be bigger than one
> page, it just is.
At least that isn't what suggested by the documentation of linuxthreads (in Debian testing). In E.5 it says the following, implying that the default stack size is really just 1 page.
E.5: Does LinuxThreads implement pthread_attr_setstacksize() and pthread_attr_setstackaddr()?
These optional functions are provided in recent versions of LinuxThreads (0.8 and up). Earlier releases did not provide these optional components of the POSIX standard.
Even if pthread_attr_setstacksize() and pthread_attr_setstackaddr() are now provided, we still recommend that you do not use them unless you really have strong reasons for doing so. The default stack allocation strategy for LinuxThreads is nearly optimal: stacks start small (4k) and automatically grow on demand to a fairly large limit (2M). Moreover, there is no portable way to estimate the stack requirements of a thread, so setting the stack size yourself makes your program less reliable and non-portable.
Why need software to be fault tolerant, when the people are fault tolerant to the highest extent?
> Finally, I do not know what the
> pthreads default stack size is
> (user-space? what is that?) but it is
> certainly larger than one page.
Why it needs to be larger than one page? The kernel will trap access to page faults due to stack overflow, and will allocate additional stack to it anyway.
> Will it still be fast enough to
> overcome the final gripe about
> Mozilla, namely that it's just too
> slow?"
Well... but memory footprint is still a big problem, and that is the case even for the "slim" version like Galeon which does nothing more than browsing...
Okay, where did you come up with the 64K figure, and also the 1 mega (megi) byte figure?
All Intel processors have 4KiB pages. Each Linux thread has two things of its own: its own stack, which can be as small as 1 or 2 pages if the code to run is simple enough, and also its own task_struct, which is 1 page including kernel stack for the thread. So all in all, you need 12KiB for each thread. Multiplying with the 100000 figure you get 1200000KiB or 1.144GiB, which is quite affordable for a 2GiB system.
> Windows succeeded because it was
> backwards-compatible. The PC was plagued by
> IRQ and DMA conflicts and still took away
> marketshare from Macs and Amiga.
> Linux needs to become
> backwards-compatible to Windows and
> needs to run Win32 applications.
OS/2 tried that, and you know its fate. You can't win market by your own merits. You have to play by the demerit of the your competitor. I don't really consider Windows to be a competitor of Linux (or vice versa), but let's consider it is. Then you don't just need Linux to be good, you need Windows to be bad, bad enough that people want to switch.
MS has made a seriously wrong move by not making their software as free as their customers want. But as shown by statistics, this is not enough to drive people over to other solutions. And, Linux is not a good enough contender at that time, anyway. Now the goal should be to make Linux attractive as an alternative, when License 6 really get people annoyed. When this happens, people should have already decided to leave MS, so no problem if MS-Word can't run. But of course another app must be there to fill its gap, and it should be able to read MS-Word created files.
I use dfontmgr and defoma. Anyone knows how the two systems differs structurally and in practice?
I think the problem of MS license change is not that it is now subscription based, but instead because volume pricing for enterprises disappears. If MS can let both programmes run concurrently, I see there won't be any problem, and quite a few will jump to subscription based anyway (because they plan to pay anyway).
But why everybody says that because the screen is small, the number of colors doesn't matter? It's quite the reverse: if you have a large display that your eye cannot or nearly cannot distinguish the position of two points, their colors mix, so dithering will work. In a display like Palm where everybody look at it from less than 8 inch, every dot is clearly distinguishable, and no dithering can hide the color difference.
But... gotta define "color combination" "properly" first, in a way that 12-bit display can display 58621 color combinations. I've made a few tries... they either get too large or too small, nowhere near... :p
A place where the government control most of the use of computers is the ideal place to put free software into it. Nobody can say "hey! I want my Microsoft stock value back!". Nobody can say "shit, I've just purchased twenty copies of MS Office!". And, nobody will complain "why I have to pay those tax to create the software that I already have!".
Will China keep them free? Why not? There are only benefits to keep it free. Internet control only needs to be put in the ISPs. Given the computers, their people have much more brain-power than needed to produce whatever software that the government won't want their people to be running. The "unreasonable law" and "Draconian punishments" is much better solution to the problem.
> A) disposal of the old workstations and making sure they are wiped clean of all information (there's been alot of problems with this lately),
Stupid. Most hardware runs well under Linux, and actually require less horse power in the CPU to run. For the rest, the government can develop drivers for less than 1% of the cost to keep MS for one year.
> B) training of some very brain-dead users who believe that a computer without Windows is not a computer, and
Really? Did you check out recent versions of KDE and Gnome? For 90% of the needed task, Linux does it in ways exceedingly similar to Windows. The training is only for the remaining 10%, which probably won't appear in the profit and loss account at all.
> C) everything related with dismantling an ENORMOUS existing infrastructure and getting all of the new systems to work seamlessly (which equals alot of time and $$$).
Okay, this is real. But come on... you gonna being slowly eat up by the worm or to accept the pain once and get rid of it? The only sensible answer, really, is that MS lobby is real strong.
Sh*t... that's the best place for large proprietary software house like Microsoft! Automatically every software get the "learn with no cost, but when you actually get used to it, you've got to pay" tag. This basically push people out of the free software camp...
> Maybe not yet Gnome 2, but especially XFree
> 4.2 is solid enough.
I've been wondering that for long as well, until I see this page...
http://people.debian.org/~branden/sid/
Well, we already have build for hppa, i386, ia64, m68k, mips, powerpc and sparc. Well... 7 architectures... but we need 11...
Let's say "good job" to Branden rather than continuing to blame Debian for trying to get a semi-finished product "XFree 4.2" into a shape that is reasonable to be included into the main archive.
> Walking through a list of modules to install is ... interesting, but anything but intuititive.
/etc/modutils). You should count *that* as unintuitive.
/etc/apt/sources.list.
:p
Well... I won't count that as interesting indeed. But you don't need to do that for most of the modules. As described in the installation process, you (only) need to select those which are used during the installation, which means the modules for scsi if you use a SCSI disk, and network if you performs a network installation. Anything else shouldn't be done when you see the module list: they are supposed to be automatically loaded by automatically (perhaps after some configurations of
> people who make Debian have no obligation to cater to *anyone* besides themselves
Not quite right: you always have a big IRC channel just for installation problems, and there are discussions of more user-friendly installer in debian-devel. There is even one user friendly installer adopted from Progeny which is in the main archive. The problem is that Debian community hate to see that a fancy installer makes it impossible to install Debian to an old machine using the default installer. Well... you can say that their priority is convoluted. But that doesn't mean they talk only to themselves.
> I've not tried the Red Hat up2date equivalent or a lot of other auto-update tools, but so far, apt-get is the most impressive
In short, up2date keep you out of security bugs, but also keep you out of new features. Perhaps this is done on purpose: who will buy new versions of Redhat if they can all up2date all the packages they installed? It might also be a good idea to keep new features out of it: you won't get a new postgreSQL file format, so won't trash your database server running your web services. But it does restrict choices. This is not a problem in Debian: you choose what you want, by choosing which archive to use in
> writer is unable or unwilling to repeatedly step all the way through the mental path his directions offer
You must not be a programmer, or you'll know what a nightmare is it to keep such a manual up to date. Change a dialog to within the main window, and you start having to go through the whole manual to pick up all those references to the procedure to use the dialog. I'd rather have the programmer specifying it once, and spend the remaining time on improving the code.
And... is this Debian specific?
> # "Getting 3D Acceleration on your Debian system"
Wait until X4.2 (or X4.3, whichever supporting your 3D video card) is out?
Well... you have to add the module to module.conf, as an (only) additional step.
> The introduction of journaling filesystems
> has greatly helped this (it happens only 1
> time in 20 on an unclean shutdown, rather
> than about 1 in 4), but it's still bad.
Well... you have 20 power-plug pulling before you say goodbye to your computer? Count yourselves lucky. Power-failure happens less than once a month for me, so 20 means around 2 years. I'd say, it is reasonable to do a complete filesystem checking which cost you 10 minutes after 2 years of use.
If you trust your OS and your hardware so much, feel free to invoke tune2fs and modify that, so that you absolutely need no filesystem check before you trash your harddisk. Being a programmer myself, I know that there are surprises, things like a kernel path that nobody had ever imagine happening, etc. And I know that the longer the surprise is left there, the better the chance that my data learn to fly away from me. I'd rather play safe a bit, especially if my power go away as much as once per month.
On the other hand, if your hidden motivation is that you should be able to do shutdown by pushing the power button, don't. Filesystem is filesystem. It don't know what is happening in the user space. In particular, while the filesystem is intact, the files can go away, or turn to an unusable state. It probably won't take your whole Linux box, but your work can be trashed. Make improper shutdown infrequent.
It's a bit better: redoing transactions in the journal will never fail if the hard disk hardware is intact. Fsck can get f*cked up, and by then all your data is, well, up to manual recovery.
Okay, what stable is, really? What does it mean to release 2.6.0?
To me, 2.6.0 means "okay, this is what we can possibly get if only developers are running the code. We have tested our kernel, we have high confidence that it will work for you, but, you know, there are surprises. So do try it out, if you can. We promise that if you find problems and tell us, we will put you to the highest priority, so that you don't have to fall back to 2.4.XX."
What is 2.7.0? People says that it means "okay, now we have 2.6.Y stable, we can pretty much ignore it. Let's put it in the hand of Xyz Abc, the new maintainer of 2.6 series, and new work will be placed at 2.7.ZZ". But I don't like this view. This ignores the possibility that new thing can land directly into 2.6.XX. This happened quite frequently in 2.4.XX, actually, and it does work.
I believe the real reason for 2.7.XX is that "after some use, we find that 2.6.XX has the following stupid problems. It can also be improved if we don't do things this way, but instead do things that way. But they are so fundamental to 2.6.XX, that if we ever change it, we can no longer make the claim that we made when we roll out 2.6.0. These things really needs to be done, though, but we prefer people not to use it yet, and we developers will try to make things work again after they break, and after every developers can reasonably make the claim we made when we delivered 2.6.0, we will roll out 2.8.0, when every of you can try this new neat way of doing things. Currently, please stick with what we have in 2.6.XX."
If that reasoning can stand, then what 2.7 is for is really new API. A new one that can cause everything else to break. I'd say, once we know what new API we want to create, we should create 2.7.0, *regardless* of whether 2.6.XX is stable enough or not. It is absurd to be afraid that stablization of 2.6.XX will slow down because of the existence of 2.7.YY: preference is always given to 2.6.XX if things go wrong there. The real problem to release 2.7.0 too early is that many things get implemented too quickly, when most of the API changes are still up in the air, forcing most things to be written again, perhaps for many times. When that "up-in-the-air" problem goes away (or has settled to a point that we want to write and see what will happen if we really do things in the new way), there is no excuse not to release 2.7.0. Further delay only makes sure that the next kernel will arrive late again.
Unluckily, cost goes high only when resource depletion is near, and at that time the economy won't be able to stop the consumption. By then the only option is to kill 90% of the remaining population.
It's never too early to worry.
Hm... In HK, where roads are everywhere and 10 times as dense as that in US, the change happened in less than 1 year, and this happened more than 10 years ago. This actually all boils down to how persistent are the policy makers.