Isn't the idea of Linux and Open Source to make a better software/OS world through contribution to the common code? Without source code, Inprise/Borland has given nothing. They could speed the Linux bandwagon they hope to make money from by making GCC work better and then bring us a C++ Builder for GCC/Linux! Make tons of money on the RAD functionality, but DO NOT break the ubiquity and portability of code that compiles under GCC.
That's a beautiful dream, but unfortunately, C++Builder relies on at least one extension to the C++ language. (Their __property keyword.) I doubt the GCC folk would accept patches to integrate that extension.
Another of the tenets of Open Source, though, is competition. Every native Unix compiler I've used has sucked in some serious ways. GCC sucks in a lot of ways, too, but for my purposes, I've found it easier to install GCC than use the native compiler.
My point? As soon as Borland releases their compiler on Linux, the GCC team will see a lot of pressure to improve their code generation engine. (GCC3, perhaps?)
I agree in principle, but I find that if I'm really familiar with the album, words don't distract me -- I treat them kind of like an instrument in their own right. I'm listening to Scorpions right now, and the main problem with it is that it kind of gets in the way of my typing rhythm -- I try to pace my keys to the drum beats. B-)
On the other hand, if the words are really strong, I'll often zone off and sit there listening instead of coding. Examples: "The Downeaster Alexa" or "Allentown" by Billy Joel. These are both songs about people losing the only jobs they're qualified for to the march of progress. I'm not a bleeding-heart sort (I consistently hang up on charities as a matter of principle), but I just can't help getting distracted by that.
As for the main question, it depends more on my mood what I listen to than on what I'm trying to do. I listen to such a wide variety of stuff. I've already mentioned Billy Joel and Scorpions. Other exemplars are Enya, Nancy Griffith, Eric Clapton, Pink Floyd, Bach, and even some top-10 stuff. (Yes, I already know I'm a Philistine.)
About the only time I pick particular bands for particular bits of work is when I know I'm going to be doing repetitive drudge work (refactoring a class, for example) I'll pick some fast, upbeat stuff to keep my interest up and keep me from getting distracted. I have an MP3-encoded CD-R for this. It has Scorpions, Bon Jovi, Pat Benatar, and Rush on it. If I get distracted or bored listening to that, I know it's time to go home and get some Zs.
One other thing I've found helpful: MP3-encoded CD-Rs are great because you don't have to stop working every hour or so to select a new CD. Just put one in when you come in, and you can listen until you leave.
Believe it or not, the "reference implementation" of UDI will be on Linux! That's right, Linux gets UDI for free, and everyone else has to write their own. Nyah, nyah, nyah, SCO!:->
The only time this will matter is when you've got to use a particular vendor's board for some reason. In that case, a closed driver is better than no driver at all. (And you know these very choices confront actual Linux users today, so don't dismiss it as unreasonable!)
If you have a choice of boards, why not find the one with the most stable driver and use it? If it comes to a run-off, pick the one with open source.
Which is the most used *NIX on Intel platforms? Right, it's Linux. So, if a hardware vendor faces the choice of writing a driver for an Intel *NIX platform, which one is it going to be? Right, Linux!
All right, then riddle me this: why is it that SCO's UnixWare and OpenServer operating systems support some hardware that Linux doesn't?
Yes, I realize that Linux has broader hardware support than SCO systems do, but there are also whole categories of hardware that aren't well-represented on the Linux platform. Two examples are telephony boards and RAID systems.
FreeBSD has a module that allows it to run Linux binary kernel modules like they were it's own. Isn't this the same function that UDI is trying to accomplish? The developer could test their driver on Linux and know it would work on BSD as well.
What you're suggesting is to simply make Linux's driver interface the Universal Driver Interface. But, Linux's driver interface has already proven to be unstable -- that is, it changes every so often. UDI is not a replacement for the Linux driver model, it's an augmentation to woo those hardware folk who still don't provide Linux drivers.
A great example is telephony boards: if it weren't for community groups like Open Telephony and the Linux Telephony project, there would be almost no support for telephony boards under Linux. And, most of these boards are supported via reverse-engineering, not by using vendor-published specs. That's a lot of community effort that would be better spent writing Linux telephony _applications_.
Windows in itself is not unstable. Third party drivers for Windows are what make it crash. Because of this, Linux will lose one of it's best assets; stability.
This issue will be handled through simple market pressure. If someone releases a buggy driver, it won't be tolerated in the Linux world like it is in the Windows world. The vendor will have two choices: 1) fix the driver, or 2) leave it alone and let its customers switch to a competitor's products.
Also, what happens when you want to run linux on non-x86 hardware? There goes linux portability.
Once again, UDI does not replace Linux's driver model, it augments it. So, maybe a Dialogic telephony board only works on x86 Linux and not Alpha Linux. Oh, well. At least we're better off today than we were yesterday. (FWIW, Dialogic is a good example because they've repeatedly refused to give away specs to their boards, even to people wanting to develop a binary-only driver. The only hope for Linux drivers at this point is something like UDI, because maybe they'll develop a driver internally for, say, UnixWare, that can also be used on Linux.)
Also, keep in mind that the companies behind UDI have their wagons hitched to other platforms than x86: UnixWare will move to IA-64, IBM is already on PowerPC, etc. What support does not exist for these today will eventually exist.
Going back to your earlier post:
Closed drivers are buggy and they always will be without the open source development model.
Have you watched the bug fix history of the Adaptec drivers in the Linux kernel? It seems like every other kernel update contains a fix to one or more of these drivers. That's some really buggy open source.
UDI does not add run-time loadable drivers to Linux: Linux already has them, since version 2.0.
It's just that distributions haven't supported them very well until recently. In Red Hat 6.0, for example, the conf.modules file is very large, with auto-load statements for all kinds of drivers. It's finally usable by the masses.
You can run Samba and use it to talk to your Windows boxes, and pull files that way.
Sorry, that won't work except for the simplest setups. (I.e. where you don't want complete backups, but rather just a selected subtree or two.)
The problem is in file locking. Many files (the registry and paging files are a prime example) are locked all the time. Typical backup programs like tar will just sit there patiently, forever waiting for the files to be unlocked when they come across them.
This is, of course, a result of Windows sucking, but bitching about it won't change the fact that sometimes you've just gotta back up a Windows box.
Elsewhere people have suggested Arkeia. I second this, as it not only handles true network backups, it does incrementals, keeps an off-tape log of files backed up so it's very easy to restore things, and it handles the registry on a Windows box appropriately.
It has other nice features, too: mutltiflows, so it's backing up more than one machine at once, for efficiency; separate GUI and backup processes, so you can start it and then shut down the GUI; a Java GUI that will run anywhere; and it's cheap.
A nice package, albeit a bit "foreign" when it comes to their terminology.
You don't know the half of it. Arkeia was written in France and then translated for the US market. I found one place in their PDF manuals where one of the tables is still in French. Elsewhere in the docs, there are awkward bits of phrasing and grammar errors.
Still, the package does work well, and it's cheap. For home use it's free, but you're limited to 2 clients. But for about $150, you can get a 5-client license which works nicely.
We use this package at work every day. It's not perfect, but it beats the hell out of installing a tape drive in every box.
A Redundant Array of Inexpensive Microcomputers is theoretically possible, designed just as you said. The problem is the interconnect.
Have you thought about how much raw data gets moved in a computer? Add together all the disk I/O, all the memory I/O, all the miscellaneous bus I/O, and all the intra-processor I/O. Then pass all that over an interconnect to the other four computers in the array. Gigabit Ethernet would choke horribly under such a load. Or rather, your app would become slower than you'd wish.
In other words, no one wants such a system, at least not to the extent that the I in the acronym holds any meaning. B-)
RAID works for hard drives because the disks already share a common bus: nothing is lost by going to RAID.
Regarding no file locking: You can in fact do locking with CVS, but it's just not the default. When I started using CVS (on a small 2-person Linux project) I initially used locking, but it proved so annoying that we've turned it back off, and haven't had a problem with bad merges. Consider also that largish teams like GNOME and EGCS use CVS all the time. If it sucked for team development, don't you think they would be using something else?
Regarding CVS vs. RCS: forget RCS. CVS is essentially a superset of RCS, so there's nothing you'll gain by choosing RCS over CVS, and plenty you'll lose.
Since I began using CVS on that project I mentioned above, I've since begun using it for my Windows code -- it works great, and it's not at all demanding. Basically, when I finish a significant update to one of my programs or libraries, I just type "cvs commit" at the command line and write up a short description of my changes. For that minimal investment, I get automatic source duplication (i.e. disaster protection), a running change log (both in terms of code and functional description), and the ability to roll back changes.
Anyone who programs without something like CVS needs to be quickly and firmly reeducated. Similarly, anyone who pays big bucks for such a tool without first looking at CVS is doing themselves a big disservice.
There's a newish network analyzer out for Linux called Ethereal that's basically tcpdump with a "face". It can read tcpdump log files, so you can capture on a machine you don't have X on and then move the capture file to the Ethereal box to view it. (Try that with NetXRay!)
One day, it might even support reading NetXRay and other network analyzer files. It's kind of rough right now, but it does work. About the only serious thing it's missing to compare with NetXRay are all the nice aggregate traffic analysis reports, and the network usage meters. Right now, it's just a protocol decoder.
that is so much bullshit, but it's 2.1. in any case no unix svr4 i came across lacked man pages. perhaps you forgot to install them...
i just installed the for-free distribution of uw 7.0. more manual pages that you can shake a stick at. it took 15 minutes for the html files to install... ie untarring.
HTML files are not man pages. Man pages are what you get when you type man ls and suchlike. And, yes, the original poster is right: they're not installed by default. Even worse, when you do install them, they're preformatted man pages, because nroff and troff are extra-cost add-ons! That's okay until you try to install a third-party package that has nroff-style man pages and you can't read them.
Then try adding GNU groff to cover that lack. First you have to install GNU C++ and GNU make to compile it because SCO CC and SCO make are so weak. Have you ever tried to compile gcc on UnixWare? It is not pretty.
unixware is known to scale (svr unix has been ported onto S370 class systems by both ibm and amdahl)
This is the standard comeback from UnixWare users, and it gets a little tiring. Anyone with sense can see that Linux can scale at least as far as UnixWare, but just because no one has tried it, the UW people laugh derisively and say it can't be done. The truth is, porting PC Unix-like systems to mainframes is just a PR stunt, not a practical solution to a real problem. If you have a mainframe-class problem, you use a mainframe OS, it's that simple.
I use UnixWare and Linux every day, and I can tell you that it's not about price, it's about power, support and convenience. Linux has it, and UnixWare doesn't. It's that simple.
The focus on geometry management
on
Learning Perl/Tk
·
· Score: 1
Geometry management is an extremely powerful and useful concept. I don't know Perl/Tk, but I do know Tcl/Tk, and I can tell you that without geometry management, Tk would be just another "me too!" GUI toolkit. Geometry management lets you construct user interfaces quickly without worrying about the details of where exactly all the widgets get placed on the screen.
Slashdot Mirror
That's a beautiful dream, but unfortunately, C++Builder relies on at least one extension to the C++ language. (Their __property keyword.) I doubt the GCC folk would accept patches to integrate that extension.
Another of the tenets of Open Source, though, is competition. Every native Unix compiler I've used has sucked in some serious ways. GCC sucks in a lot of ways, too, but for my purposes, I've found it easier to install GCC than use the native compiler.
My point? As soon as Borland releases their compiler on Linux, the GCC team will see a lot of pressure to improve their code generation engine. (GCC3, perhaps?)
A rising tide lifts all boats...
--
On the other hand, if the words are really strong, I'll often zone off and sit there listening instead of coding. Examples: "The Downeaster Alexa" or "Allentown" by Billy Joel. These are both songs about people losing the only jobs they're qualified for to the march of progress. I'm not a bleeding-heart sort (I consistently hang up on charities as a matter of principle), but I just can't help getting distracted by that.
As for the main question, it depends more on my mood what I listen to than on what I'm trying to do. I listen to such a wide variety of stuff. I've already mentioned Billy Joel and Scorpions. Other exemplars are Enya, Nancy Griffith, Eric Clapton, Pink Floyd, Bach, and even some top-10 stuff. (Yes, I already know I'm a Philistine.)
About the only time I pick particular bands for particular bits of work is when I know I'm going to be doing repetitive drudge work (refactoring a class, for example) I'll pick some fast, upbeat stuff to keep my interest up and keep me from getting distracted. I have an MP3-encoded CD-R for this. It has Scorpions, Bon Jovi, Pat Benatar, and Rush on it. If I get distracted or bored listening to that, I know it's time to go home and get some Zs.
One other thing I've found helpful: MP3-encoded CD-Rs are great because you don't have to stop working every hour or so to select a new CD. Just put one in when you come in, and you can listen until you leave.
Believe it or not, the "reference implementation" of UDI will be on Linux! That's right, Linux gets UDI for free, and everyone else has to write their own. Nyah, nyah, nyah, SCO! :->
The only time this will matter is when you've got to use a particular vendor's board for some reason. In that case, a closed driver is better than no driver at all. (And you know these very choices confront actual Linux users today, so don't dismiss it as unreasonable!)
If you have a choice of boards, why not find the one with the most stable driver and use it? If it comes to a run-off, pick the one with open source.
This is not hard....
All right, then riddle me this: why is it that SCO's UnixWare and OpenServer operating systems support some hardware that Linux doesn't?
Yes, I realize that Linux has broader hardware support than SCO systems do, but there are also whole categories of hardware that aren't well-represented on the Linux platform. Two examples are telephony boards and RAID systems.
What you're suggesting is to simply make Linux's driver interface the Universal Driver Interface. But, Linux's driver interface has already proven to be unstable -- that is, it changes every so often. UDI is not a replacement for the Linux driver model, it's an augmentation to woo those hardware folk who still don't provide Linux drivers.
A great example is telephony boards: if it weren't for community groups like Open Telephony and the Linux Telephony project, there would be almost no support for telephony boards under Linux. And, most of these boards are supported via reverse-engineering, not by using vendor-published specs. That's a lot of community effort that would be better spent writing Linux telephony _applications_.
Windows in itself is not unstable. Third party drivers for Windows are what make it crash. Because of this, Linux will lose one of it's best assets; stability.
This issue will be handled through simple market pressure. If someone releases a buggy driver, it won't be tolerated in the Linux world like it is in the Windows world. The vendor will have two choices: 1) fix the driver, or 2) leave it alone and let its customers switch to a competitor's products.
Also, what happens when you want to run linux on non-x86 hardware? There goes linux portability.
Once again, UDI does not replace Linux's driver model, it augments it. So, maybe a Dialogic telephony board only works on x86 Linux and not Alpha Linux. Oh, well. At least we're better off today than we were yesterday. (FWIW, Dialogic is a good example because they've repeatedly refused to give away specs to their boards, even to people wanting to develop a binary-only driver. The only hope for Linux drivers at this point is something like UDI, because maybe they'll develop a driver internally for, say, UnixWare, that can also be used on Linux.)
Also, keep in mind that the companies behind UDI have their wagons hitched to other platforms than x86: UnixWare will move to IA-64, IBM is already on PowerPC, etc. What support does not exist for these today will eventually exist.
Going back to your earlier post:
Closed drivers are buggy and they always will be without the open source development model.
Have you watched the bug fix history of the Adaptec drivers in the Linux kernel? It seems like every other kernel update contains a fix to one or more of these drivers. That's some really buggy open source.
UDI does not add run-time loadable drivers to Linux: Linux already has them, since version 2.0.
It's just that distributions haven't supported them very well until recently. In Red Hat 6.0, for example, the conf.modules file is very large, with auto-load statements for all kinds of drivers. It's finally usable by the masses.
If you take the route of Samba, how can you backup the so-crucial registry files of Windows?
You don't. This is one of many reasons why specialized network backup programs exist: they know to handle the registry and pagefiles a special cases.
You can run Samba and use it to talk to your Windows boxes, and pull files that way.
Sorry, that won't work except for the simplest setups. (I.e. where you don't want complete backups, but rather just a selected subtree or two.)
The problem is in file locking. Many files (the registry and paging files are a prime example) are locked all the time. Typical backup programs like tar will just sit there patiently, forever waiting for the files to be unlocked when they come across them.
This is, of course, a result of Windows sucking, but bitching about it won't change the fact that sometimes you've just gotta back up a Windows box.
Elsewhere people have suggested Arkeia. I second this, as it not only handles true network backups, it does incrementals, keeps an off-tape log of files backed up so it's very easy to restore things, and it handles the registry on a Windows box appropriately.
It has other nice features, too: mutltiflows, so it's backing up more than one machine at once, for efficiency; separate GUI and backup processes, so you can start it and then shut down the GUI; a Java GUI that will run anywhere; and it's cheap.
A nice package, albeit a bit "foreign" when it comes to their terminology.
You don't know the half of it. Arkeia was written in France and then translated for the US market. I found one place in their PDF manuals where one of the tables is still in French. Elsewhere in the docs, there are awkward bits of phrasing and grammar errors.
Still, the package does work well, and it's cheap. For home use it's free, but you're limited to 2 clients. But for about $150, you can get a 5-client license which works nicely.
We use this package at work every day. It's not perfect, but it beats the hell out of installing a tape drive in every box.
A Redundant Array of Inexpensive Microcomputers is theoretically possible, designed just as you said. The problem is the interconnect.
Have you thought about how much raw data gets moved in a computer? Add together all the disk I/O, all the memory I/O, all the miscellaneous bus I/O, and all the intra-processor I/O. Then pass all that over an interconnect to the other four computers in the array. Gigabit Ethernet would choke horribly under such a load. Or rather, your app would become slower than you'd wish.
In other words, no one wants such a system, at least not to the extent that the I in the acronym holds any meaning. B-)
RAID works for hard drives because the disks already share a common bus: nothing is lost by going to RAID.
(The regular Apple II's used snap on covers, so kids in classrooms could open them up, which was not good, generally)
Not good? Hell, it was invaluable! It made it practical to quickly open the case and pull the speaker wire so you could play games during BASIC class!
Regarding no file locking: You can in fact do locking with CVS, but it's just not the default. When I started using CVS (on a small 2-person Linux project) I initially used locking, but it proved so annoying that we've turned it back off, and haven't had a problem with bad merges. Consider also that largish teams like GNOME and EGCS use CVS all the time. If it sucked for team development, don't you think they would be using something else?
Regarding CVS vs. RCS: forget RCS. CVS is essentially a superset of RCS, so there's nothing you'll gain by choosing RCS over CVS, and plenty you'll lose.
Since I began using CVS on that project I mentioned above, I've since begun using it for my Windows code -- it works great, and it's not at all demanding. Basically, when I finish a significant update to one of my programs or libraries, I just type "cvs commit" at the command line and write up a short description of my changes. For that minimal investment, I get automatic source duplication (i.e. disaster protection), a running change log (both in terms of code and functional description), and the ability to roll back changes.
Anyone who programs without something like CVS needs to be quickly and firmly reeducated. Similarly, anyone who pays big bucks for such a tool without first looking at CVS is doing themselves a big disservice.
One day, it might even support reading NetXRay and other network analyzer files. It's kind of rough right now, but it does work. About the only serious thing it's missing to compare with NetXRay are all the nice aggregate traffic analysis reports, and the network usage meters. Right now, it's just a protocol decoder.
HTML files are not man pages. Man pages are what you get when you type man ls and suchlike. And, yes, the original poster is right: they're not installed by default. Even worse, when you do install them, they're preformatted man pages, because nroff and troff are extra-cost add-ons! That's okay until you try to install a third-party package that has nroff-style man pages and you can't read them.
Then try adding GNU groff to cover that lack. First you have to install GNU C++ and GNU make to compile it because SCO CC and SCO make are so weak. Have you ever tried to compile gcc on UnixWare? It is not pretty.
This is the standard comeback from UnixWare users, and it gets a little tiring. Anyone with sense can see that Linux can scale at least as far as UnixWare, but just because no one has tried it, the UW people laugh derisively and say it can't be done. The truth is, porting PC Unix-like systems to mainframes is just a PR stunt, not a practical solution to a real problem. If you have a mainframe-class problem, you use a mainframe OS, it's that simple.
I use UnixWare and Linux every day, and I can tell you that it's not about price, it's about power, support and convenience. Linux has it, and UnixWare doesn't. It's that simple.
Geometry management is an extremely powerful and useful concept. I don't know Perl/Tk, but I do know Tcl/Tk, and I can tell you that without geometry management, Tk would be just another "me too!" GUI toolkit. Geometry management lets you construct user interfaces quickly without worrying about the details of where exactly all the widgets get placed on the screen.