The OpenMotif license is a compromise to keep all the paying members of the consortium happy. Most contributors to Motif licensed intellectual th^H^Hproperty to TOG, and that license isn't TOG's to give away.
As I understand it, an effort was made to solve this issue by having the contributors license their IP to the public for free, but contributors balked (or even more likely, got bogged down in their own legal departments). Hence this weird compromise.
Apart from the code not being production quality, it is likely not going to be production code in this form. Microsoft has access to a bunch of really good user interface folks, and chances are that they are dealing with the "how will we present a fatal error to the user" issue as we speak^H^Hculate.
I have no clue where the user interface guys will take it, but I'd be stunned if anything even remotely resembling a blue screen will appear in a non-debug build.
Getting field-proven developers is hard enough as it is without worrying about which talent pool you recruit them from.
If you strike a good deal with a good developer, it will be a win/win situation. Good programmers can do with a decent salary to pay the bills, and as long as you allow the guy (or gal) some slack in doing things in his/her copious spare time, you'll have a happy developer and the community benefits from the situation where he has a real life playground for his out-of-work ambitions.
Unless you're in a position to tell the lawyers what to do, steer clear from
them. Nothing is more demotivating than having a bunch of paper pushers looking
over your shoulder all day. Just be very up front about what exactly will become
corporate property, and where the limits of outside activities are (i.e., don't
compete, and don't get involved in activities that reflect badly on the company). Really, there is no need to put the gory details in writing as long as you get rid of the blanket restrictions that are in some contracts.
I sort of take it you're an American business, so firing people just because
you don't like the color of their socks shouldn't be an issue. I'm always surprised to see contract wording that is so anti-employee it hurts, while the person that drafted the contract completely forgot that retaining a creative person against his/her will is entirely against the company interest in the first place.
If law were this black and white, we wouldn't have the intricate layering of appeals processes, and we wouldn't have court rulings that consist for three quarters of quotes of other judges' interpretation of the law.
And while I don't want to enter the debate on whether the outcome of the trial is defendable on legal and moral grounds, I do want to point out that both parties have themselves to blame for letting it get this far out of hand.
I've been on the corporate side of such disputes more than once, and I'm actually quite proud none of them got out of hand to the point where talking could not resolve the issue (from both ends: getting the individual to stop damaging activities, and getting the corporation to at least listen to the warning signs).
I'm very tired of hearing this argument. It is the same argument as "no one ever got fired over buying IBM". If you feel good over the ability to sue, fine, it'll make you sleep better. But I've learned to sleep well by shrugging off the repeated experience of getting screwed over by vendors who just had a better lawyer than I did when the contracts were reviewed.
And that's with vendors where you can actually negociate a contract. Microsofts market dominance means it will get away with not negociating a contract. Take the EULA or leave it.
Besides, for a successful suit you'd need to prove something like gross negligence or criminal intent. I think the chance of proving that is slim in the case of this backdoor, and that they would probably walk away with a court order mandating half off upgrades to all affected users.
I think that the image of "us nerds" as being, well, somewhat weird has a footing in truth though. The folks that I appreciate as being like minded do tend to have something that set them apart at an early age, other than an interest or aptitude for science.
The whole thing of course boils down to the nature vs nurture debate, which I'm afraid we're not going to settle on slashdot. That said, I'm not buying the argument that peer pressure is keeping kids from becoming technologists. If the urge is there (and most of us around here probably recognize that urge), it won't be repressed. Worst would be that a kid becomes a closet technologist, but the True Calling will come out one day.
The trick with alarm circuits used to work in the Netherlands too. Unfortunately, the telco copped on in the early eighties and installed coils in all alarm circuits, limiting line capacity to its intended purpose.
The trick is either to have friends at the telco, or social engineer your way into them: "Hey, it's John from telco corporate headquarters. Just spoke with Peter at the city center CO about a problem a customer had with his line; seems you installed coils. Please do something about it".
I know an ISP that pulled this trick in the early days...
Until BGP, OSPF, and IS-IS all FULLY support IPv6 don't expect ANYONE to even begin a migration.
Well, of course there is the traditional killer app that can tip the balance real quickly. For example, RIPE (the European IP address agency) received a phone call one day from a cellphone operator that they needed two class A address ranges, and when could they get them?
Of course, those guys were sent back to the drawing board. But if one of the bigger handset manufacturers starts deploying IPV6 (and IPV6 is complete enough to do that right now), the balance of power would shift and a lot of folks would be forced to keep up with the Joneses.
As you say, my concern is with the infrastructure more than with client support. Microsoft has been mentioned a lot in this thread, and I would be greatly surprised if they didn't have something in the wings to at least work around lack of native IPV6 support for existing clients (like 6to4 support).
Re:You forget about the BSDi code influx...
on
Is BSD Dying?
·
· Score: 2
At long last, a rant about BSDi that isn't just inflammatory:-)
As of 4.2 BSD/OS, BSDi has awful multi-threading support (the programming interface bites). I'm not sure what you mean here. It's the plain old pthreads interface (which sort of sucks, but BSDi's implementation is stable and quite fast). There are some things it won't do, and depending on your expectations and your experiences with other implementations (which may have what you want, but blow up in other respects) that may or may not be a show stopper.
BSD/OS 4.x does not offer much in the way of thread priority, for example. Since pthreads were built on the assumption that apps should be coded to avoid contention in the first place, I'm sort of surprised that this is seen as a major problem by so many in the pthreads field (but it is seen as a problem, and not just by people who run into contention because they misdesigned their app).
The major claim to fame BSDi has when it comes to SMP is the clean system setup. One single kernel will run in pre-SMP IRQ mode, in single CPU APIC mode, or in multi CPU mode, switchable at run time, which makes for excellent troubleshooting. If you compare this to FreeBSD, where a kernel built for APIC mode won't even boot on a single CPU system, that's quite a difference.
The major claim to fame BSDi has in general over FreeBSD is the patch system. With the possible exception of the debian potato release, I know of no other Unix like system that is so easy to keep stable if you prefer a stable system to a bleeding edge system. This of course is also BSD/OS's drawback in some peoples minds, because living on the bleeding edge with BSDi means you'll have to do some manual jiggery pokery to make the bits you tack on coexist with what BSDi provides. To me that's a small price to be paid, but if you're in a hurry it can be annoying.
The horrible things you said about the BSDI shared libraries in the 2.x and 3.x time frames are accurate but there were worse problems (e.g., a hard to fix dependance on argv[0] not changing to make dlsym work) that prompted the replacement. Once again, it's a trade-off, and I valued the stability and performance over the problems (but I jumped at 4.x just to get rid of them). To each his dentifrice, as Opus said.
As to the original topic of the big BSDi contributions to FreeBSD, well, I'm waiting but not holding my breath. It's not unwillingness on BSDi's part, but there's only so many hours in a day... These days, my company spends its dollars on both the excellent, stable and dull BSD/OS, and the cheap, fast and up to date FreeBSD (oh, and we're also running Linux, Solaris and NT where it makes the most sense -- please don't roast me about the NT part, it was not my choice). The total license cost is negligable compared to the man-hours, and that's where we optimize.
I do not see any path out of this morass. I'd love to see something like a Library Of Congress archive of out-of-print manuals, to keep them accessible.
At least with these old devices, there was printed documentation. These days, it's all.PDF (if docs exist in the first place), and my hopes are not high on retrieving them if a modern device goes out of production. The number of times I've run into the situation that you count on being able to retrieve something from a bookmark, only to find the document is no longer there, and conversely, that I find myself with an archive of.pdf's that I've got not clue of what it's all about, and what it's status is...
I recently needed to buy an airline ticket from KLM (http://www.klm.com). They had this lovely browser detect JavaScript, and because I always disable JavaScript until I get to verify the authors intentions, I got a blank screen. So, I got a blank screen, glanced quickly over the code and enabled JavaScript.
Blank page.
As it turns out, the JavaScript code checked for IE or NS on MacPPC or Win32. If you run NS on BSD/OS, they don't want to do business with you. Neither do they care about Amiga, Mac68K, Linux, WAP phones, well, anything they never heard of...
Every three months they change the website, and every time I run into this, I point it out to them (at first to the webmasters, later to their PHB's). They usually fix it a few days after I report it, but they invariably screw it up when they bring a new site online and they fail to see that it's the kewl scripting that's the problem, not my browser.
I don't care how the site looks. I want to buy an airline ticket. This concept is one I have not been able to get across, and they will not acknowledge it's their problem. Sometimes I can vote with my feet, sometimes I can't: that's my biggest frustration.
Unfortunately, the Sourceforge code snippet library has two problems:
There is little code available
What's in there is hard to find
To be useful in this respect, it needs to have many more entries, and the categorization needs to be improved (and inappropriate entries purged, etcetera). Sort of like the patent database, actually:-)
That said, it's a cool idea and I always check the snippet library when I notice I'm reinventing a wheel.
Reading/proc may be a bit more work for the
programmer but is IMHO much safer than reading/dev/kmem.
This is true. However, even better is to have a good API to access to access kernel data. sysctl is unfortunately not widely advertised enough, which means that SNMP daemons like UCD-SNMP have not been fully converted over yet. The sysctl interface offers the well-definedness of/proc with the speed of kmem grovelling (and like/proc, it doesn't require privileges for read access unless you are trying to read privileged data).
Reading/proc is easier for scripts, but I hate having to redo all the structs that are already defined in system headers and writing code to fill them in. And for some reason (I've never quite figured out why),/proc seems more prone to write kernel code for.
My main dislike for/proc stems from a philosophical standpoint, which is that the kernel has no business with providing a user friendly interface -- that's what userland is for, but I'll happily sidestep such philosphical issues if they are shown to be overshadowed by other advantages.
For completenesses sake, the main advantage of kmem grovelling is that it also works on kernel coredumps. To me, it still leaves me in awe to run netstat or ps on a kernel coredump and be able to tell exactly what was going on at the time of the crash.
It will help other ports as well (not just FreeBSD and BSDi, but OSes like BeOS as well).
The hardest part of porting something as complex as Plex86 to a different OS is figuring out where to start. Just comparing the kernel modules for Linux and NetBSD will teach you a wealth of knowledge, and for the small but important details in the non-kernel bits, grepping for __NetBSD__ tells you where to start your port. After that, it is a small issue of coding and debugging.
It's not just about more eyeballs or exposing bugs in the primary development platform, it's also about lowering the barrier for other ports, which can accelerate the eyeballs effect.
The challenge of course is spending the money -- wisely. BSDi has a fairly small core of Really Good engineers, and they are obviously going to hire. That of course is a challenge in the current, still overheated, market.
Oh, I know OO design alright... I've worked on big projects in Java (which I'm also not a fan of, but mostly for it's runtime environment rather than the language). Years ago, I worked on Sather, which is a cool language.
However, important details like who owns a blob of memory take a more than disproportionate amount of time in understanding the Mozilla code. Feel free to take this particular comment as a gripe about either C++ or Mozilla.
My most important gripe about C++ is not the language itself, it's its support on UNIX. GDB just plain sucks when debugging C++ code, where it does an acceptable job on debugging C.
I sincerely doubt the "reduction" of several thousand C calls to a hundred C++ classes makes the thing easier to debug. Remember the "seven, plus or minus two" rule from cognitive psychology. C++ is supposed to make this issue better, by reducing the amount of bookkeeping to enable the developer to focus on functionality. Guess what? Most C routines I've debugged in the old code base required fewer things to jot down than the C++ classes in the new code base have -- precisely because the combination of data hiding and the ability to corrupt memory easily co-exist in the same language.
In an ideal world, memory corruption (beyond algorithmical corruption) would not exist, and debugging would be easier with an OO language. C++ doesn't offer this, and as a result, debugging it is more complicated than debugging C. I'm not talking about simple, algorithmical bugs -- those are easy to track down in C++, but those are not showstoppers either. It's the hard bugs, the one that take down the app, which are much harder to debug in C++ than in C.
Ah, thanks for admitting you're an OS/2 troll and not a Windows troll. It's always gratifying to see that I'm not the only one fighting for what I think is right (and yes, I too believe OS/2 is far superior to the winner of the popular vote).
As to being realistic, sure, do you think I'd even be on/. if my blood pressure wasn't A-OK?
I still have images of all night debugging sessions to get Wine working on BSDI 1.x on my retina. By the time I had the thing working and all actual applications supported by Wine at the time ran (i.e., WinMine and Solitaire), the Wine project had changed it's register use around, and my code was as good as worthless.
When I looked at the plex86 kernel module, I noticed little in the way of providing documentation about assumptions made about this particular kernel/"application" interface, and with the vivid Wine memory made me think twice about trying to port the kernel interface to either of FreeBSD or BSD/OS, my two main platforms.
Am I overlooking some docs, or does this issue need addressing?
Also, performance is next to irrelevant in my book, and I'm wondering what the focus on plex86 will do to the Bochs emulator, which works fairly well on BSD/OS, but again doubts on it's future have kept me from firing up gdb and trying to find the fixes that would make it work for me -- it doesn't itch quite hard enough at the moment to justify sinking time into, considering its unknown fate. It'd be really kewl if plex86 would have an emulation mode that makes the plex86/bochs distinction obsolete. Again, am I overlooking the obvious?
That was my immediate reaction as well. The whole thing reminds me of the 45 RPM singles that were distributed in magazines way back when: not sturdy piece of vinyl, but a square, badly deformed thin sheet that produced some noise if you eventually got the thing flat, even if most of it came from the record player rather than the amp.
Still, if they pull it off it's be a cool gizmo. It would reduce the shelf space for an MSDN subscription significantly. Besides, if you use them as frisbees they don't have enough mass to poke someones eye out.
Yup, TeX is probably the most thoroughly designed tool on the planet. That said, it's basic premise is to limit an implementations freedom to adjust the layout (reading Knuths remarks about Postscript fonts getting a pixel added is very informative to know just how rigid TeX is designed to be). This rigidity is its strongest point; as Knuth puts it: if he writes part one of a five part book series in 1980, he expects part five to have the exact same layout in 2000, and anyone who has ever tried to collect SF paperbacks from an author over a number of years knows how ugly the differences are if you put the books side by side on your bookshelf.
But I still think it is a pity that people insist HTML should be a powerful page layout tool. TeX is pretty anal in its requirement that page layout be predictable, which is cool for paper documents but way uncool for web pages. When I resize my web browser to show a long, narrow page, I'd appreciate it if the text flowed in such a way that the page would still be legible. This is already broken in a lot of web pages that insist on specifying table widths in pixels or using images to enforce a certain size, but TeX is even more inflexible in allowing the user to determine what his screen should look like.
Putting the user in control was one of the advantages of HTML in the old days. These days, one is glad if windows full of ads aren't popping up left, right and center, and obviously there must be someone around who thinks that is somehow a good idea...
I've been involved in efforts to get Cisco's do something sensible with prioritizing traffic over Frame Relay, to make sure Telnet survives in the face of rabid web browsing. It's a lost cause except in cases where the overloading is marginal in the first place.
Of course, this was in a friendly network setting, mostly TCP and no way for abusers to hide from the network managers.
And this was the easy case, prioritizing TCP. The problem with UDP is that it has no inherent flow control mechanism. Stuff like RealAudio has its own heuristics to avoid overloading a line, but as heuristics go, the time to respond to changing conditions is quite noticable, and because UDP doesn't back off by itself, in the mean time the link is loaded with packets that don't reach their final destination in the first place. On overloaded Frame Relay circuits, it is not unusual to see 50% of traffic consisting of TCP retransmits, and in those cases, tuning the rate down can actually improve performance. I don't want to know what happens to VoIP in those circumstances...
VoIP really hinges on the availability of fat pipes. They're cheap in the US and parts of Europe and Asia, but try getting a reliable circuit in South Africa...
Slashdot Mirror
As I understand it, an effort was made to solve this issue by having the contributors license their IP to the public for free, but contributors balked (or even more likely, got bogged down in their own legal departments). Hence this weird compromise.
I have no clue where the user interface guys will take it, but I'd be stunned if anything even remotely resembling a blue screen will appear in a non-debug build.
If you strike a good deal with a good developer, it will be a win/win situation. Good programmers can do with a decent salary to pay the bills, and as long as you allow the guy (or gal) some slack in doing things in his/her copious spare time, you'll have a happy developer and the community benefits from the situation where he has a real life playground for his out-of-work ambitions.
Unless you're in a position to tell the lawyers what to do, steer clear from them. Nothing is more demotivating than having a bunch of paper pushers looking over your shoulder all day. Just be very up front about what exactly will become corporate property, and where the limits of outside activities are (i.e., don't compete, and don't get involved in activities that reflect badly on the company). Really, there is no need to put the gory details in writing as long as you get rid of the blanket restrictions that are in some contracts.
I sort of take it you're an American business, so firing people just because you don't like the color of their socks shouldn't be an issue. I'm always surprised to see contract wording that is so anti-employee it hurts, while the person that drafted the contract completely forgot that retaining a creative person against his/her will is entirely against the company interest in the first place.
If law were this black and white, we wouldn't have the intricate layering of appeals processes, and we wouldn't have court rulings that consist for three quarters of quotes of other judges' interpretation of the law.
And while I don't want to enter the debate on whether the outcome of the trial is defendable on legal and moral grounds, I do want to point out that both parties have themselves to blame for letting it get this far out of hand.
I've been on the corporate side of such disputes more than once, and I'm actually quite proud none of them got out of hand to the point where talking could not resolve the issue (from both ends: getting the individual to stop damaging activities, and getting the corporation to at least listen to the warning signs).
I'm very tired of hearing this argument. It is the same argument as "no one ever got fired over buying IBM". If you feel good over the ability to sue, fine, it'll make you sleep better. But I've learned to sleep well by shrugging off the repeated experience of getting screwed over by vendors who just had a better lawyer than I did when the contracts were reviewed.
And that's with vendors where you can actually negociate a contract. Microsofts market dominance means it will get away with not negociating a contract. Take the EULA or leave it.
Besides, for a successful suit you'd need to prove something like gross negligence or criminal intent. I think the chance of proving that is slim in the case of this backdoor, and that they would probably walk away with a court order mandating half off upgrades to all affected users.
The whole thing of course boils down to the nature vs nurture debate, which I'm afraid we're not going to settle on slashdot. That said, I'm not buying the argument that peer pressure is keeping kids from becoming technologists. If the urge is there (and most of us around here probably recognize that urge), it won't be repressed. Worst would be that a kid becomes a closet technologist, but the True Calling will come out one day.
The trick is either to have friends at the telco, or social engineer your way into them: "Hey, it's John from telco corporate headquarters. Just spoke with Peter at the city center CO about a problem a customer had with his line; seems you installed coils. Please do something about it".
I know an ISP that pulled this trick in the early days...
Well, of course there is the traditional killer app that can tip the balance real quickly. For example, RIPE (the European IP address agency) received a phone call one day from a cellphone operator that they needed two class A address ranges, and when could they get them?
Of course, those guys were sent back to the drawing board. But if one of the bigger handset manufacturers starts deploying IPV6 (and IPV6 is complete enough to do that right now), the balance of power would shift and a lot of folks would be forced to keep up with the Joneses.
As you say, my concern is with the infrastructure more than with client support. Microsoft has been mentioned a lot in this thread, and I would be greatly surprised if they didn't have something in the wings to at least work around lack of native IPV6 support for existing clients (like 6to4 support).
As of 4.2 BSD/OS, BSDi has awful multi-threading support (the programming interface bites). I'm not sure what you mean here. It's the plain old pthreads interface (which sort of sucks, but BSDi's implementation is stable and quite fast). There are some things it won't do, and depending on your expectations and your experiences with other implementations (which may have what you want, but blow up in other respects) that may or may not be a show stopper.
BSD/OS 4.x does not offer much in the way of thread priority, for example. Since pthreads were built on the assumption that apps should be coded to avoid contention in the first place, I'm sort of surprised that this is seen as a major problem by so many in the pthreads field (but it is seen as a problem, and not just by people who run into contention because they misdesigned their app).
The major claim to fame BSDi has when it comes to SMP is the clean system setup. One single kernel will run in pre-SMP IRQ mode, in single CPU APIC mode, or in multi CPU mode, switchable at run time, which makes for excellent troubleshooting. If you compare this to FreeBSD, where a kernel built for APIC mode won't even boot on a single CPU system, that's quite a difference.
The major claim to fame BSDi has in general over FreeBSD is the patch system. With the possible exception of the debian potato release, I know of no other Unix like system that is so easy to keep stable if you prefer a stable system to a bleeding edge system. This of course is also BSD/OS's drawback in some peoples minds, because living on the bleeding edge with BSDi means you'll have to do some manual jiggery pokery to make the bits you tack on coexist with what BSDi provides. To me that's a small price to be paid, but if you're in a hurry it can be annoying.
The horrible things you said about the BSDI shared libraries in the 2.x and 3.x time frames are accurate but there were worse problems (e.g., a hard to fix dependance on argv[0] not changing to make dlsym work) that prompted the replacement. Once again, it's a trade-off, and I valued the stability and performance over the problems (but I jumped at 4.x just to get rid of them). To each his dentifrice, as Opus said.
As to the original topic of the big BSDi contributions to FreeBSD, well, I'm waiting but not holding my breath. It's not unwillingness on BSDi's part, but there's only so many hours in a day... These days, my company spends its dollars on both the excellent, stable and dull BSD/OS, and the cheap, fast and up to date FreeBSD (oh, and we're also running Linux, Solaris and NT where it makes the most sense -- please don't roast me about the NT part, it was not my choice). The total license cost is negligable compared to the man-hours, and that's where we optimize.
That said, I think this daemon is cool... Bit expensive, but... Where's that credit card... Zirconium plated, please... Hold the bun.
At least with these old devices, there was printed documentation. These days, it's all .PDF (if docs exist in the first place), and my hopes are not high on retrieving them if a modern device goes out of production. The number of times I've run into the situation that you count on being able to retrieve something from a bookmark, only to find the document is no longer there, and conversely, that I find myself with an archive of .pdf's that I've got not clue of what it's all about, and what it's status is...
Blank page.
As it turns out, the JavaScript code checked for IE or NS on MacPPC or Win32. If you run NS on BSD/OS, they don't want to do business with you. Neither do they care about Amiga, Mac68K, Linux, WAP phones, well, anything they never heard of...
Every three months they change the website, and every time I run into this, I point it out to them (at first to the webmasters, later to their PHB's). They usually fix it a few days after I report it, but they invariably screw it up when they bring a new site online and they fail to see that it's the kewl scripting that's the problem, not my browser.
I don't care how the site looks. I want to buy an airline ticket. This concept is one I have not been able to get across, and they will not acknowledge it's their problem. Sometimes I can vote with my feet, sometimes I can't: that's my biggest frustration.
- There is little code available
- What's in there is hard to find
To be useful in this respect, it needs to have many more entries, and the categorization needs to be improved (and inappropriate entries purged, etcetera). Sort of like the patent database, actuallyThat said, it's a cool idea and I always check the snippet library when I notice I'm reinventing a wheel.
This is true. However, even better is to have a good API to access to access kernel data. sysctl is unfortunately not widely advertised enough, which means that SNMP daemons like UCD-SNMP have not been fully converted over yet. The sysctl interface offers the well-definedness of /proc with the speed of kmem grovelling (and like /proc, it doesn't require privileges for read access unless you are trying to read privileged data).
Reading /proc is easier for scripts, but I hate having to redo all the structs that are already defined in system headers and writing code to fill them in. And for some reason (I've never quite figured out why), /proc seems more prone to write kernel code for.
My main dislike for /proc stems from a philosophical standpoint, which is that the kernel has no business with providing a user friendly interface -- that's what userland is for, but I'll happily sidestep such philosphical issues if they are shown to be overshadowed by other advantages.
For completenesses sake, the main advantage of kmem grovelling is that it also works on kernel coredumps. To me, it still leaves me in awe to run netstat or ps on a kernel coredump and be able to tell exactly what was going on at the time of the crash.
If you want to see what the US doesn't want you to see, you can always go to terraserver. My home isn't visible, but all the army bases are...
The hardest part of porting something as complex as Plex86 to a different OS is figuring out where to start. Just comparing the kernel modules for Linux and NetBSD will teach you a wealth of knowledge, and for the small but important details in the non-kernel bits, grepping for __NetBSD__ tells you where to start your port. After that, it is a small issue of coding and debugging.
It's not just about more eyeballs or exposing bugs in the primary development platform, it's also about lowering the barrier for other ports, which can accelerate the eyeballs effect.
The challenge of course is spending the money -- wisely. BSDi has a fairly small core of Really Good engineers, and they are obviously going to hire. That of course is a challenge in the current, still overheated, market.
However, important details like who owns a blob of memory take a more than disproportionate amount of time in understanding the Mozilla code. Feel free to take this particular comment as a gripe about either C++ or Mozilla.
My most important gripe about C++ is not the language itself, it's its support on UNIX. GDB just plain sucks when debugging C++ code, where it does an acceptable job on debugging C.
I sincerely doubt the "reduction" of several thousand C calls to a hundred C++ classes makes the thing easier to debug. Remember the "seven, plus or minus two" rule from cognitive psychology. C++ is supposed to make this issue better, by reducing the amount of bookkeeping to enable the developer to focus on functionality. Guess what? Most C routines I've debugged in the old code base required fewer things to jot down than the C++ classes in the new code base have -- precisely because the combination of data hiding and the ability to corrupt memory easily co-exist in the same language.
In an ideal world, memory corruption (beyond algorithmical corruption) would not exist, and debugging would be easier with an OO language. C++ doesn't offer this, and as a result, debugging it is more complicated than debugging C. I'm not talking about simple, algorithmical bugs -- those are easy to track down in C++, but those are not showstoppers either. It's the hard bugs, the one that take down the app, which are much harder to debug in C++ than in C.
As to being realistic, sure, do you think I'd even be on /. if my blood pressure wasn't A-OK?
When I looked at the plex86 kernel module, I noticed little in the way of providing documentation about assumptions made about this particular kernel/"application" interface, and with the vivid Wine memory made me think twice about trying to port the kernel interface to either of FreeBSD or BSD/OS, my two main platforms.
Am I overlooking some docs, or does this issue need addressing?
Also, performance is next to irrelevant in my book, and I'm wondering what the focus on plex86 will do to the Bochs emulator, which works fairly well on BSD/OS, but again doubts on it's future have kept me from firing up gdb and trying to find the fixes that would make it work for me -- it doesn't itch quite hard enough at the moment to justify sinking time into, considering its unknown fate. It'd be really kewl if plex86 would have an emulation mode that makes the plex86/bochs distinction obsolete. Again, am I overlooking the obvious?
Death of FreeBSD predicted. Film at eleven.
Still, if they pull it off it's be a cool gizmo. It would reduce the shelf space for an MSDN subscription significantly. Besides, if you use them as frisbees they don't have enough mass to poke someones eye out.
But I still think it is a pity that people insist HTML should be a powerful page layout tool. TeX is pretty anal in its requirement that page layout be predictable, which is cool for paper documents but way uncool for web pages. When I resize my web browser to show a long, narrow page, I'd appreciate it if the text flowed in such a way that the page would still be legible. This is already broken in a lot of web pages that insist on specifying table widths in pixels or using images to enforce a certain size, but TeX is even more inflexible in allowing the user to determine what his screen should look like.
Putting the user in control was one of the advantages of HTML in the old days. These days, one is glad if windows full of ads aren't popping up left, right and center, and obviously there must be someone around who thinks that is somehow a good idea...
Point taken anyway. I shouldn't extrapolate experiences with Dutch fast food franchises into a world wide view.
Of course, this was in a friendly network setting, mostly TCP and no way for abusers to hide from the network managers.
And this was the easy case, prioritizing TCP. The problem with UDP is that it has no inherent flow control mechanism. Stuff like RealAudio has its own heuristics to avoid overloading a line, but as heuristics go, the time to respond to changing conditions is quite noticable, and because UDP doesn't back off by itself, in the mean time the link is loaded with packets that don't reach their final destination in the first place. On overloaded Frame Relay circuits, it is not unusual to see 50% of traffic consisting of TCP retransmits, and in those cases, tuning the rate down can actually improve performance. I don't want to know what happens to VoIP in those circumstances...
VoIP really hinges on the availability of fat pipes. They're cheap in the US and parts of Europe and Asia, but try getting a reliable circuit in South Africa...