the real problem is that c *can't* make some good decisions, with or without your help (the aliasing problem).
C will never be as quick on some numerical problems, because the language hobbles the compiler in certain respects.
C++ might (see blitz++, etc.) but only by taking those decisions away from the complier and making them explicit (via templates, or whatever).
There are lot's of reasons one might want to ditch FORTRAN (from a comp sci. point of view) but there aren't any really good contenders there yet. That doesn't even bring up the F95 sucks/sucks not debate:)
You seem to be extrapolating from a problem domain you understand to one that you don't...always a mistake.
Think about that statement: "I've never seen or done anything with more than 50 lines of code...". Especially the 'done' part. I can translate that as 'I don't really know anything about this language'.
Many extremely large projects have been done in lisp. In fact it is particularly well suited for large research projects, because it is so flexible. Need examples? Most early large scale AI projects were done in lisp. Many still are, but also many use variants. AutoCAD. Symbolic algebra systems. Many 'expert systems' (I never did consider them 'AI', but I guess you could lump that in with above). Lot's more if you care to look....
Sounds like programmer A is a complete idiot. Why would you release a program under a license you don't understand and/or for purposes contrary to the stated goals of the license???
GPL is not there for you to do a 'hey guys why don't you help me debug this program so I can close the development and sell it to you later when it works.'
you said:"Some enterprising programmer *might* pick up that code and reuse it or fix it. But it is unlikely that the code will reach anywhere near what it could have beeN, had programmer A not dropped the project. "
could you get any more speculative?
Why are you ranting about something you don't seem to understand? There are many reasonable (unfortunately, many other completely unreasonable) essays and discussions about free software, copyleft, what it does and does not do... why don't you read a few before going off about something (your above scenario) that is actually irrelevant to free software. What you are talking about is someone who wants all the advantages of free software with none of the resposibilities. Can't have it both ways (althought Sun, etc. will try).
Actually, 'dude', you are about as clueless as the first poster.
Ok, that is a bit harsh. You are more confused, than clueless, it seems. He was talking about making money *off his own work*. You are talking about making money *off someone else's* work.
Not the same thing. You can *always* control what happens to your own source. What the licences do is affect what you can do with other peoples work. Let me repeat that, as it is important. The GPL, BSD, etc., are not about restricting what you can do with *your* work. You own it, you can do what you want with it including 'make money off it' or 'give it away' or whatever. I can even write a program, GPL it and *also* sell it to a company with an explicit exclusion from the GPL terms. Of course when you release source code under any license you are expicitly giving up some control. I can't open source some code and then 3 months later say 'ooopppps, I didn't mean that. You all have to destroy your copies'. But you get the point, I hope.
If he doesn't release his own work, it isn't under BSD or GPL. The only question in this case is, did he use anyone elses code in the process --- in that case we are talking about whether or not he can make money off someone elses work (without their express permission). If the other code he used is BSD'd, he can, if GPL'd he is illegally re-distributing.
This was the misinformation in the orignal post that I was pointing out.
>I must agree with you. >I much prefer the BSD-style-licenses in that I >can someday make profit off of something that I >spend countless hours working on.
Either you are spreading FUD, or you don't understand what you are talking about. In the first case, please stop being lame. In the second --- read a little, if you really are concerned about how licences affect *you*, you should have at least a little understanding of them.
I don't want to get drawn into a license-advocacy discussion, but completely incorrect statements like your just confuse neophytes who may be reading this. In case it is not obvious, I will be more explicit. The BSD license doesn't give *you* any additional ability to make profit off something *you* did. What it does do is let *me* make a profit of your 'countless hours' --- without even mentioning it to you. This is why many corporate types favour teh BSD style, as it allows a company to benifit from the pool of code without returning anything. For exactly the same reason, this is why many GPL advocates are anti-BSD.
Ok, like most generalisations, my above statement is too strong. Thought I would jump on it before someone else does;)
The WTO is not *inherently* a tool of multinationals --- it is just shaping up that way. A concerted effort could turn that around, I suppose, and in that way it could become an aid to developing countries. Not holding my breath on that one.
The WTO isn't, never was, and never will be a benifit to develping countries. In fact, it isn't about benifit to any countries. The WTO is all about empowering corporations --- the largest benifit is to large multinationals.
Any statements (and we will probably here a lot of them next week) to the contrary are smoke & mirrors...
I guess my wording was a little incomplete. I was referring to the section:
2. BSD --> FreeBSD, NetBSD, OpenBSD, BSD OS, MachTen, NeXTStep (which has recently mutated into Apple Macintosh OS X Server), and SunOS (now called Solaris) ...AT&T did notice, panicked, and sued. That, too, is a long story best omitted. Under the stress of the lawsuit, freeware BSD split into three..
But I should have been more specific. What I meant was it would have been interesting if he had expanded a bit on what he thought the difference a GPL type license would have been, or the difference between the effect of this proprietary+free branches fork and a pure OS fork.
I wasn't trying to suggest a GPL good BSD bad slant. This probaly answers the other poster as well...
I assumed from (your?) 'reliable and stable' comment that 2.7 was meant.
2.8.1 wasn't reliable *or* stable, for me, on Suns, Alphas or i386s... I don't know what the earlier post was referring to. 2.95.1 has been quite good for me --- but I have been using more i386 boxes lately than when I was playing with 2.8.x so that may skew the results a bit.
Note that I am not (primarily) a linux user either --- that being said I can sympathise with the pgcc/egcs crowds frustration with the fairly pathetic i386 support in 2.8.x....
I think you are being too harsh. gcc->egcs->gcc was *sub-optimal*, I don't think anyone will disagree with you there. However, you can make a pretty good argument that it was necessary.
gcc2.7.x was stalble, reliable, buggy, and slow. Just because you know a workaround to a compiler bug doesn't mean it shouldn't be fixed:) gcc's optimisation was starting to look a bit aged as well.
and g++2.7.x was pretty much useless, as it wasn't keeping up with c++.
you can still use 2.7.x if you need to right now, and there is every reason to expect that when the dust settles we will have a gcc that is more stable, more reliable, faster, and less buggy. And this is a bad thing?
I have ported and built a non-trivial (>500k lines) numerically intesive app with gcc-2.95.1, with no significant problems (proved out by extensive regression testing). Any claim that this compiler is not useful is silly. You can run into problems with some code and techniques (some of which you shouldn't have been doing anyways;) but that doesn't mean we are stepping backwards here.
besides, having g77 is *lot's* nicer than f2c, if you need to play with f77 code
I wouldn't call Alans version a 'fork'... except in the trivial sense that every multi-developer project has a bunch of forks on different peoples drives. Probably ditto for the small patches --- I think the existence of these is a feature of the development model, certainly not a fork in the sense of emacs->xemacs or BSD->SunOS.
The capability to fork in the above sense is both neccesary and mostly undesireable --- but not something to freak out about the possibility of. I wonder how much of the current mindshare GPL forks have is due to FUD from various commercial interests?
Seriously, I have always considered forking of an OS project to be a last resort. If you have the 'bright ideas' and the source code you can become a *contributer*. I think you will find that this is (and always was) a pretty common outlook on the subject. The ability to fork is great. The neccessity of forking is unfortuneate.
The point behind (successful) forking was always that if a group of people irreconcileably dissagree about what constitutes a 'bright idea'... they can split up and each go after what they see as best. If you and your bright ideas are operating in a vacuum, it isn't much of a fork. Another possibility is that a project has fallen into disrepair, or hasn't been updated as rapidly as people want --- but the people involved refuse to do anything about it or let you help. Then OS means you can pick up where they left off.
Both these situations are pretty extreme though. In general, everyone will win if you can figure out a way to patch up your differences and all push in the same direction, no?
This article is quite well done. The scope is not that large, so he doesn't get bogged down in all the usual license bickering. He does make a reasonably good case for why the GPL dissuades certain types of forks, and why OS in general dissuades forking over all. I find the comments on the BSDish license promoting (a) fork interesting but underdeveloped.
The idea that a lot of non OS people are having difficulty getting is that for a fork of an OS project to be effective, there must be some sort of 'collective' agreement that is a good idea by (a significant part of) the community using that project. In many cases this is simply not going to happen. But it does allow the fork to occur when sufficient people believe it is neccessary (ie gcc->egcs->gcc).
I think the examples he gives are useful for neophytes and others who wonder what a fork is all about. I'm glad he resisted the urge to go into the muddled history of some of them in great depth --- that can be found elsewhere on the net/usenet if you really need to read about how obnoxious some people behave in the name of protecting there favorite project...
I recently hooked up with Bell 'HSE' service in SW ontario. This has pppoe.... and it has been interesting to follow the discussions on sympatico's (closed) newsgroups. A *lot* of wintel users are very unhappy with the switch (including a ~1000 member petition to bell/symp/whatever to complain about pppoe)
I hear there is a *BSD solution now, but when I go t going there wasn't so I have only played with linux --- don't have time to try and roll my own at the moment. The company Bell contracted to provide their pppoe client for wintel also built a linux client (presumeably there were enough linux DHCP clients already that bell didn't want to lose) but the implementation was incompetant, to be charitable (have a look at the source... ).
Fortunately, the linux community reacted as you might hope and by the time I was connecting there were three other solutions; one solid (if expensive cpuwise) user space client and two using kernel modules for efficiency. I am not claiming that these are perfect (some people are having difficulty getting up and going, it seems) but the upshot is that I have a solid 850/120 (on a nominal 968/128) connection to my linux box that has uptimes on the order of a week (and of course my recovery is automated if they drop the connection so even my dynamic dns (yuck, but what do you do) only takes about 5 min to update). CPU usage is less than 4% at full b-width. This may not sound great --- but consider that HSE is in the middle of transit between DHCP and pppoe; they are having server outages all over the place and many people on wintel are complaining about uptimes on the order of an hour, and 200K/s transfers....
If you have a look at the newsgroups you will see that many wintel users are having to resort to and additional commercial ($90) package just to get back to 'acceptable' service after losing DHCP. Of course this is not making bell/sympatico look particularly good.
So for me at least, CDN $35/mo is looking just fine compared to that $20/mo dailup....
I could be off here, but it seems to me that a lot of people are having a knee-jerk reaction to RH's aquisition plans etc. What did you expect, really? They have to do something with the (absurd) market cap they have or they will loose it, *fast*. There are a lot of holes in the RH business plan at the moment, so of course they will try and plug them. Whether or not a particular purchase is good idea for redhat or for 'the community' (whatever that is) is not such an easy question to answer.
I think it is *way* too early to start lumping them in with MS. Look, big (market wise) companies buy small ones because it is cheaper than developing in-house (or at least some PHB thinks it is). Why should we expect RH be different in that? The question is, what are they going to do with this new leverage they currently command in the commercial linux world? And what can we do to help keep them on track? Just because a company has money doesn't actually make them evil (statistical evidence aside:) ). Unfortunately there are going to be more and more pressures on RH from outside ( 'the community') to do things in conventially brain-damaged ways. That doesn't mean they will follow that pattern. I think this possibility is what people are reacting to, rather than any action RH has really taken.
One interesting point is the fact that while RH and Cygnus are (were?) both commercial players in the open-source game, they had different outlooks. RH may have bundled commercial software, but it has always claimed that in-house software will be returned to 'the community'. Cygnus on the other hand had a commercial version/free version approach. The question is, will RH free up the Cygnus tools, or bundle them as a commercial add-on?
A more important issue is the long term scope of RHlabs. Indirectly, RH has aquired the current gcc maintenance codebase and people, no? This is not inherently a bad thing. However, it does raise a few interesting points: like how much concentration of OS projects is a good thing? If at some later date RH starts playing silly buggers with some of 'our' cherised projects, is the OS community going to be faced with the possibility of a series of ugly forks?
On a related note, RH is putting a lot of effort into PR on one side, and eye-candy (see new installer) on the other....fine, but they have some more serious problems to look at. I have recently played around with 5.1, 5.2, 6.0, 6.1 on both i386 and alpha. For the most part things have been smooth to get up and going (excepting 5.x on alpha). The problem is, once the system is up. I have never had as much trouble with a linux box as I have with the 6.x machines. Okay, that is not quite true... the 0.11x betas would fall down hourly when you played with them (but it was fun:) --- and things didn't get really solid until 2.0.x kernels (for me at least). But for example, the 6.x versions ship with a buggy gnome, and then try really hard to get you to use it. My 6.0 machines would dump a core in ~ every time you log in! Sometime gnome would hang for a minute or two with *no feedback* as to what was happening (unless you count the X error messages) 6.1 I thought would be better but it has all the signs of being a rush job to get the new installer out the door. Gnome was still problematic, there are config hiccups with less often use packages, and the 'upgrade' changes parts of *my* config without warning or backups. Annoying. I don't want to pick on Gnome, there are plenty of other examples but this message is way too long already...
The point I am getting at (slowly, sorry) is that this is a bad sign. My debian machines, slack machines, and the machines that were hand-built (no distro) had never given me this much trouble. The problem is that in NA at least RH is becoming synonymous with Linux in the minds of the great unwashed. So either we don't care what anyone else thinks (a valid, if limited scope, view) or we care what people think about RH. In the later case we really need to push them on the underlying technical issues a bit. It is a bit discouraging, for example, to see the possibility of a BETA-VHS type thing being precipitated by RH. Look at.rpm vs say ,.deb. The.deb is a better design, and fits in to existing tools more easily. Why didn't RH, realising this, bail on.rpm and make a set of good tools to sit on top of the.deb format? Ok, I know this has been talked to death, but I recall it to bring to mind the problems we could face in a couple of years if redhat has both a) de-facto control of a number of significant projects and b) a not-invented-here syndrome...
I don't know how much you are looking to spend, but the KVM switches made by Black Box (www.blackbox.com IIRC) worked pretty well for me at a previous job. We had a big ($1500) 12:1 box and a smaller one... never had a problem with either of them.
I'm not out to bash Java here just picking a nit; I am a bit tired of hearing the 'The beautiful thing... everyone seems to be missing...' type comments from various Java advocates. I don't know how many times I've heard/read 'and it works on *any* machine, **wow** what a breakthrough' statements. This is *not* a new idea. Java didn't invent it. For that matter, Sun didn't invent it. It is just cheesy hype from Sun on the same order as the common 'we invented the dll' type statements from MS.
Come on guys, Java (like just about any other language) has some good points and some bad points. It isn't really a general purpose language in the sense that C/C++ is so the trade offs are different. If you're on the right side of those trade-offs it can make you life a lot easier (wrt C/whatever); on the wrong side it can make your life miserable.
Please lets not have yet another discussion degenerate into a stupid language war full of pointless statements by people who either don't know what they are talking about or should know better than to get into it once the temperature is up, ok?
Slashdot Mirror
Unfortunately, we only got 2 of them right...but we are stuck with all four ;)
S.
the real problem is that c *can't* make some good decisions, with or without your help (the aliasing problem).
:)
C will never be as quick on some numerical problems, because the language hobbles the compiler in certain respects.
C++ might (see blitz++, etc.) but only by taking those decisions away from the complier and making them explicit (via templates, or whatever).
There are lot's of reasons one might want to ditch FORTRAN (from a comp sci. point of view) but there aren't any really good contenders there yet. That doesn't even bring up the F95 sucks/sucks not debate
You seem to be extrapolating from a problem domain you understand to one that you don't...always a mistake.
S.
Think about that statement: "I've never seen or done anything with more than 50 lines of code...". Especially the 'done' part. I can translate that as 'I don't really know anything about this language'.
Many extremely large projects have been done in lisp. In fact it is particularly well suited for large research projects, because it is so flexible. Need examples? Most early large scale AI projects were done in lisp. Many still are, but also many use variants. AutoCAD. Symbolic algebra systems. Many 'expert systems' (I never did consider them 'AI', but I guess you could lump that in with above). Lot's more if you care to look....
S.
Sounds like programmer A is a complete idiot. Why would you release a program under a license you don't understand and/or for purposes contrary to the stated goals of the license???
GPL is not there for you to do a 'hey guys why don't you help me debug this program so I can close the development and sell it to you later when it works.'
you said:"Some enterprising programmer *might* pick up that code and reuse it or fix it. But it is unlikely that the code will reach anywhere near what it could have beeN, had programmer A not dropped the project. "
could you get any more speculative?
Why are you ranting about something you don't seem to understand? There are many reasonable (unfortunately, many other completely unreasonable) essays and discussions about free software, copyleft, what it does and does not do... why don't you read a few before going off about something (your above scenario) that is actually irrelevant to free software. What you are talking about is someone who wants all the advantages of free software with none of the resposibilities. Can't have it both ways (althought Sun, etc. will try).
S.
Actually, 'dude', you are about as clueless as the first poster.
Ok, that is a bit harsh. You are more confused, than clueless, it seems. He was talking about making money *off his own work*. You are talking about making money *off someone else's* work.
Not the same thing. You can *always* control what happens to your own source. What the licences do is affect what you can do with other peoples work. Let me repeat that, as it is important. The GPL, BSD, etc., are not about restricting what you can do with *your* work. You own it, you can do what you want with it including 'make money off it' or 'give it away' or whatever. I can even write a program, GPL it and *also* sell it to a company with an explicit exclusion from the GPL terms. Of course when you release source code under any license you are expicitly giving up some control. I can't open source some code and then 3 months later say 'ooopppps, I didn't mean that. You all have to destroy your copies'. But you get the point, I hope.
If he doesn't release his own work, it isn't under BSD or GPL. The only question in this case is, did he use anyone elses code in the process --- in that case we are talking about whether or not he can make money off someone elses work (without their express permission). If the other code he used is BSD'd, he can, if GPL'd he is illegally re-distributing.
This was the misinformation in the orignal post that I was pointing out.
S.
>I must agree with you.
>I much prefer the BSD-style-licenses in that I >can someday make profit off of something that I >spend countless hours working on.
Either you are spreading FUD, or you don't understand what you are talking about. In the first case, please stop being lame. In the second --- read a little, if you really are concerned about how licences affect *you*, you should have at least a little understanding of them.
I don't want to get drawn into a license-advocacy discussion, but completely incorrect statements like your just confuse neophytes who may be reading this. In case it is not obvious, I will be more explicit. The BSD license doesn't give *you* any additional ability to make profit off something *you* did. What it does do is let *me* make a profit of your 'countless hours' --- without even mentioning it to you. This is why many corporate types favour teh BSD style, as it allows a company to benifit from the pool of code without returning anything. For exactly the same reason, this is why many GPL advocates are anti-BSD.
S.
Ok, like most generalisations, my above statement is too strong. Thought I would jump on it before someone else does ;)
The WTO is not *inherently* a tool of multinationals --- it is just shaping up that way. A concerted effort could turn that around, I suppose, and in that way it could become an aid to developing countries. Not holding my breath on that one.
S.
The WTO isn't, never was, and never will be a benifit to develping countries. In fact, it isn't about benifit to any countries. The WTO is all about empowering corporations --- the largest benifit is to large multinationals.
Any statements (and we will probably here a lot of them next week) to the contrary are smoke & mirrors...
S.
I guess my wording was a little incomplete. I was referring to the section:
2. BSD --> FreeBSD, NetBSD, OpenBSD, BSD OS, MachTen, NeXTStep (which has recently mutated into Apple Macintosh OS X Server), and SunOS (now called Solaris)
But I should have been more specific. What I meant was it would have been interesting if he had expanded a bit on what he thought the difference a GPL type license would have been, or the difference between the effect of this proprietary+free branches fork and a pure OS fork.
I wasn't trying to suggest a GPL good BSD bad slant.
This probaly answers the other poster as well...
I assumed from (your?) 'reliable and stable'
....
comment that 2.7 was meant.
2.8.1 wasn't reliable *or* stable, for me, on Suns, Alphas or i386s... I don't know what the earlier post was referring to. 2.95.1
has been quite good for me --- but I have been
using more i386 boxes lately than when I was
playing with 2.8.x so that may skew the results a bit.
Note that I am not (primarily) a linux user
either --- that being said I can sympathise with
the pgcc/egcs crowds frustration with the fairly pathetic i386 support in 2.8.x
S.
I think you are being too harsh. gcc->egcs->gcc was *sub-optimal*, I don't think anyone will disagree with you there. However, you can make a pretty good argument that it was necessary.
:) gcc's optimisation was starting to look a bit aged as well.
;) but that doesn't mean we are stepping backwards here.
gcc2.7.x was stalble, reliable, buggy, and slow. Just because you know a workaround to a compiler bug doesn't mean it shouldn't be fixed
and g++2.7.x was pretty much useless, as it wasn't keeping up with c++.
you can still use 2.7.x if you need to right now, and there is every reason to expect that when the dust settles we will have a gcc that is more stable, more reliable, faster, and less buggy. And this is a bad thing?
I have ported and built a non-trivial (>500k lines) numerically intesive app with gcc-2.95.1, with no significant problems (proved out by extensive regression testing). Any claim that this compiler is not useful is silly. You can run into problems with some code and techniques (some of which you shouldn't have been doing anyways
besides, having g77 is *lot's* nicer than f2c, if you need to play with f77 code
S.
I wouldn't call Alans version a 'fork'... except in the trivial sense that every multi-developer project has a bunch of forks on different peoples drives. Probably ditto for the small patches --- I think the existence of these is a feature of the development model, certainly not a fork in the sense of emacs->xemacs or BSD->SunOS.
The capability to fork in the above sense is both neccesary and mostly undesireable --- but not something to freak out about the possibility of. I wonder how much of the current mindshare GPL forks have is due to FUD from various commercial interests?
S.
I think it is just you ;)
... they can split up and each go after what they see as best. If you and your bright ideas are operating in a vacuum, it isn't much of a fork. Another possibility is that a project has fallen into disrepair, or hasn't been updated as rapidly as people want --- but the people involved refuse to do anything about it or let you help. Then OS means you can pick up where they left off.
Seriously, I have always considered forking of an OS project to be a last resort. If you have the 'bright ideas' and the source code you can become a *contributer*. I think you will find that this is (and always was) a pretty common outlook on the subject. The ability to fork is great. The neccessity of forking is unfortuneate.
The point behind (successful) forking was always that if a group of people irreconcileably dissagree about what constitutes a 'bright idea'
Both these situations are pretty extreme though. In general, everyone will win if you can figure out a way to patch up your differences and all push in the same direction, no?
S.
This article is quite well done. The scope is not that large, so he doesn't get bogged down in all the usual license bickering. He does make a reasonably good case for why the GPL dissuades certain types of forks, and why OS in general dissuades forking over all. I find the comments on the BSDish license promoting (a) fork interesting but underdeveloped.
The idea that a lot of non OS people are having difficulty getting is that for a fork of an OS project to be effective, there must be some sort of 'collective' agreement that is a good idea by (a significant part of) the community using that project. In many cases this is simply not going to happen. But it does allow the fork to occur when sufficient people believe it is neccessary (ie gcc->egcs->gcc).
I think the examples he gives are useful for neophytes and others who wonder what a fork is all about. I'm glad he resisted the urge to go into the muddled history of some of them in great depth --- that can be found elsewhere on the net/usenet if you really need to read about how obnoxious some people behave in the name of protecting there favorite project...
S.
It looks like any OSI approved license is welcome, so that gives you some room to move.
S.
I recently hooked up with Bell 'HSE' service in SW ontario. This has pppoe.... and it has been interesting to follow the discussions on sympatico's (closed) newsgroups. A *lot* of wintel users are very unhappy with the switch (including a ~1000 member petition to bell/symp/whatever to complain about pppoe)
I hear there is a *BSD solution now, but when I go t going there wasn't so I have only played with linux --- don't have time to try and roll my own at the moment. The company Bell contracted to provide their pppoe client for wintel also built a linux client (presumeably there were enough linux DHCP clients already that bell didn't want to lose) but the implementation was incompetant, to be charitable (have a look at the source... ).
Fortunately, the linux community reacted as you might hope and by the time I was connecting there were three other solutions; one solid (if expensive cpuwise) user space client and two using kernel modules for efficiency. I am not claiming that these are perfect (some people are having difficulty getting up and going, it seems) but the upshot is that I have a solid 850/120 (on a nominal 968/128) connection to my linux box that has uptimes on the order of a week (and of course my recovery is automated if they drop the connection so even my dynamic dns (yuck, but what do you do) only takes about 5 min to update). CPU usage is less than 4% at full b-width. This may not sound great --- but consider that HSE is in the middle of transit between DHCP and pppoe; they are having server outages all over the place and many people on wintel are complaining about uptimes on the order of an hour, and 200K/s transfers....
If you have a look at the newsgroups you will see that many wintel users are having to resort to and additional commercial ($90) package just to get back to 'acceptable' service after losing DHCP. Of course this is not making bell/sympatico look particularly good.
So for me at least, CDN $35/mo is looking just fine compared to that $20/mo dailup....
S.
I could be off here, but it seems to me that a lot of people are having a knee-jerk reaction to RH's aquisition plans etc. What did you expect,
:) ). Unfortunately there are going to be more and more pressures on RH from outside ( 'the community') to do things in conventially brain-damaged ways. That doesn't mean they will follow that pattern. I think this possibility is what people are reacting to, rather than any action RH has really taken.
:) --- and things didn't get really solid until 2.0.x kernels (for me at least). But for example, the 6.x versions ship with a buggy gnome, and then try really hard to get you to use it. My 6.0 machines would dump a core in ~ every time you log in! Sometime gnome would hang for a minute or two with *no feedback* as to what was happening (unless you count the X error messages) 6.1 I thought would be better but it has all the signs of being a rush job to get the new installer out the door. Gnome was still problematic, there are config hiccups with less often use packages, and the 'upgrade' changes parts of *my* config without warning or backups. Annoying. I don't want to pick on Gnome, there are plenty of other examples but this message is way too long already...
.rpm vs say , .deb. The .deb is a better design, and fits in to existing tools more easily. Why didn't RH, realising this, bail on .rpm and make a set of good tools to sit on top of the .deb format? Ok, I know this has been talked to death, but I recall it to bring to mind the problems we could face in a couple of years if redhat has both a) de-facto control of a number of significant projects and b) a not-invented-here syndrome...
really? They have to do something with the (absurd) market cap they have or they will loose it, *fast*. There are a lot of holes in the RH business plan at the moment, so of course they will try and plug them. Whether or not a particular purchase is good idea for redhat or for 'the community' (whatever that is) is not such an easy question to answer.
I think it is *way* too early to start lumping them in with MS. Look, big (market wise) companies buy small ones because it is cheaper than developing in-house (or at least some PHB thinks it is). Why should we expect RH be different in that? The question is, what are they going to do with this new leverage they currently command in the commercial linux world? And what can we do to help keep them on track? Just because a company has money doesn't actually make them evil (statistical evidence aside
One interesting point is the fact that while RH and Cygnus are (were?) both commercial players in the open-source game, they had different outlooks. RH may have bundled commercial software, but it has always claimed that in-house software will be returned to 'the community'. Cygnus on the other hand had a commercial version/free version approach. The question is, will RH free up the Cygnus tools, or bundle them as a commercial add-on?
A more important issue is the long term scope of RHlabs. Indirectly, RH has aquired the current gcc maintenance codebase and people, no? This is not inherently a bad thing. However, it does raise a few interesting points: like how much concentration of OS projects is a good thing? If at some later date RH starts playing silly buggers with some of 'our' cherised projects, is the OS community going to be faced with the possibility of a series of ugly forks?
On a related note, RH is putting a lot of effort into PR on one side, and eye-candy (see new installer) on the other....fine, but they have some more serious problems to look at. I have recently played around with 5.1, 5.2, 6.0, 6.1 on both i386 and alpha. For the most part things have been smooth to get up and going (excepting 5.x on alpha). The problem is, once the system is up. I have never had as much trouble with a linux box as I have with the 6.x machines. Okay, that is not quite true... the 0.11x betas would fall down hourly when you played with them (but it was fun
The point I am getting at (slowly, sorry) is that this is a bad sign. My debian machines, slack machines, and the machines that were hand-built (no distro) had never given me this much trouble. The problem is that in NA at least RH is becoming synonymous with Linux in the minds of the great unwashed. So either we don't care what anyone else thinks (a valid, if limited scope, view) or we care what people think about RH. In the later case we really need to push them on the underlying technical issues a bit. It is a bit discouraging, for example, to see the possibility of a BETA-VHS type thing being precipitated by RH. Look at
Enough rambling!
S.
I don't know how much you are looking to spend, but the KVM switches made by Black Box (www.blackbox.com IIRC) worked pretty well for me at a previous job. We had a big ($1500) 12:1 box and a smaller one... never had a problem with either of them.
of course, YMMV.
S.
I'm not out to bash Java here just picking a nit; I am a bit tired of hearing the 'The beautiful thing ... everyone seems to be missing...' type comments from various Java advocates. I don't know how many times I've heard/read 'and it works on *any* machine, **wow** what a breakthrough' statements. This is *not* a new idea. Java didn't invent it. For that matter, Sun didn't invent it. It is just cheesy hype from Sun on the same order as the common 'we invented the dll' type statements from MS.
Come on guys, Java (like just about any other language) has some good points and some bad points. It isn't really a general purpose language in the sense that C/C++ is so the trade offs are different. If you're on the right side of those trade-offs it can make you life a lot easier (wrt C/whatever); on the wrong side it can make your life miserable.
Please lets not have yet another discussion degenerate into a stupid language war full of pointless statements by people who either don't know what they are talking about or should know better than to get into it once the temperature is up, ok?
peace,
S.