I'm not quite sure how this will play out, but it seems to be an overlooked factor. In terms of hardware cost, a network of independent PCs would seem cheaper to upgrade because there's such tremendous pricing pressure in that very competitive market segment. However, when you consider the human cost of upgrades, the thin-client solution starts to look pretty attractive. You can pretty much swap one server machine and everyone gets the benefit, without having to run around upgrading hundreds of differently-configured PCs. If you actually do need to upgrade the clients, that's easy too because the clients are stateless. Take the new one out of the box, switch cables, put the old one in the box...voila!
I know there've been lots of other thin-client paradigms, from Sun's own diskless (my brother always called 'em "dickless") workstations to X terminals etc., but somehow this one reminds me of nothing quite so much as Plan 9. It's really not a bad idea. The question is whether Sun - whose track record in these areas is less than stellar - can execute the idea well.
Writing drivers (and here I mean "drivers" in the strict sense of the software that most directly controls a device, not in the loose sense that includes things like filesystems and protocol modules) is one of the least creative forms of kernel programming. Providing a framework for more portable drivers will reduce the development effort expended on drivers and will free up many developers to do other, more interesting, things...and that, to me, is more important than open vs. closed source.
>Virtual functions, for instance, would have to be layered on top of C with an entire application level framework to support it, and based on the arguments made in the C++ FAQS here, if you don't use or at least understand virtual functions, you're not working in OO, you're wanking.
That's sort of my point, actually. People have been doing the equivalent of virtual functions for years in C and even assembler, using function pointers and dispatch tables. Some other people think they're more advanced programmers because they use C++, but don't have the faintest clue what virtual functions are or what they're good for. That's just hogwash. C++ is not an option for kernel work in many environments - notably just about any flavor or UNIX, whereas NT actually supports in-kernel C++ quite well and even requires it in some cases (e.g. filesystems) - but it's still entirely possible to write very OO code in those situations.
Going back to what I said originally, criticizing a GUI framework for having a C rather than C++ style native interface, without addressing the usefulness of its object model (or whether it even has one) is - to borrow your own phrase - just wanking. If it's decently OO but expressed in C, C++ wrappers are a trivial exercise. If it's lousy OO but expressed in C++, there's no easy way to fix it.
>C as a language doesn't support the required features to allow you to program in an truly OO manner.
Anything expressible in C++ is expressible in C. This was an explicit design decision for C++. Therefore, C supports every feature C++ does, and if that's not enough to do OOP in C then it's not enough to do OOP in C++ either.
There's an old saying: a bad programmer can write bad FORTRAN in any language. I've seen C and even assembly code that is very object-oriented despite the limitations of those languages. OTOH, most of the worst and least OO code I've ever seen was in C++. We're talking about code that abuses statics and globals, that uses inheritance in unsavory ways (e.g. just to avoid having to type parameters) without any rational parent/child/peer model in mind, that uses overloading to make the code unreadable, etc.
Using C++ does not make code OO, and in some ways even interferes with that effort. Criticizing something for being C rather than C++, without adressing whether it is or is not good OO, is a sure way to prove that you don't even know the difference.
I think he was talking about something that could become the basis for a real program, not some throwaway POS that only reveals the poor programming practices of its author.
Actually, 70+ lines is about right for a _Win32_ program. At the very least, you have to register your window class, create a window, do a message loop, write a window procedure that calls DefWindowProc (or whatever, it's been a while) and so on. Of course, if you're an MFC weenie, you may write a lot less code but MFC != Win32, and the most common way of using MFC via "wizards" in VC++ actually ends up generating a lot more than 70 lines of code for you.
That said, Win32 may be easier than Xlib - or maybe not - but the original estimate was more tied to reality than your "correction".
Palpatine is the negative-agreeability archetype. I know this, because I got a perfect 0% on that part and that's who showed up[1]. Did anyone else get a "perfect score" on any category so we can see who the other boundary cases are?
[1] Under the circumstances, the only possible reaction is "$#@! you with a ten-foot fork";-)
>hiking costs for us, the gamers. If you're an >addict like me, they can break your bank.
Interesting that you refer to gaming as an addiction, making the social significance of stealing to support your habit even more apparent. Do you think other addictions should be enabled in this fashion? We should force the liquor and tobacco producers to reduce their prices, then. Capitalism be damned, it is imperative that we make it as easy as possible for people with impulse-control problems to indulge in their preferred vices.
Yeah, right. What you're doing is theft, in part from your fellow programmers...assuming you're a programmer yourself. Get a life/clue/whatever.
My experience was a little different. I installed a new disk drive in my system, making the new one the primary IDE master (I do SCSI at work, don't want it at home) with the old one as primary slave. I could still boot Windows 95 - yes, 95, not 98 - via LILO off the old drive and it would figure out what happened and be happy. When I tried to boot Linux off the old partition it wasn't happy because what used to be/dev/hda was now/dev/hdb etc. So I restored the old hardware config, booted Linux, fixed up LILO and/etc/fstab and so on and so forth, and rebooted. Still doesn't work. Maybe there's some step I forgot, but if anyone here says it's my own fault for not remembering to change/etc/shove_this or whatever then I don't ever want to hear a comment from the same person sneering about config.sys and win.ini and "that just works on Linux" because there's just as much nobody-could-have-known crap on Linux as on Windows. I've been working on UNIX kernels longer than Messrs. Torvalds and Cox, and it's entirely reasonable to say that the OS should be able to figure out something as simple as this and deal with it instead of crashing. Remeber, even lowly Win95 managed it, and Linux fell over itself.
First off, the way he counts seven versions of Windows 98 is dishonest, since it counts the same thing bought in a store and downloaded electronically as two separate versions. Yeah, right. By my count it's more like four of five, which is still a really stupid way to release software, so it would have been better to report the sad truth honestly instead of trying to inflate the numbers.
Others have addressed the way that many Windows applications port more easily between 95/98/NT[1] than UNIX applications port between e.g. Linux/AIX/HPUX. Heck, thanks to glibc-maintainer incompetence, even portability between Linux distros is often questionable. What I'd like to point out is the issue of driver portability. Windows 98 adopted the "Windows Driver Model" which is a minor variation on the model NT had used all along. While this doesn't necessarily mean that the same driver binary will work with both, the changes required are trivial. Compare this to the situation in UNIX-land. Driver models are drastically different between UNIX versions, even between those that supposedly use standards such as DDI/DKI or DLPI. Occasionally a driver can be ported with little change, but more often 30-50% of the driver code has to be different for each platform. The saddest part is that there have been efforts to agree on a common UNIX driver model, but people right here always shout them down as a way to make it easier for vendors to ship closed binaries. *sigh* You want openness, you take fragmentation with it as a necessary consequence, and I wish everyone who tries to have their cake and eat it too (in this or other contexts) would just choke to death.
[1] As an owner of and programmer for a CE device, I think it's fair to say that CE isn't truly part of the "Windows family". Yes, it has the same GUI, mostly, but the internals are totally different.
A few years ago I interviewed at {name deleted to protect the guilty}, and the people interviewing me made a big deal of having restaurant-quality food brought in for breakfast, lunch, and dinner. I immediately knew that meant they expected people to be there for breakfast, lunch, and dinner, so I jokingly asked if they had cots and showers. They denied that it was like that, but of course they were lying.
The long and the short of it is that companies don't offer these perks because they're nice guys. The point about a $50/hour masseuse being a lot cheaper than even a 1% raise for your engineers hit it right on the button.
There's actually an aspect of the whole thing that's just a little discriminatory. It doesn't take a genius to notice that not everyone can take equal advantage of many of these perks...and I'm not even talking about something as obvious as a lactation room here. Seems to me that the people who are don't want perks should be eligible to receive those perks' cash value instead to make things fair.
>Only yesterday, I had a greying geek, who was probably hot stuff in the mainframe days, come to my NT workstation, and have difficulty navigating to the floppy drive.
While I generally agree with what you say, you do need to be careful about what evidence you use to conclude that someone else is clueless. Does not knowing a particular technique on a particular OS invalidate 20+ years of design experience? I know that's not what you're saying, but often what people think is based on very little more than that. It helps to remember that this guy might laugh at the way you stumble when you're in his favored environment.
There's a common tendency to assume that things we know are worth knowing, and things we don't know are just junk. It's an especially common tendency among young and technically-inclined people, which is why we see it constantly in the Windows vs. Linux flame-wars. The Windows zealots think you're an idiot if you don't know COM or config.sys, the Linux zealots think you're an idiot if you don't know CORBA or/etc/init.d, and those of us who've lived through a few rounds of such wars just roll our eyes.
The point is that the most valuable skills often turn out to be the ones that we ourselves do not have, that we might have considered obscure and useless until the very moment that we tripped over a situation where they were needed. Maybe someone else's skills really are useless and outdated, maybe that guy is a stuck-in-his-ways old relic, but we should be very hesitant lest we make that determination too quickly and have to eat our hats later.
Everything I say here is a generalization. There will be exceptions to every statement, but I hope we all know the difference between anecdotes and trends.
Older workers have several advantages over their younger peers. Foremost among these is that they generally have both a breadth and depth of experience that their younger peers. They're more likely to have seen something similar to the current problem, remember the tradeoffs and pitfalls of various solutions, etc. They often have better communication and interpersonal skills than younger folk. Lastly, there's nothing about coding that favors the young, unlike for example mountain-bike racing. It's a sedentary intellectual activity, and like any such activity people get better at it when they do it more, and older programmers have done it more.
There are also major downsides to older workers. They do tend to be more expensive. Depth of experience is of no (or even negative) value if it's in the wrong area. Single-machine FORTRAN or COBOL skills on an OS that hardly exists any more might not be all that valuable when programming is done in C++ or Java in a distributed environment using CORBA etc. With the rate of change in this industry it is essential for anyone to keep up with the latest technologies, even if it means that sometimes you'll "waste time" learning a technology that drops off everyone's radar screens when the next competing standard comes along. C'est la vie. Contrary to popular belief, old dogs can learn new tricks, but too many people both young and old don't make the effort; the only difference is that the young one's laziness hasn't caught up with them yet.
There's one area where I defy conventional wisdom: amount of work. Yes, younger people - especially single ones - are more likely to work longer hours. They're also more likely to spend half of those hours surfing the web, on IRC/MOO, playing Quake, etc. Older people are likely to work fewer hours because of family commitments and so on, more likely to take sick leave, probably have more vacation time, but in my experience they do have a better work ethic. 40 hours of "work" is 40 hours of work instead of 70 hours of "work" being evenly split between real work and play. Overall, I think the older folks I've worked with got more done on a per-week basis than the younger ones who put in longer hours. YMMV.
Overall, I think we need both. I've long since abandoned the "one size fits all" philosophy, and that applies to personnel too. I think the best projects combine the experience and discipline of a few older workers with the energy and exuberance of a few younger ones. I've worked at companies that were unbalanced in both directions, and both suck.
Actually, the use of ISA to mean "Instruction Set Architecture" may well predate it use to mean "Industry Standard Architecture". In any case, both meanings have been around for a long time and we might as well get used to them. It wouldn't be the only time the same acronym had two very distinct meanings. ATM, anyone?
[Apologies if this sounds familiar to long-time readers; I've said this before and I believe it bears saying again.]
In addition to the lower native gate speed and inefficiencies of cell-based logic of FPGAs vis a vis full-custom processors, there's a serious problem with the time it takes to reprogram an FPGA. To put this in perspective, let's say that the time to perform computational work can be expressed as AX+B, where A is the time to perform an operation, X is the number of times the operation is repeated before moving on to a different operation, and B is the time to program that operation into the processor. For a traditional processor, B is zero. For an FPGA, A might be smaller than it is for the traditional processor, but B is very large. It doesn't take a rocket scientist[1] to figure out, therefore, that FPGAs win when X is large, i.e. when a task is very highly repetitive. There are a lot of tasks that fit this mold - audio and video processing, discrete-element simulations, etc. - but many of the most common everyday computational tasks you and I might face do not. For those cases, reprogramming overhead would be a killer.
Is there hope? Yes, absolutely. Lots of people are working on faster reprogramming, because it's known to be the One Big Problem in reconfigurable computing. Even better, work on partial reprogrammability is increasing. This is really cool because it would essentially allow you to dedicate part of the processor to functions you always need[2], and then use the rest to cache logic very much as data is cached now. In its simplest form, this could mean that all the parts of a traditional processor except for the actual functional units are permanent, and the cached items are instructions much like the instructions we have today. Need a population-count instruction? Allocate logic space and an opcode, reprogram the space, and voila! When you no longer need that instruction it'll fall out of the cache to be replaced by another instruction you do need. Of course, when the von Neumann model itself becomes the bottleneck then maybe the cached items would have interfaces other than instruction opcodes and register files, but defining those interfaces to allow the sort of logic-caching I've described is still a major conceptual problem worthy of a doctoral thesis or two.
[1] What's so special about rocket scientists, anyway? There are plenty of professions nowadays requiring greater knowledge and skill.
[2] The permanent part could even be implemented full-custom style, while the reprogrammable part remains cell-based. Altera had something called an SPGA which was like this, but I can't find it any more.
>I figured they would have got farther with the Ethernet clustering by now. They've been working on it for quite some time. 6 or 7 years, at least?
Longer than that, I think. I vaguely recall reading about it about ten years ago.
>To show how really out of touch I am now with the Digital world, what's MC?
Memory Channel. Originally it was based on Encore's Reflective Memory technology, but I've heard that in a later version they redid the whole thing pretty thoroughly.
What masterwork? VMS's DLM wasn't truly distributed, it was "static master with a capability for recovery". As a result, four-node DB scalability using plain old Ethernet never exceeded 0.6. With a truly distributed lock manager and dynamic resource migration, we got up to 0.8. We also never forgave Oracle for retaining all sorts of VMS-specific semantics (the classic six lock modes, blocking ASTs) in the lock-manager specification even when running on non-VMS platforms.
DEC was pretty much the first to develop HA clustering as we know it today, and to this day leads the pack in terms of functionality. However, they tend to use a big proprietary-hardware crutch quite a bit. It used to be the HSC, now it's MC. If you take away the proprietary hardware DEC's offerings lose a little bit of functionality (though still remaining quite excellent) and a lot of performance.
>I seem to recall that in a recent interview Linus said HA software wasn't being pushed hard in linux development because the whole point of linux development was to not have the software crash all the time in the first place. > >If MS wants High Availability, fix the durned bugs.
These comments, even Linus's, are just plain ignorant. HA exists to recover from a huge range of failures, from hardware going bad to cables getting tripped over to OS bugs to driver bugs (two different things!) to application bugs to cosmic rays. Nobody controls all of the drivers for either Linux or NT, and nobody can tell customers never to run beta drivers that might crash their systems. Failures will happen no matter how much Linus Torvalds would like us to think he's the smartest person ever born, or how much Bill Gates or Dave Cutler would like us to believe they are.
"Fixing the damn bugs" is sure as hell a good idea, but it's not enough.
>I'm sure as hell not paying for 8 1000$+ licenses and 8 quad-whatever comps to do the work of a decent linux box or two with far less hardware.
More ignorance. Wolfpack is considered pathetic precisely because it's limited to active-passive mode, while any HA package worth its salt allows active-active mode in which nodes are all doing real work all the time instead of just sitting around waiting for a failure. The tradeoff you present just doesn't exist in real life.
I was one of the principal designers and implementors of both the cluster manager and lock manager for HACMP/6000 version 3.1 (which, BTW, supported 8-way symmetric failover) back in '94, so maybe I'm qualified to comment on some of this.
First, about MS. The consensus opinion among people who really know HA is that Wolfpack was and is the most pathetic piece of junk ever. The prevailing theory is that they quite deliberately announced it knowing that it was junk, to scare off anyone (such as my employer at the time) who might try to produce their own NT HA solutions.
This Janus project is just another step in that direction. 64 or 256 nodes? Yeah right. There are several reasons other HA solutions typically only go up to eight. The main one is that nobody really wants a single cluster that big. It's a total management nightmare. What customers actually want to do is set up multiple independent clusters of a reasonable size, and perhaps manage them all from within a common framework, but that's not the same as a single cluster. There's just no benefit to offset the cost of setting up failover relationships that deep and complex.
Another reason you don't see HA clusters beyond eight is that it's all but impossible to devise protocols (membership, hearbeat, consensus, and so on) that scale that high and yet still handle the simple cases efficiently. Just avoiding all the race conditions in eight nodes booting and trying to join the cluster at once is incredibly difficult. If you don't think it's that hard, try it. Have fun. Come back after you've failed, and we'll talk.;-) MS has so far exhibited nothing but the most startling ignorance and incompetence in these areas so far, and the idea that they'll suddenly leapfrog the established experts like this is just bunk. It's far easier to believe that they're deliberately making false claims to scare off the competition...again.
Now that I've bashed MS HA, a few words about Linux HA. It's as pathetic as MS. We have some very basic heartbeat code, and a few other scattered bits and pieces, but that's it. There's practically no fault identification to distinguish different types of failures so that one can respond differently to an adapter or network failure as distinct from a node failure. There's no lock manager. Many of the people working on the designs are only beginning to grasp the basic problems, and they're months if not years from actually implementing industrial-strength solutions. I'm on the mailing list (or I was, before I moved and had to give up my cable-modem account), I see the traffic, and it's Just Not There. I'm sorry, and I wish I could spare more time to contribute more of my own hard-won experience to the project, but that's just the way things are.
>QNX is a horrible operating system. I wouldn't >use it to run a toaster, much less a desktop >environment
You again, tlewis? Why are you on this anti-QNX crusade, anyway? For a brief moment, I was wondering whether you work for a QNX competitor, but then I remembered from our last encounter that you don't have any OS or embedded-system experience so that seems unlikely. I can only guess that you enjoy trolling.
As I pointed out last time, different platforms are intended for different environments, in terms of both the "lower environment" of what the hardware provides and the "upper environment" of what the applications/users require. Your phrasing "...much less a desktop environment..." shows your bias; like many people, you seem to consider the desktop to be the whole world. This is just not realistic.
>Message passing is for wussies
Speaking of what's "for wussies" how much real programming have you done? Application-level programming is "for wussies" as far as I'm concerned, and that's all you ever seem to have done.
Message passing is not "for wussies" at all. Look under the covers of any supposedly non-message-passing system - even a processor/memory bus - and what you'll see are...messages! It doesn't make any difference that the messages are processed by hardware rather than software. Now, given that it's all messages in reality, what's wrong with passing messages that represent higher-level semantic concepts than "get" and "put"? Answer: nothing. Message passing is, in short, an essential part of computing.
Is explicit message passing implemented in software a good basis for an OS? Yeah, it's OK, if one understands its strengths and weaknesses. Message passing is good for supporting heterogeneous systems, long latencies, and robust fault detection/recovery, compared to memory sharing. Message passing can also suck like a black hole wrt performance. Efficient message passing is essential, as is an overall architecture that keeps the number of messages and/or time blocked waiting for messages down. Many message-passing systems (e.g. Mach) have sucked because they had layer after layer of overly-complex interfaces creating more message traffic, and were insufficiently parallel within each subsystem to tolerate message latencies. But it _can_ be done right. Did QNX do it right? I don't know, but I've heard quite a few comments leading me to believe that maybe they did.
As an aside, I have worked on both hardware and software versions of distributed shared memory. The latencies etc. involved present some very hard problems which to the best of my knowledge have not yet been adequately solved. I'm inclined at this point to believe that - until we understand the solutions better - anything inherently distributed is better off with explicit message passing than with a shared-memory paradigm on top of a translation to the necessary message passing.
Slashdot Mirror
I'm not quite sure how this will play out, but it seems to be an overlooked factor. In terms of hardware cost, a network of independent PCs would seem cheaper to upgrade because there's such tremendous pricing pressure in that very competitive market segment. However, when you consider the human cost of upgrades, the thin-client solution starts to look pretty attractive. You can pretty much swap one server machine and everyone gets the benefit, without having to run around upgrading hundreds of differently-configured PCs. If you actually do need to upgrade the clients, that's easy too because the clients are stateless. Take the new one out of the box, switch cables, put the old one in the box...voila!
I know there've been lots of other thin-client paradigms, from Sun's own diskless (my brother always called 'em "dickless") workstations to X terminals etc., but somehow this one reminds me of nothing quite so much as Plan 9. It's really not a bad idea. The question is whether Sun - whose track record in these areas is less than stellar - can execute the idea well.
Writing drivers (and here I mean "drivers" in the strict sense of the software that most directly controls a device, not in the loose sense that includes things like filesystems and protocol modules) is one of the least creative forms of kernel programming. Providing a framework for more portable drivers will reduce the development effort expended on drivers and will free up many developers to do other, more interesting, things...and that, to me, is more important than open vs. closed source.
>Virtual functions, for instance, would have to be layered on top of C with an entire application level framework to support it, and based on the arguments made in the C++ FAQS here, if you don't use or at least understand virtual functions, you're not working in OO, you're wanking.
That's sort of my point, actually. People have been doing the equivalent of virtual functions for years in C and even assembler, using function pointers and dispatch tables. Some other people think they're more advanced programmers because they use C++, but don't have the faintest clue what virtual functions are or what they're good for. That's just hogwash. C++ is not an option for kernel work in many environments - notably just about any flavor or UNIX, whereas NT actually supports in-kernel C++ quite well and even requires it in some cases (e.g. filesystems) - but it's still entirely possible to write very OO code in those situations.
Going back to what I said originally, criticizing a GUI framework for having a C rather than C++ style native interface, without addressing the usefulness of its object model (or whether it even has one) is - to borrow your own phrase - just wanking. If it's decently OO but expressed in C, C++ wrappers are a trivial exercise. If it's lousy OO but expressed in C++, there's no easy way to fix it.
>I have an old Win32 FTP application I wrote that's right around 100 lines w/o comments. That's including the network code.
You, sir, are simply a liar and a troll.
>C as a language doesn't support the required features to allow you to program in an truly OO manner.
Anything expressible in C++ is expressible in C. This was an explicit design decision for C++. Therefore, C supports every feature C++ does, and if that's not enough to do OOP in C then it's not enough to do OOP in C++ either.
There's an old saying: a bad programmer can write bad FORTRAN in any language. I've seen C and even assembly code that is very object-oriented despite the limitations of those languages. OTOH, most of the worst and least OO code I've ever seen was in C++. We're talking about code that abuses statics and globals, that uses inheritance in unsavory ways (e.g. just to avoid having to type parameters) without any rational parent/child/peer model in mind, that uses overloading to make the code unreadable, etc.
Using C++ does not make code OO, and in some ways even interferes with that effort. Criticizing something for being C rather than C++, without adressing whether it is or is not good OO, is a sure way to prove that you don't even know the difference.
I think he was talking about something that could become the basis for a real program, not some throwaway POS that only reveals the poor programming practices of its author.
Actually, 70+ lines is about right for a _Win32_ program. At the very least, you have to register your window class, create a window, do a message loop, write a window procedure that calls DefWindowProc (or whatever, it's been a while) and so on. Of course, if you're an MFC weenie, you may write a lot less code but MFC != Win32, and the most common way of using MFC via "wizards" in VC++ actually ends up generating a lot more than 70 lines of code for you.
That said, Win32 may be easier than Xlib - or maybe not - but the original estimate was more tied to reality than your "correction".
>>3) Rent a game first to try it.
>
>Fine. But 2 big problems. First, it is hard to find places to rent PC games
Gee, have you wondered why that might be the case?
Palpatine is the negative-agreeability archetype. I know this, because I got a perfect 0% on that part and that's who showed up[1]. Did anyone else get a "perfect score" on any category so we can see who the other boundary cases are?
;-)
[1] Under the circumstances, the only possible reaction is "$#@! you with a ten-foot fork"
>hiking costs for us, the gamers. If you're an >addict like me, they can break your bank.
Interesting that you refer to gaming as an addiction, making the social significance of stealing to support your habit even more apparent. Do you think other addictions should be enabled in this fashion? We should force the liquor and tobacco producers to reduce their prices, then. Capitalism be damned, it is imperative that we make it as easy as possible for people with impulse-control problems to indulge in their preferred vices.
Yeah, right. What you're doing is theft, in part from your fellow programmers...assuming you're a programmer yourself. Get a life/clue/whatever.
My experience was a little different. I installed a new disk drive in my system, making the new one the primary IDE master (I do SCSI at work, don't want it at home) with the old one as primary slave. I could still boot Windows 95 - yes, 95, not 98 - via LILO off the old drive and it would figure out what happened and be happy. When I tried to boot Linux off the old partition it wasn't happy because what used to be /dev/hda was now /dev/hdb etc. So I restored the old hardware config, booted Linux, fixed up LILO and /etc/fstab and so on and so forth, and rebooted. Still doesn't work. Maybe there's some step I forgot, but if anyone here says it's my own fault for not remembering to change /etc/shove_this or whatever then I don't ever want to hear a comment from the same person sneering about config.sys and win.ini and "that just works on Linux" because there's just as much nobody-could-have-known crap on Linux as on Windows. I've been working on UNIX kernels longer than Messrs. Torvalds and Cox, and it's entirely reasonable to say that the OS should be able to figure out something as simple as this and deal with it instead of crashing. Remeber, even lowly Win95 managed it, and Linux fell over itself.
First off, the way he counts seven versions of Windows 98 is dishonest, since it counts the same thing bought in a store and downloaded electronically as two separate versions. Yeah, right. By my count it's more like four of five, which is still a really stupid way to release software, so it would have been better to report the sad truth honestly instead of trying to inflate the numbers.
Others have addressed the way that many Windows applications port more easily between 95/98/NT[1] than UNIX applications port between e.g. Linux/AIX/HPUX. Heck, thanks to glibc-maintainer incompetence, even portability between Linux distros is often questionable. What I'd like to point out is the issue of driver portability. Windows 98 adopted the "Windows Driver Model" which is a minor variation on the model NT had used all along. While this doesn't necessarily mean that the same driver binary will work with both, the changes required are trivial. Compare this to the situation in UNIX-land. Driver models are drastically different between UNIX versions, even between those that supposedly use standards such as DDI/DKI or DLPI. Occasionally a driver can be ported with little change, but more often 30-50% of the driver code has to be different for each platform. The saddest part is that there have been efforts to agree on a common UNIX driver model, but people right here always shout them down as a way to make it easier for vendors to ship closed binaries. *sigh* You want openness, you take fragmentation with it as a necessary consequence, and I wish everyone who tries to have their cake and eat it too (in this or other contexts) would just choke to death.
[1] As an owner of and programmer for a CE device, I think it's fair to say that CE isn't truly part of the "Windows family". Yes, it has the same GUI, mostly, but the internals are totally different.
A few years ago I interviewed at {name deleted to protect the guilty}, and the people interviewing me made a big deal of having restaurant-quality food brought in for breakfast, lunch, and dinner. I immediately knew that meant they expected people to be there for breakfast, lunch, and dinner, so I jokingly asked if they had cots and showers. They denied that it was like that, but of course they were lying.
The long and the short of it is that companies don't offer these perks because they're nice guys. The point about a $50/hour masseuse being a lot cheaper than even a 1% raise for your engineers hit it right on the button.
There's actually an aspect of the whole thing that's just a little discriminatory. It doesn't take a genius to notice that not everyone can take equal advantage of many of these perks...and I'm not even talking about something as obvious as a lactation room here. Seems to me that the people who are don't want perks should be eligible to receive those perks' cash value instead to make things fair.
>I'd also suggest that if you know how to do the job right the first time, you don't have to stay until 2:00 am debugging it...
I know we all hate "me too" posts, but...amen, brother! I could not agree more with your post.
>Only yesterday, I had a greying geek, who was probably hot stuff in the mainframe days, come to my NT workstation, and have difficulty navigating to the floppy drive.
/etc/init.d, and those of us who've lived through a few rounds of such wars just roll our eyes.
While I generally agree with what you say, you do need to be careful about what evidence you use to conclude that someone else is clueless. Does not knowing a particular technique on a particular OS invalidate 20+ years of design experience? I know that's not what you're saying, but often what people think is based on very little more than that. It helps to remember that this guy might laugh at the way you stumble when you're in his favored environment.
There's a common tendency to assume that things we know are worth knowing, and things we don't know are just junk. It's an especially common tendency among young and technically-inclined people, which is why we see it constantly in the Windows vs. Linux flame-wars. The Windows zealots think you're an idiot if you don't know COM or config.sys, the Linux zealots think you're an idiot if you don't know CORBA or
The point is that the most valuable skills often turn out to be the ones that we ourselves do not have, that we might have considered obscure and useless until the very moment that we tripped over a situation where they were needed. Maybe someone else's skills really are useless and outdated, maybe that guy is a stuck-in-his-ways old relic, but we should be very hesitant lest we make that determination too quickly and have to eat our hats later.
Everything I say here is a generalization. There will be exceptions to every statement, but I hope we all know the difference between anecdotes and trends.
Older workers have several advantages over their younger peers. Foremost among these is that they generally have both a breadth and depth of experience that their younger peers. They're more likely to have seen something similar to the current problem, remember the tradeoffs and pitfalls of various solutions, etc. They often have better communication and interpersonal skills than younger folk. Lastly, there's nothing about coding that favors the young, unlike for example mountain-bike racing. It's a sedentary intellectual activity, and like any such activity people get better at it when they do it more, and older programmers have done it more.
There are also major downsides to older workers. They do tend to be more expensive. Depth of experience is of no (or even negative) value if it's in the wrong area. Single-machine FORTRAN or COBOL skills on an OS that hardly exists any more might not be all that valuable when programming is done in C++ or Java in a distributed environment using CORBA etc. With the rate of change in this industry it is essential for anyone to keep up with the latest technologies, even if it means that sometimes you'll "waste time" learning a technology that drops off everyone's radar screens when the next competing standard comes along. C'est la vie. Contrary to popular belief, old dogs can learn new tricks, but too many people both young and old don't make the effort; the only difference is that the young one's laziness hasn't caught up with them yet.
There's one area where I defy conventional wisdom: amount of work. Yes, younger people - especially single ones - are more likely to work longer hours. They're also more likely to spend half of those hours surfing the web, on IRC/MOO, playing Quake, etc. Older people are likely to work fewer hours because of family commitments and so on, more likely to take sick leave, probably have more vacation time, but in my experience they do have a better work ethic. 40 hours of "work" is 40 hours of work instead of 70 hours of "work" being evenly split between real work and play. Overall, I think the older folks I've worked with got more done on a per-week basis than the younger ones who put in longer hours. YMMV.
Overall, I think we need both. I've long since abandoned the "one size fits all" philosophy, and that applies to personnel too. I think the best projects combine the experience and discipline of a few older workers with the energy and exuberance of a few younger ones. I've worked at companies that were unbalanced in both directions, and both suck.
>FPGA's can run at much higher clock frequencies then current CPU's because of fundamental architectural differences.
That is incorrect. Gate speeds for FPGAs are _lower_ than for full-custom silicon.
>XF86 manages colors better than openwindows.
I thought we were talking about operating systems.
Actually, the use of ISA to mean "Instruction Set Architecture" may well predate it use to mean "Industry Standard Architecture". In any case, both meanings have been around for a long time and we might as well get used to them. It wouldn't be the only time the same acronym had two very distinct meanings. ATM, anyone?
[Apologies if this sounds familiar to long-time readers; I've said this before and I believe it bears saying again.]
In addition to the lower native gate speed and inefficiencies of cell-based logic of FPGAs vis a vis full-custom processors, there's a serious problem with the time it takes to reprogram an FPGA. To put this in perspective, let's say that the time to perform computational work can be expressed as AX+B, where A is the time to perform an operation, X is the number of times the operation is repeated before moving on to a different operation, and B is the time to program that operation into the processor. For a traditional processor, B is zero. For an FPGA, A might be smaller than it is for the traditional processor, but B is very large. It doesn't take a rocket scientist[1] to figure out, therefore, that FPGAs win when X is large, i.e. when a task is very highly repetitive. There are a lot of tasks that fit this mold - audio and video processing, discrete-element simulations, etc. - but many of the most common everyday computational tasks you and I might face do not. For those cases, reprogramming overhead would be a killer.
Is there hope? Yes, absolutely. Lots of people are working on faster reprogramming, because it's known to be the One Big Problem in reconfigurable computing. Even better, work on partial reprogrammability is increasing. This is really cool because it would essentially allow you to dedicate part of the processor to functions you always need[2], and then use the rest to cache logic very much as data is cached now. In its simplest form, this could mean that all the parts of a traditional processor except for the actual functional units are permanent, and the cached items are instructions much like the instructions we have today. Need a population-count instruction? Allocate logic space and an opcode, reprogram the space, and voila! When you no longer need that instruction it'll fall out of the cache to be replaced by another instruction you do need. Of course, when the von Neumann model itself becomes the bottleneck then maybe the cached items would have interfaces other than instruction opcodes and register files, but defining those interfaces to allow the sort of logic-caching I've described is still a major conceptual problem worthy of a doctoral thesis or two.
[1] What's so special about rocket scientists, anyway? There are plenty of professions nowadays requiring greater knowledge and skill.
[2] The permanent part could even be implemented full-custom style, while the reprogrammable part remains cell-based. Altera had something called an SPGA which was like this, but I can't find it any more.
>I figured they would have got farther with the Ethernet clustering by now. They've been working on it for quite some time. 6 or 7 years, at least?
Longer than that, I think. I vaguely recall reading about it about ten years ago.
>To show how really out of touch I am now with the Digital world, what's MC?
Memory Channel. Originally it was based on Encore's Reflective Memory technology, but I've heard that in a later version they redid the whole thing pretty thoroughly.
What masterwork? VMS's DLM wasn't truly distributed, it was "static master with a capability for recovery". As a result, four-node DB scalability using plain old Ethernet never exceeded 0.6. With a truly distributed lock manager and dynamic resource migration, we got up to 0.8. We also never forgave Oracle for retaining all sorts of VMS-specific semantics (the classic six lock modes, blocking ASTs) in the lock-manager specification even when running on non-VMS platforms.
DEC was pretty much the first to develop HA clustering as we know it today, and to this day leads the pack in terms of functionality. However, they tend to use a big proprietary-hardware crutch quite a bit. It used to be the HSC, now it's MC. If you take away the proprietary hardware DEC's offerings lose a little bit of functionality (though still remaining quite excellent) and a lot of performance.
>I seem to recall that in a recent interview Linus said HA software wasn't being pushed hard in linux development because the whole point of linux development was to not have the software crash all the time in the first place.
>
>If MS wants High Availability, fix the durned bugs.
These comments, even Linus's, are just plain ignorant. HA exists to recover from a huge range of failures, from hardware going bad to cables getting tripped over to OS bugs to driver bugs (two different things!) to application bugs to cosmic rays. Nobody controls all of the drivers for either Linux or NT, and nobody can tell customers never to run beta drivers that might crash their systems. Failures will happen no matter how much Linus Torvalds would like us to think he's the smartest person ever born, or how much Bill Gates or Dave Cutler would like us to believe they are.
"Fixing the damn bugs" is sure as hell a good idea, but it's not enough.
>I'm sure as hell not paying for 8 1000$+ licenses and 8 quad-whatever comps to do the work of a decent linux box or two with far less hardware.
More ignorance. Wolfpack is considered pathetic precisely because it's limited to active-passive mode, while any HA package worth its salt allows active-active mode in which nodes are all doing real work all the time instead of just sitting around waiting for a failure. The tradeoff you present just doesn't exist in real life.
I was one of the principal designers and implementors of both the cluster manager and lock manager for HACMP/6000 version 3.1 (which, BTW, supported 8-way symmetric failover) back in '94, so maybe I'm qualified to comment on some of this.
;-) MS has so far exhibited nothing but the most startling ignorance and incompetence in these areas so far, and the idea that they'll suddenly leapfrog the established experts like this is just bunk. It's far easier to believe that they're deliberately making false claims to scare off the competition...again.
First, about MS. The consensus opinion among people who really know HA is that Wolfpack was and is the most pathetic piece of junk ever. The prevailing theory is that they quite deliberately announced it knowing that it was junk, to scare off anyone (such as my employer at the time) who might try to produce their own NT HA solutions.
This Janus project is just another step in that direction. 64 or 256 nodes? Yeah right. There are several reasons other HA solutions typically only go up to eight. The main one is that nobody really wants a single cluster that big. It's a total management nightmare. What customers actually want to do is set up multiple independent clusters of a reasonable size, and perhaps manage them all from within a common framework, but that's not the same as a single cluster. There's just no benefit to offset the cost of setting up failover relationships that deep and complex.
Another reason you don't see HA clusters beyond eight is that it's all but impossible to devise protocols (membership, hearbeat, consensus, and so on) that scale that high and yet still handle the simple cases efficiently. Just avoiding all the race conditions in eight nodes booting and trying to join the cluster at once is incredibly difficult. If you don't think it's that hard, try it. Have fun. Come back after you've failed, and we'll talk.
Now that I've bashed MS HA, a few words about Linux HA. It's as pathetic as MS. We have some very basic heartbeat code, and a few other scattered bits and pieces, but that's it. There's practically no fault identification to distinguish different types of failures so that one can respond differently to an adapter or network failure as distinct from a node failure. There's no lock manager. Many of the people working on the designs are only beginning to grasp the basic problems, and they're months if not years from actually implementing industrial-strength solutions. I'm on the mailing list (or I was, before I moved and had to give up my cable-modem account), I see the traffic, and it's Just Not There. I'm sorry, and I wish I could spare more time to contribute more of my own hard-won experience to the project, but that's just the way things are.
jdarcy@emc.com, until I get a new home account
>QNX is a horrible operating system. I wouldn't
>use it to run a toaster, much less a desktop
>environment
You again, tlewis? Why are you on this anti-QNX crusade, anyway? For a brief moment, I was wondering whether you work for a QNX competitor, but then I remembered from our last encounter that you don't have any OS or embedded-system experience so that seems unlikely. I can only guess that you enjoy trolling.
As I pointed out last time, different platforms are intended for different environments, in terms of both the "lower environment" of what the hardware provides and the "upper environment" of what the applications/users require. Your phrasing "...much less a desktop environment..." shows your bias; like many people, you seem to consider the desktop to be the whole world. This is just not realistic.
>Message passing is for wussies
Speaking of what's "for wussies" how much real programming have you done? Application-level programming is "for wussies" as far as I'm concerned, and that's all you ever seem to have done.
Message passing is not "for wussies" at all. Look under the covers of any supposedly non-message-passing system - even a processor/memory bus - and what you'll see are...messages! It doesn't make any difference that the messages are processed by hardware rather than software. Now, given that it's all messages in reality, what's wrong with passing messages that represent higher-level semantic concepts than "get" and "put"? Answer: nothing. Message passing is, in short, an essential part of computing.
Is explicit message passing implemented in software a good basis for an OS? Yeah, it's OK, if one understands its strengths and weaknesses. Message passing is good for supporting heterogeneous systems, long latencies, and robust fault detection/recovery, compared to memory sharing. Message passing can also suck like a black hole wrt performance. Efficient message passing is essential, as is an overall architecture that keeps the number of messages and/or time blocked waiting for messages down. Many message-passing systems (e.g. Mach) have sucked because they had layer after layer of overly-complex interfaces creating more message traffic, and were insufficiently parallel within each subsystem to tolerate message latencies. But it _can_ be done right. Did QNX do it right? I don't know, but I've heard quite a few comments leading me to believe that maybe they did.
As an aside, I have worked on both hardware and software versions of distributed shared memory. The latencies etc. involved present some very hard problems which to the best of my knowledge have not yet been adequately solved. I'm inclined at this point to believe that - until we understand the solutions better - anything inherently distributed is better off with explicit message passing than with a shared-memory paradigm on top of a translation to the necessary message passing.