Your reasoning falls short. Linus isn't the driver of new features. He's the head maintainer. Many other people contribute code they need to do new things. He vets it and makes sure it doesn't break the rest of the kernel. He enables other people to do the innovative things by giving them a well-maintained place to put them.
It's true that Linus is simply the head of the maintenance tree, but the fact that he isn't the driver of new features seems to support my thesis that he doesn't have much need to look ahead very far. That function is generally handled by others lower in the tree, or completely outside of it.
I'm not sure I see my logic failure. Could you elaborate? Am I emulating Eliza?:)
No, no, no, no, no! The concept of garbage collecting is a reaction to poor coding practices and reliance on it is laziness. Software engineers responsible for real-time, public safety software should be capable of managing memory in their code!
Meh. Real-time public safety software should not be running in an environment which allows an application to arbitrarily request memory.
I've written code for multiple mainframe online transaction environments and in UNIX C/C++ and Java environments. Guess which one is more problematic when it comes to memory leaks and other similar issues?
I'm hardly suggesting that a mainframe environment is a viable answer, but the approach that such environments take was taken for a reason. Controlled environments are far less prone to programmer stupidity than uncontrolled ones.
One advantage of many airline online transaction systems: An applications programmer cannot do a malloc equivalent.
Programs are created with a fixed memory size, and complex applications are simply a series of program modules which pass data between each other via common memory areas or memory-mapped files.
Memory leaks in such an environment are quite rare.
Linux isn't a corporation. Also, for something as specific as an OS kernel, I'm not sure there's much to be said for looking out in a detailed manner more than a few major iterations in advance. Sure, there are probably features being considered all the time, but that doesn't make them a focus.
SLS was fun to play with, but sadly that's all I did. I grabbed a boot and root diskette image plus the A and B series diskettes from a local BBS in the Twin Cities sometime in 1993. SPS 099pl13 or something. Moobasi BBS? Anyway, I also grabbed the X series for XFree86, but I couldn't get it to work (I might've had a Diamond Stealth VRAM at the time which didn't play nice outside of Windows), so I mostly just putzed on the command line.
By the time I tried Slackware for my 486, I'd upgraded to a CL5343-based Speedstar 64 because it worked with OS/2, and XFree86 was perfectly happy.
From there, I want to RH4.2 I think. Red Hat was not to bad with fvwm. It was fun to tinker with the various window managers. olwm, mwm, etc. I didn't really use Linux "seriously" until much latter. I was happy with my OS/2 2.1 GA+SP setup, and with Warp 3, so Linux was more a curiosity than a necessity for me.
It would be easier to teach new programmers the old mainframe environment we used to use than the new Java environment that replaced it. Not that Java is inherently difficult in itself. It's just that the newer system had to reinvent so many wheels that were performed "under the hood" on the mainframe that the application itself became a lot more complex. On the older system, applications programmers could concentrate on the application and not networking, file logging, security, etc.
One of the reasons cited for moving off the old environment was a lack of people with mainframe skills. Mainframe isn't a skill... it's just an OS, editor, set of languages, and programmer environment like anything else, and simpler than many.
If you are over 30 and a programmer, your walker will be arriving shortly. Security will be on hand to escort you out.
Thankfully, not all companies are that shortsighted.:) I'm past your limit by 20 years now, and yet I'm still elbows deep in code and relatively young compared to many of my cow orkers, though as of last year it's more shell, PHP, Perl, and C++ bits than the Fortran 77 I was writing back when I started my career.
My most recent partner in crime (manager, teammate, etc.) just retired in January of this year. He had 20 years of seniority on me, literally, and he was still very very good at what he did.
Don't underestimate the combination of a good mind, good training, and a few solid decades of hard-earned OJT. Sometimes younger programmers are better, and that's good, but having an old fart or three around to mentor (and help by spotting and correcting blatant mistakes) is one of the fastest ways to learn. I had several mentors coming out of college, and i'm thankful for all of them.
VirtuaWin is neither buggy nor slow. I've used it for years on XP boxes, and even though I prefer some Linux virtual desktop implementation, this one is at least as good than most of those.
Athletes degrade somewhat more than programmers do by the age of 40.:-)
I juggle C, Perl, PHP, Java, Fortran, assembly, and a few macro languages most Slashdotters have never heard of in my current position, sometimes in the same day. You need it, I'll code it. If it's something new, I'll learn it and stick it in the toolkit with the other few dozen other languages I've learned on the job over the years...
In the programming world I've been a part of for almost 23 years, "programmer" has actually meant designer, developer, unit and system tester, tech writer, system implementer, and application/system support person as well as level 3 help desk and several other roles.
If you think I'd have been happy being a simple code monkey for two decades, you need help.:-)
There are advantages in having one person able to do the work of a half-dozen others, and someone who does it well can get the job done without having to stretch the work week to unreasonable lengths.
It sounds like some folks simply haven't found a (relatively) sane shop in which to hang their hat, or have never really worked with a good experienced programmer.
Wasn't support for older or dying platforms supposed to be one of the advantages of open source?
Do Open Source projects really want to put themselves in the position of being the reason people move to the latest version of the popular proprietary platform?
The internet is accessible to all kinds of machines and operating systems. Just because you're using the latest and greatest popular platform doesn't mean everyone else is. I sometimes use XP, Win2K, Win95OSR2, various flavors of Linux, and even old classics like BeOS 5 from time to time. Why should that concern you?
Luddite. Piffle. Good multithreaded GUI software used to run in 1MB of RAM. I would rather be a luddite than dependent in the horsecrap that substitutes for good software these days.:-)
If if compare the usability experience of the 1993 WPS on OS/2 and *any* modern Desktop Environment in terms of consistency, accessibility and general performance, WPS beats them all.
You know it. I know it. Sadly, the folks doing interface design for these projects don't know it.:-(
No, some format shifting is explicitly legal. The Philips 765 CD burner that I own, for example, is explicitly intended to convert analog audio from other stereo components into digital and record it on CD, or make digital copies of existing CDs, but it (a) will only burn to CD-R discs which are marked "Digital Music" (making sure the music industry gets a cut of the CD price), and has certain copyright features(SCMS) in place to limit making multi-generation copies.
Slashdot Mirror
Your reasoning falls short. Linus isn't the driver of new features. He's the head maintainer. Many other people contribute code they need to do new things. He vets it and makes sure it doesn't break the rest of the kernel. He enables other people to do the innovative things by giving them a well-maintained place to put them.
It's true that Linus is simply the head of the maintenance tree, but the fact that he isn't the driver of new features seems to support my thesis that he doesn't have much need to look ahead very far. That function is generally handled by others lower in the tree, or completely outside of it.
I'm not sure I see my logic failure. Could you elaborate? Am I emulating Eliza? :)
You're getting grumpy, old man. :-)
Nothing a good card sorter couldn't fix. That's why we use line numbers on our COBOL decks and all that. :)
Er. UseD. UseD. :)
No, no, no, no, no! The concept of garbage collecting is a reaction to poor coding practices and reliance on it is laziness. Software engineers responsible for real-time, public safety software should be capable of managing memory in their code!
Meh. Real-time public safety software should not be running in an environment which allows an application to arbitrarily request memory.
I've written code for multiple mainframe online transaction environments and in UNIX C/C++ and Java environments. Guess which one is more problematic when it comes to memory leaks and other similar issues?
I'm hardly suggesting that a mainframe environment is a viable answer, but the approach that such environments take was taken for a reason. Controlled environments are far less prone to programmer stupidity than uncontrolled ones.
One advantage of many airline online transaction systems: An applications programmer cannot do a malloc equivalent.
Programs are created with a fixed memory size, and complex applications are simply a series of program modules which pass data between each other via common memory areas or memory-mapped files.
Memory leaks in such an environment are quite rare.
Linux isn't a corporation. Also, for something as specific as an OS kernel, I'm not sure there's much to be said for looking out in a detailed manner more than a few major iterations in advance. Sure, there are probably features being considered all the time, but that doesn't make them a focus.
Heh. I'll reply to this non-anonymously. :-)
SLS was fun to play with, but sadly that's all I did. I grabbed a boot and root diskette image plus the A and B series diskettes from a local BBS in the Twin Cities sometime in 1993. SPS 099pl13 or something. Moobasi BBS? Anyway, I also grabbed the X series for XFree86, but I couldn't get it to work (I might've had a Diamond Stealth VRAM at the time which didn't play nice outside of Windows), so I mostly just putzed on the command line.
By the time I tried Slackware for my 486, I'd upgraded to a CL5343-based Speedstar 64 because it worked with OS/2, and XFree86 was perfectly happy.
From there, I want to RH4.2 I think. Red Hat was not to bad with fvwm. It was fun to tinker with the various window managers. olwm, mwm, etc. I didn't really use Linux "seriously" until much latter. I was happy with my OS/2 2.1 GA+SP setup, and with Warp 3, so Linux was more a curiosity than a necessity for me.
The white house cannot lie. It's a house. :-) But the residents thereof might.
You must be new. Cerfification does not imply functional. :(
It would be easier to teach new programmers the old mainframe environment we used to use than the new Java environment that replaced it. Not that Java is inherently difficult in itself. It's just that the newer system had to reinvent so many wheels that were performed "under the hood" on the mainframe that the application itself became a lot more complex. On the older system, applications programmers could concentrate on the application and not networking, file logging, security, etc.
One of the reasons cited for moving off the old environment was a lack of people with mainframe skills. Mainframe isn't a skill ... it's just an OS, editor, set of languages, and programmer environment like anything else, and simpler than many.
If you are over 30 and a programmer, your walker will be arriving shortly. Security will be on hand to escort you out.
Thankfully, not all companies are that shortsighted. :) I'm past your limit by 20 years now, and yet I'm still elbows deep in code and relatively young compared to many of my cow orkers, though as of last year it's more shell, PHP, Perl, and C++ bits than the Fortran 77 I was writing back when I started my career.
My most recent partner in crime (manager, teammate, etc.) just retired in January of this year. He had 20 years of seniority on me, literally, and he was still very very good at what he did.
Don't underestimate the combination of a good mind, good training, and a few solid decades of hard-earned OJT. Sometimes younger programmers are better, and that's good, but having an old fart or three around to mentor (and help by spotting and correcting blatant mistakes) is one of the fastest ways to learn. I had several mentors coming out of college, and i'm thankful for all of them.
Many developers share that view. Many others do not. Is this really the time and place?
"Go" at a stop light or stop sign means "go with caution" anyway, so the behavior of others doesn't matter as long as you drive defensively.
I think most posters here are too young to know what you're talking about. :-)
VirtuaWin is neither buggy nor slow. I've used it for years on XP boxes, and even though I prefer some Linux virtual desktop implementation, this one is at least as good than most of those.
Athletes degrade somewhat more than programmers do by the age of 40. :-)
I juggle C, Perl, PHP, Java, Fortran, assembly, and a few macro languages most Slashdotters have never heard of in my current position, sometimes in the same day. You need it, I'll code it. If it's something new, I'll learn it and stick it in the toolkit with the other few dozen other languages I've learned on the job over the years...
In the programming world I've been a part of for almost 23 years, "programmer" has actually meant designer, developer, unit and system tester, tech writer, system implementer, and application/system support person as well as level 3 help desk and several other roles.
If you think I'd have been happy being a simple code monkey for two decades, you need help. :-)
There are advantages in having one person able to do the work of a half-dozen others, and someone who does it well can get the job done without having to stretch the work week to unreasonable lengths.
It sounds like some folks simply haven't found a (relatively) sane shop in which to hang their hat, or have never really worked with a good experienced programmer.
I will enthusiastically second Lord of Light. One of my all-time favorites!
Would leading zeros be acceptable? :-)
Wasn't support for older or dying platforms supposed to be one of the advantages of open source?
Do Open Source projects really want to put themselves in the position of being the reason people move to the latest version of the popular proprietary platform?
The internet is accessible to all kinds of machines and operating systems. Just because you're using the latest and greatest popular platform doesn't mean everyone else is. I sometimes use XP, Win2K, Win95OSR2, various flavors of Linux, and even old classics like BeOS 5 from time to time. Why should that concern you?
Luddite. Piffle. Good multithreaded GUI software used to run in 1MB of RAM. I would rather be a luddite than dependent in the horsecrap that substitutes for good software these days. :-)
Not very intuitive for GUI-centric users, which would be a sizable percentage of Ubuntu's target audience.
What spyware is installed on an iPhone out of the box, pray tell?
You know it. I know it. Sadly, the folks doing interface design for these projects don't know it. :-(
No, some format shifting is explicitly legal. The Philips 765 CD burner that I own, for example, is explicitly intended to convert analog audio from other stereo components into digital and record it on CD, or make digital copies of existing CDs, but it (a) will only burn to CD-R discs which are marked "Digital Music" (making sure the music industry gets a cut of the CD price), and has certain copyright features(SCMS) in place to limit making multi-generation copies.
The Audio Home Audio Recording Act of1992 explicitly allows for such format shifting as long as authorized equipment is used.