Want to read Slashdot from your mobile device? Point it at m.slashdot.org and keep reading!


Forgot your password?
Take advantage of Black Friday with 15% off sitewide with coupon code "BLACKFRIDAY" on Slashdot Deals (some exclusions apply)". ×

Comment Re: Linus Torvalds Isn't Looking 10 Years Ahead (Score 1) 108

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? :)

Comment Re:Software error ... (Score 1) 234

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.

Comment Re:But, but, but... (Score 2, Informative) 234

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.

Comment Re:Linus Torvalds Isn't Looking 10 Years Ahead (Score 2) 108

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.

Comment Re:From SLS to Slackware (Score 1) 136

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.

Comment Re:Of course not (Score 2) 365

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.

Comment Re:Of course not (Score 1) 365

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.

"Spock, did you see the looks on their faces?" "Yes, Captain, a sort of vacant contentment."