The old interface was maxed. It had to be changed. It is better that
users go through the trouble of updating a legacy API than to have
continual complaints "I'm out of ttys!" pouring in. Look at how many
people constantly complain that their eth0 is getting tons of errors and
it's an emergency and we need to get our act in gear and patch the kernel
`right now!'
Supporting legacy software in this manner is a developers nightmare and
-hinders- advancement.
You don't put electronic fuel injection modules atop an engine from a
Model T. If you want the EFI, you get the car that supports it. We'd
still be half stuck in horse buggies if the auto industry supported all
legacy equipment.
We'll never make it to `Star Trek' this way. We'll become the Borg. A
huge collective of old APIs, but we assuredly will be the most bloated
slowest hunk of software ever made.
> david parsons \bi/ Contemplating, with horror, the thought of having
> \/ to maintain a collection of kernel patches so I
> don't have to patch the 40 or so machines that
> I run Linux on.
- if you're always patching with all 40. combine them. make your kernel
on your lab build machine and distro it. optimise your process.
- if you're always applying those patches, submit them here
- you are always welcome to modify your kernel as you see fit. the
developers are focused on what is best for everyone.
- if you are frequently updating your kernel, you are showing a desire to
maintain some order of currency. why not keep everything current.
It is nice to have a 300+ day uptime on a server, but is the cost of
maintaining that vigil over an increasingly insecure kernel worth the
effort made to protect it? A singular site wide update on a regular basis
ensures that you're covered. Many bugs in software are found and fixed by
the developers long before some 14yr old punk figures it out and tries to
crash your systems.
Keeping current is also keeping safety, security, and stability.
good day,
-d
-- Look, look, see Windows 98. Buy, lemmings, buy! (c) 1998 David Ford. Redistribution via the Microsoft Network is prohibited. for linux-kernel: please read linux/Documentation/* before posting problems
- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.rutgers.edu Please read the FAQ at http://www.altern.org/andrebalsa/doc/lkml-faq.html