You wouldn't believe how many "professional" programmers don't do this. Truncatation is OK (via strncpy) -- not great, but OK. Writing beyond the end of your allocated memory is just horrible. Where I work, we just had several nasty bugs because of things like this:
1. C++ does not include garbage collection for efficiency reasons. However, if you want it, libraries supporting garbage collection are available (Great Circle, for example).
2. A pure virtual class is an interface.
3. What where you smoking when you said that C++ has no standardized libraries!!??? Have you used C++ in the last few years? Check out something called "The Standard C++ Library," part of the ISO C++ standard, and included with every modern C++ compiler. It has standard classes for strings, lists, vectors, i/o, etc.
In theory, at least, using CORBA doesn't tie you in to any particular vendor any more than XML does, since CORBA is standardized. Of course this won't be true in practice for a while.
XML is a good way for applications to exchange data, but it is not a great way for applications to call other application's code in a language independent way. Aside from all the network stuff (which many see as the raison d'etre of CORBA), CORBA and COM are good at providing a language independent interface to shared libraries and applications. That's why Gnome and KDE are using CORBA to provide OLE style linking and embedding, and sharing of common modules. XML doesn't even begin to address this sort of thing.
I've just started reading the book, so I can't really comment on it. I do have a question, however, for those who have read it.
Does this book effectively address how to effectively implement an iterative process, as oppossed a waterfall process? A lot of contemporary methodologies pay lip service to the idea of iterative design and development (with lots of recursive arrows on the process diagrams), but this is often very difficult to implement in a corporate environment. (Easier on web-based/open source projects.) On my projects where I own everything, I constantly go back and revise specs. But on a large coporate project, changing the spec can be a big deal and take a long time, so it tends not to get done -- once the spec is written, it's set in stone. I suppose tools would help here.
Also, how do the authors feel about using UML tools like RationalRose for code generation? It seems like that could be pretty handy, but I worry that people would start using the diagrams as an implementation tool, instead of a design illustration tool. The diagrams could get too complicated, and hard to understand. What Fred Brookes said about flow-charts might apply here -- a little bit goes a long way. One simple, unclutterd UML diagram could be more useful than lots of really complicated diagrams.
I tried OpenLinux 2.2 also. Pretty nice, but I coundn't find the source to the installer, and more annoyingly, the "booter" thingy that displays messages about what services are starting, etc., when you boot up. I wanted to change or configure a few things, but there was no source or documentation, or a least I couldn't find it.
Also, as someone else mentioned, they tweaked the kernel, so you can't just download the lastest kernel patches and upgrade your kernel. Very annoying. Suse has a custom kernel also, but the standard kernel works just fine with their distro. If you build the standard Linux kernel with OpenLinux, the fancy gui boot messages thingy stops working.
I think he was just stating his opinion based on his personal experiences. Obviouly he wasn't implying that a scientific study had been conducted.
I agree with his basic point. In my experience also, a large percentage of them are, thus the stereotype. Stereotypes often have at least a grain of truth to them.
Have you ever hung out in a University English department (I have)? There are lots of Charlenes. Anyway, what makes caricatures of post-modernists so sacronsat? Most of post-modernism is mumbo-jumbo that deserves to be satirized. Satire and characature have a long and respected history in literature, going back to Jonathan Swift, even the Eripides, and it has a useful corrective effect on public opinion.
Would you have been more happy if Stephenson satirized Microserfs, or Bill Gates instead? Or maybe Repulicans? Why are po-mo feminists taboo?
This is Stephen's best book yet. It's a book about men, and their perspective's on women, but so what? A book on cryptography, soldiers fighting in WWII, and hacking is going to be a male-oriented book if it wants to be realistic. We might wish that there were equal numbers of female/male hackers-math-geeks-etc., but the fact is most of them are men.
You'll see a lot of the same politically in-correct, anti-postmodernism attitudes reflected in the Victorians in "The Diamond Age," another great book.
In Japanese, Japan is pronounced "Nippon," or "Nihon" nowadays. "Nihon" is an alliteration of "Nippon" -- Japanese sometimes soften a double p sound into an h sound.
Yup, it's a good book -- I'm working my way through it right now. More elaborate examples towards the end would've been nice. Also, I hope they come out with a second edition that really covers Qt 2.0. Maybe a second volume covering more advanced stuff.
This isn't all bad. Mandrake/MacMillan might force RedHat to lower their prices. Also, M/M will appeal to users who want a stable desktop that doesn't crash installed by default (ie, KDE by default, not Gnome).
If RedHat is the primary vendor, then they can force Gnome and higher prices down the average Joe's throat. (More enlightened users can get RedHat from CheapBytes, or use Debian, and easily switch to KDE if they prefer. But I'm talking about the average Joe going into BestBuy, and sticking with all the defaults after installation, and thinking that all of Linux sucks because Gnome crashes.)
Would Bruce Parens, Eric Raymond, or anyone else from OSI or SPI care to talk about this? I don't recall the exact wording of Peren or Raymonds statements, or the wording on SPI's page, but they certainly left the impression that there was something worth disputing about -- that either the term was trademarked or registered to be.
Why the big soap opera much ado about nothing? Were these guys hiding the truth from us (that there was no Open Source trademark)? Or were they ignorant of the fact that the trademark expired? If the latter, then they're incompetent in legal matters and shouldn't be handling trademark issues at all.
Not that I'm flaming Raymond, Perens, et al, but this is really embarassing.
Well, I'm not sure. Does anyone out there know? Which came first, Debian's or RedHat's package manager?
Anyway, that doesn't really change my main point, which was that having one dominant vendor, even with open source products, can lead to distortions in the market place, similar to what happened with the Macintosh vs. Windows desktops, where the best product doesn't necessarily win. RedHat's sponsorship of Gnome is going to give Gnome an advantage in the Unix desktop competition that has nothing to do with its merit.
I disagree. I think it is possible to create a nice integrated desktop environment for Unix. KDE proves that. Several people I know, myself included, feel more comfortable with KDE than Windows. It's definitely an improvement over fvwm, twm, mwm, etc. I'm not sure what you mean when you say the improvements are merely "cosmetic." All user-interface improvements are cosmetic at some level. I prefer to drag and drop icons to set up my desktop over edit configuration or resource files, for example. The result is the same, and I'm perfectly capable of editing configuration files, but dragging and dropping saves me time. The advantage of a unix environment is that the confiration files are still there for me to edit, if I want to. Same thing with graphical equivalents of command-line tools. I can always drop back to the command line when I want to. Some argue that graphical tools dumb down the user, that the user isn't forced to learn the command line stuff. (Neal Stephenson says this). That may be true, but it doesn't affect me, since I already know all the command line stuff.
As far as component programming goes, I partially agree with you there. I don't know where all this stuff (CORBA, etc.) will go. I'm hopeful, however. The STL is a resuable set of components that I use every day. That demonstrates that resuable components are at least possible, if not common.
It's great that RedHat is spending a money on Linux, and that everything they do is GPL'd. Rpm, in particular, has been a great boon to Linux. (Debian's package manager might be better, but rpm came first).
But, remember Brooks' (sp?) law -- Adding more programmers to a late project makes it later. Or, pouring more money into an ill-conceived project (Gnome, Windows) just makes it bigger, and bloatier. Through shear brute-force effort you may be able to patch most of the obvious bugs , but you won't have a stable, maintainable, extendable system without starting from scratch with a cleaner architecture.
Gnome is an ill-conveived system. It's architecture was thrown together in haste, and many of it's most praised features, like "window manager independence" were in fact just spin on the fact that they hadn't thought things through. "Language independence" means that they coded everything in the lowest common denominator, "C". They have not acheived true language independence through Corba, yet. Object-oriented programming works very well in gui programming. Although object-oriented programming is possible in languages that don't directly support it (witness Motif, Gtk), just as it's possible to program in a procedural style using assembly, it's a lot easier to do object-oriented programming in languages that support object-oriented programming. Again, if you want true language independence, use CORBA.
But, Gnome's failure wouldn't be a big deal if it were just one of among many desktop attempts. Darwinism, letting the best code win, is one of the open source model's strengths. You get some duplication of effort, sure, but that effort doesn't usually waste much money since it's programmers working on their own time. In Gnome's case, however, RedHat is unlikely just to drop it and use something else. They have too much money invested in it. So, RedHat will continue pushing Gnome in the media, and will still be the default desktop environment in their distribution. Even though it's inferior. This will hamper the development of end user applications for Linux, since Gnome is an awkward system to write for. Of course developers could just write for KDE, or wxWindows (which wraps Gtk nicely), or whatever, but they can't ignore default desktop environment on the dominant distribution if they want their apps to be widely used. Gnome is already slowing down end-user acceptance of Linux. If Joe User walks into Best-Buy to buy Linux, he'll probablly pick up RedHat. He'll probablly also use Gnome as his windowing environment, since that's what comes up by default. He'll probablly also get really frustrated when Gnome locks up, when he finds out he has two control panels to worry about (Enlightenment's and Gnomes), etc.
In spite of all this, I still think RedHat has done many great things for the community. I just think that we're sticking our heads in the sand if we deny the fact that there are some down sides to RedHat's dominence (in the U.S., at least).
-------------------------------------------
Re:Not flamebait: KDE 1.1.1 and RH6 are stable
on
Red Hat Growing Pains
·
· Score: 1
I installed the KDE that came with RedHat 6.0. Problems, weird directories, etc.
Removed them, downloaded the sources from kde.org, built and installed them. No problems.
So much for RedHat's install making things easier.
Any talk of porting Delphi or C++ Builder? This would be a much be bigger challenge than JBuilder or Interbase. Interbase is mostly non-gui (and perhaps it had already been ported to other Unix platforms before Linux???). JBuilder would require no porting if it were written in pure Java to begin with, and if Java were truly platform independent.
Slashdot Mirror
Surely this is a parody.
Yes!
// aaaaaaah!
You wouldn't believe how many "professional" programmers don't do this. Truncatation is OK (via strncpy) -- not great, but OK. Writing beyond the end of your allocated memory is just horrible. Where I work, we just had several nasty bugs because of things like this:
char buf[16];
strpcy(buf, getenv("SOME_VAR"));
Should be:
char buf[16];
strncpy(buf, gentenv("SOME_VAR"), sizeof(buf)-1);
Of course, if you're using C++, you can avoid the whole issue by using the string class, which holds variable length strings:
string s = getenv("SOME_VAR");
What about Scheme? How does that compare to Common Lisp?
A few retorts:
1. C++ does not include garbage collection for efficiency reasons. However, if you want it, libraries supporting garbage collection are available (Great Circle, for example).
2. A pure virtual class is an interface.
3. What where you smoking when you said that C++ has no standardized libraries!!??? Have you used C++ in the last few years? Check out something called "The Standard C++ Library," part of the ISO C++ standard, and included with every modern C++ compiler. It has standard classes for strings, lists, vectors, i/o, etc.
---------------------------------------------
In theory, at least, using CORBA doesn't tie you in to any particular vendor any more than XML does, since CORBA is standardized. Of course this won't be true in practice for a while.
XML is a good way for applications to exchange data, but it is not a great way for applications to call other application's code in a language independent way. Aside from all the network stuff (which many see as the raison d'etre of CORBA), CORBA and COM are good at providing a language independent interface to shared libraries and applications. That's why Gnome and KDE are using CORBA to provide OLE style linking and embedding, and sharing of common modules. XML doesn't even begin to address this sort of thing.
--------------------------------------
Didn't Eric Raymond cite Mozilla as an open source success story in his latest piece?
I've just started reading the book, so I can't really comment on it. I do have a question, however, for those who have read it.
Does this book effectively address how to effectively implement an iterative process, as oppossed a waterfall process? A lot of contemporary methodologies pay lip service to the idea of iterative design and development (with lots of recursive arrows on the process diagrams), but this is often very difficult to implement in a corporate environment. (Easier on web-based/open source projects.) On my projects where I own everything, I constantly go back and revise specs. But on a large coporate project, changing the spec can be a big deal and take a long time, so it tends not to get done -- once the spec is written, it's set in stone. I suppose tools would help here.
Also, how do the authors feel about using UML tools like RationalRose for code generation? It seems like that could be pretty handy, but I worry that people would start using the diagrams as an implementation tool, instead of a design illustration tool. The diagrams could get too complicated, and hard to understand. What Fred Brookes said about flow-charts might apply here -- a little bit goes a long way. One simple, unclutterd UML diagram could be more useful than lots of really complicated diagrams.
------------------------------
I tried OpenLinux 2.2 also. Pretty nice, but I coundn't find the source to the installer, and more annoyingly, the "booter" thingy that displays messages about what services are starting, etc., when you boot up. I wanted to change or configure a few things, but there was no source or documentation, or a least I couldn't find it.
Also, as someone else mentioned, they tweaked the kernel, so you can't just download the lastest kernel patches and upgrade your kernel. Very annoying. Suse has a custom kernel also, but the standard kernel works just fine with their distro. If you build the standard Linux kernel with OpenLinux, the fancy gui boot messages thingy stops working.
So, I went back to RedHat/Mandrake.
I think he was just stating his opinion based on his personal experiences. Obviouly he wasn't implying that a scientific study had been conducted.
I agree with his basic point. In my experience also, a large percentage of them are, thus the stereotype. Stereotypes often have at least a grain of truth to them.
------------------------------------------
"...doesn't mean I view all women as either sex-toys or ballbreakers. That's a one-dimensional view, in my opinion."
It certainly is, but that's obviously not Stephenson's view.
Bring this guy back for more reviews! Much more substantial than some of the Slashdot reviews.
That was a strongly worded reply!!
Have you ever hung out in a University English department (I have)? There are lots of Charlenes. Anyway, what makes caricatures of post-modernists so sacronsat? Most of post-modernism is mumbo-jumbo that deserves to be satirized. Satire and characature have a long and respected history in literature, going back to Jonathan Swift, even the Eripides, and it has a useful corrective effect on public opinion.
Would you have been more happy if Stephenson satirized Microserfs, or Bill Gates instead? Or maybe Repulicans? Why are po-mo feminists taboo?
-----------------------------------
Where is Randy derogatory??
This is Stephen's best book yet. It's a book about men, and their perspective's on women, but so what? A book on cryptography, soldiers fighting in WWII, and hacking is going to be a male-oriented book if it wants to be realistic. We might wish that there were equal numbers of female/male hackers-math-geeks-etc., but the fact is most of them are men.
You'll see a lot of the same politically in-correct, anti-postmodernism attitudes reflected in the Victorians in "The Diamond Age," another great book.
------------------------------------------
In Japanese, Japan is pronounced "Nippon," or "Nihon" nowadays. "Nihon" is an alliteration of "Nippon" -- Japanese sometimes soften a double p sound into an h sound.
Haven't finished yet, but it's a great book.
Yup, it's a good book -- I'm working my way through it right now. More elaborate examples towards the end would've been nice. Also, I hope they come out with a second edition that really covers Qt 2.0. Maybe a second volume covering more advanced stuff.
---------------------------------------
This isn't all bad. Mandrake/MacMillan might force RedHat to lower their prices. Also, M/M will appeal to users who want a stable desktop that doesn't crash installed by default (ie, KDE by default, not Gnome).
If RedHat is the primary vendor, then they can force Gnome and higher prices down the average Joe's throat. (More enlightened users can get RedHat from CheapBytes, or use Debian, and easily switch to KDE if they prefer. But I'm talking about the average Joe going into BestBuy, and sticking with all the defaults after installation, and thinking that all of Linux sucks because Gnome crashes.)
----------------------------------
Would Bruce Parens, Eric Raymond, or anyone else from OSI or SPI care to talk about this? I don't recall the exact wording of Peren or Raymonds statements, or the wording on SPI's page, but they certainly left the impression that there was something worth disputing about -- that either the term was trademarked or registered to be.
Why the big soap opera much ado about nothing? Were these guys hiding the truth from us (that there was no Open Source trademark)? Or were they ignorant of the fact that the trademark expired? If the latter, then they're incompetent in legal matters and shouldn't be handling trademark issues at all.
Not that I'm flaming Raymond, Perens, et al, but this is really embarassing.
-----------------------------
Well, I'm not sure. Does anyone out there know? Which came first, Debian's or RedHat's package manager?
Anyway, that doesn't really change my main point, which was that having one dominant vendor, even with open source products, can lead to distortions in the market place, similar to what happened with the Macintosh vs. Windows desktops, where the best product doesn't necessarily win. RedHat's sponsorship of Gnome is going to give Gnome an advantage in the Unix desktop competition that has nothing to do with its merit.
------------------------------
Yup. I see what you mean, and agree.
I disagree. I think it is possible to create a nice integrated desktop environment for Unix. KDE proves that. Several people I know, myself included, feel more comfortable with KDE than Windows. It's definitely an improvement over fvwm, twm, mwm, etc. I'm not sure what you mean when you say the improvements are merely "cosmetic." All user-interface improvements are cosmetic at some level. I prefer to drag and drop icons to set up my desktop over edit configuration or resource files, for example. The result is the same, and I'm perfectly capable of editing configuration files, but dragging and dropping saves me time. The advantage of a unix environment is that the confiration files are still there for me to edit, if I want to. Same thing with graphical equivalents of command-line tools. I can always drop back to the command line when I want to. Some argue that graphical tools dumb down the user, that the user isn't forced to learn the command line stuff. (Neal Stephenson says this). That may be true, but it doesn't affect me, since I already know all the command line stuff.
- -
As far as component programming goes, I partially agree with you there. I don't know where all this stuff (CORBA, etc.) will go. I'm hopeful, however. The STL is a resuable set of components that I use every day. That demonstrates that resuable components are at least possible, if not common.
-----------------------------------------------
It's great that RedHat is spending a money on Linux, and that everything they do is GPL'd. Rpm, in particular, has been a great boon to Linux. (Debian's package manager might be better, but rpm came first).
But, remember Brooks' (sp?) law -- Adding more programmers to a late project makes it later. Or, pouring more money into an ill-conceived project (Gnome, Windows) just makes it bigger, and bloatier. Through shear brute-force effort you may be able to patch most of the obvious bugs , but you won't have a stable, maintainable, extendable system without starting from scratch with a cleaner architecture.
Gnome is an ill-conveived system. It's architecture was thrown together in haste, and many of it's most praised features, like "window manager independence" were in fact just spin on the fact that they hadn't thought things through. "Language independence" means that they coded everything in the lowest common denominator, "C". They have not acheived true language independence through Corba, yet. Object-oriented programming works very well in gui programming. Although object-oriented programming is possible in languages that don't directly support it (witness Motif, Gtk), just as it's possible to program in a procedural style using assembly, it's a lot easier to do object-oriented programming in languages that support object-oriented programming. Again, if you want true language independence, use CORBA.
But, Gnome's failure wouldn't be a big deal if it were just one of among many desktop attempts. Darwinism, letting the best code win, is one of the open source model's strengths. You get some duplication of effort, sure, but that effort doesn't usually waste much money since it's programmers working on their own time. In Gnome's case, however, RedHat is unlikely just to drop it and use something else. They have too much money invested in it. So, RedHat will continue pushing Gnome in the media, and will still be the default desktop environment in their distribution. Even though it's inferior. This will hamper the development of end user applications for Linux, since Gnome is an awkward system to write for. Of course developers could just write for KDE, or wxWindows (which wraps Gtk nicely), or whatever, but they can't ignore default desktop environment on the dominant distribution if they want their apps to be widely used. Gnome is already slowing down end-user acceptance of Linux. If Joe User walks into Best-Buy to buy Linux, he'll probablly pick up RedHat. He'll probablly also use Gnome as his windowing environment, since that's what comes up by default. He'll probablly also get really frustrated when Gnome locks up, when he finds out he has two control panels to worry about (Enlightenment's and Gnomes), etc.
In spite of all this, I still think RedHat has done many great things for the community. I just think that we're sticking our heads in the sand if we deny the fact that there are some down sides to RedHat's dominence (in the U.S., at least).
-------------------------------------------
I installed the KDE that came with RedHat 6.0. Problems, weird directories, etc.
Removed them, downloaded the sources from kde.org, built and installed them. No problems.
So much for RedHat's install making things easier.
Brilliant idea!
Any talk of porting Delphi or C++ Builder? This would be a much be bigger challenge than JBuilder or Interbase. Interbase is mostly non-gui (and perhaps it had already been ported to other Unix platforms before Linux???). JBuilder would require no porting if it were written in pure Java to begin with, and if Java were truly platform independent.