Setting up open wireless networks that don't connect to the Internet is somewhat anti-social: people may get confused about their network settings or their laptops may connect to the first available network (yours) and then not be able to get out.
If you want a geographic community, why not just give out access cards with a password in person at your place? That way, your population will be local, but you can use a more standard setup. And when your local friend travel, they can still check in over the Internet.
You can say the same thing about NetBSD. But frankly, who cares? You're talking about a wristwatch! No one cares what OS is on a wristwatch. Frankly, an Unix-like OS on a wristwatch is pretty strange to begin with. It's not like it has a shell or any other environment to interact with.
Quite to the contrary: the OS matters a great deal. With Linux running your wrist watch (it's actually a PDA in a wrist watch package) or phone, you can reuse tons of software. And shells are enormously important on those tiny devices because you can connect to them easily (serial port, network) and actually debug and work on them.
But if you don't own a Z Series mainframe, who the hell cares? For 999 out of 1000 Linux users, Linux on a mainframe VM is nothing more than a bragging point. There's nothing wrong with bragging, but it's not a strike against any other operating system.
It's more than a bragging point. The fact that when I start a business, I know that people have demonstrated that Linux works well on big iron means that I know I can get that capability when my business has grown to the point where I need it. If a system hasn't demonstrated that, I know that it's not available and that I would have to switch.
Mainframes are only one example of that. When I go with Linux, I can be pretty certain that someone will have made it work on just about any hardware.
Again, things would be different if FreeBSD had some truly compelling technical advantage, but the two kernels really aren't all that different, so Linux wins in real life because of those practical advantages.
You don't specifically need "six stereoscopic camera pairs" or "180 x 180 LED arrays". What you need is some kind of camera that can model the 3D scene reasonably well (there are many different designs known), and some kind of decent 3D display (it doesn't have to be 180 x 180 LED arrays behind a hemispherical lens, and probably won't be).
In different words, you just need improvements that people are already making any way in 3D cameras and 3D displays. Give it another 10-20 years, and making an "invisibility cloak" or "invisible wall" will be as simple as hooking about a 3D camera to a 3D display, just like today, you may hook up a 2D camera to a 2D display.
IBM has demonstrated them. Linux is also used in cell phones and many other embedded devices. Linux on small devices isn't a gimmick, it is widely used.
But as far as I can tell, only IBM ever bothered to put Linux on a mainframe anyway. So it's a pointless argument.
What is "pointless" about IBM delivering a Linux environment to their customers for some of the biggest mainframes in the world? Again, Linux on mainframes is not a gimmick, it's a real and important product.
There is no reason why FreeBSD couldn't be put on a big-iron mainframe.
You're right: there is no reason why it couldn't be. But the fact is: it hasn't been. Among the glut of interchangeable big, monolithic, C-based kernels with UNIX-like APIs, people have to pick something when they need a kernel, and they happen to pick Linux by default.
If FreeBSD actually offered some ground-breaking advantage, people might switch, but merely being "as good as" or even "slight better than" is not compelling enough. If an OS developer wants to lure people away from Linux and Windows NT, they have to do a lot better than either, and so far, nobody has. Put on your thinking cap.
If that patent gets granted, it only goes to show that the USPTO doesn't know what they are doing. The idea itself is old and that "inventor" has contributed nothing to the hard part of making it work.
In about 10-20 years, the hardware to make real invisibility cloaks will be ready, as part of better camera and 3D display technologies. Then, people will be able to build these things with satisfactory performance.
The only benefit of having the patent issued to that guy is that if the development of that display technology takes about 20 years, then his patent will have expired and nobody else will be able to patent the same stupid, obvious, and old idea. But in a well-run patent office, such applications should be rejected as soon as they are submitted.
Yes, you could, in principle. And people are working on those kinds of display technologies, not for making invisibility cloaks, but for general purpose 3D displays. Once you have a good 3D display technology that can be applied to flexible surfaces, you can start doing these kinds of things.
However, such displays are not practical yet, so all you get for now is people playing around with projectors. You can be that as soon as the display technology is there, however, it will be applied to "invisibility cloaks" right away. Give it another decade or two.
I really don't get why this is receiving so much coverage.
The "invisibility cloak" is an old idea (and, no, it's not just this guy's old idea); the difficult part is making it work well, and the guys from U. Tokyo haven't done that. They have done a little to improve things by using different materials to project on ("retro-reflectium"), but that is not sufficient.
And their approach to making "walls invisible" amounts to hooking up a web cam to a projector.
Geez, the threshold for calling something a "new technology" seems to be getting lower and lower.
Yet it only became popular in the last decade. Remember, Sun was a *workstation* company before the mid-1990s. The big-ass UNIX servers we see today really are a fairly recent development--before them were the mainframes. I think it is fair to say that SMP really is only recently proven, regardless of how long various implementations existed.
Mainframes had symmetric multiprocessing going back to the 1960's (!).
And "popularity" is not a useful concept for measuring when something has succeeded in the computer world: because of the spectacular growth of the computer industry, almost any feature you can name has become popular only in the last decade.
However, in terms of fraction of total installed machines, I suspect there may have been more SMP machines in the 1960's than there are today.
traditional media
on
Meet Joe Blog
·
· Score: 3, Funny
Why are more and more people getting their news from amateur websites called blogs? Because they're fast, funny and totally biased
Well, then they have one of the three in common with traditional media, and it isn't being either fast or funny.
Now that a lot of SMP technology has matured and proven its worth
You've got to be kidding: "SMP technology" proved its worth decades ago.
OpenBSD philosophy is to do it and do it well make absolutely sure that it is secure.
By itself, a concern over security does not mean that you have long time-to-market for a product. It is possible to implement secure software systems rapidly, but you have to give up on other things (like, for example, an insistence on manual storage management and raw pointer manipulation).
The degree to which OpenBSD's tradeoffs are desired by the market becomes clear from how widely it is used--and I don't mean that cynically: OpenBSD fulfills a significant function for a small market, but most people choose something else. It's good that we have choices like OpenBSD, even if most people choose not to use it.
The IM infrastructure, whether text, voice, or video, should never have become centralized--there is no technical reason for it. And companies like AOL and Microsoft have been poor stewards of the IM infrastructure they have created anyway.
As long as it was "free", it didn't matter much to most people. Now that they have to pay, hopefully they will have an incentive to move to decentralized, non-proprietary systems, and IM will become what it should have been since the start.
As long as Palm keep shipping the same old stuff, why should people upgrade? A Palm from 2004 isn't all that much more useful than a Palm from four years ago: it runs basically the same PIM applications and still has most of the same limitations. Screens have gotten a little better, but a 320x320 screen doesn't really display any more information (even Palm's own applications don't handle smaller fonts correctly), and many applications don't support the 320x480 screens. It's also not really surprising that people haven't come up with new killer apps for the Palm--if you spend fighting with the OS and supporting a dozen different versions, they don't have time.
Internet and phone connectivity are such a pain to figure out on most models, too, that people don't use PDAs for that. They probably don't prefer the bulky phone-PDA combos, but it's the only thing they can get to work.
I suspect the situation is not much different with PocketPC.
Once PDA manufacturers figure out how to do a better job on the OS and libraries, then the PDA market will pick up again.
If you are on VMS, the "best" scripting language may be DCL (or whatever it was called). On Windows, it may be VBscript or Perl. If you write numerical code, it may be Matlab. If you write visualization code, it may be Python with VTK libraries. Etc.
The whole point of scripting languages is that they are well-adapted to their application domain--different domain, different winner.
If you try to develop "general purpose scripting languages", all you are doing is developing a poor implementation of a general-purpose dynamic language (Lisp, Smalltalk, etc.).
Fortunately I have better things to do than participate in the mindless cloning of products merely to extend Microsoft's mindshare in the development community.
Mono isn't "mindless cloning", since the most important part of it is the development of a fully open source set of C# APIs--a better set of APIs than either.NET or Java provide.
[If you want a legal opinion, go pay for it.] I guess you offer the same advice to all prospective users of "your" platform?
I give the same advice to anybody who wants a well-founded legal opinion.
In fact, if you are a Java user, I strongly recommend you get a well-founded legal opinion about the Java licenses, since Java is heavily patent and IP encumbered. If you are worried about Microsoft suing independent implementors of ECMA C#, go ask your lawyer about the possibility of Sun suing independent implementors of Java and the (I claim) non-existent protection and guarantees such implementors have from Sun.
[Furthermore, Microsoft has publicly stated that it is their intention that people can implement ECMA C# (which includes a lot of.NET libraries) freely.] So you do make a coy little promise of free Dotnet.
And your point is what? ECMA C# is standardized. ECMA C# shares hundreds of classes with what Microsoft separately calls ".NET". Those statements are both correct. They don't imply that ".NET as a whole" is standardized.
But of course you had to - after all the platform would offer virtually zero portablity without the main libraries, right?
Wrong. The standard library included in ECMA C# is extensive and lets you write portable code if you choose. That level of portability is very useful for writing libraries that work across platforms. However, for applications, most developers choose to go beyond it.
You are still living under the misconception that people want cross-platform portability and that therefore mentioning.NET is some kind of attempt to trick people into getting some benefit that they don't get. But most people who use C# don't view cross-platform portability as a benefit; their (my) statement that Mono supports.NET (which it does) is just a statement of fact, not an inducement; I have made it clear that I actually think you shouldn't use those parts of.NET that go beyond ECMA C# and instead use the OSS-based libraries with C#.
Note that if you actually need cross-platform capabilities, both the.NET and the Gnome-based environments provide it: using Mono's.NET clone, you can run.NET applications on Linux, and using the Gnome port to Windows, you can run Gnome/C# applications on Windows, and both of those work at least as well as Swing (which is really a pretty shitty cross-platform library). Furthermore, there are C# bindings to wxWindows and Qt, which also let you write cross-platform applications. And there will doubtlessly be pure ECMA C# GUI toolkits analogous to Swing (although, hopefully, better designed). But all of those cross-platform capabilities are a side-show for Mono. Most C# applications will be developed using.NET libraries for Windows and using Gnome libraries for Linux, with no intent or desire to port them to other platforms.
Wonder if we'll ever see the day when a Mono proponent comes clean and makes a clear distinction between language and libraries.
That would be a useless distinction since nobody implements just the C# language. The important distinction is between ECMA C# (C# and its standard library), the.NET-specific APIs (all of Microsoft's published APIs minus what is in ECMA C#), and the Gnome/OSS-based Mono APIs. Of those, most OSS developers use ECMA C# and the Gnome/OSS-based Mono APIs. The Mono project is quite clear about this distinction.
Which "Mono lawyers" and what review are you referring to? Have these findings been made public?
The Mono project is public. If you participated or at least followed it, instead of badmouthing the project from a state of ignorance, you'd know the status of the review (and, no, the review isn't complete, but they haven't come up with anything related to ECMA C#).
If not, on whose authority are you asserting that Dotnet is unthreatened by patents?
You seem to have trouble distinguishing authoritative legal opinions and general discussions. If you want a legal opinion, go pay for it.
And I never asserted that "Dotnet" (whatever you may be referring to) is "unthreatened by patents" anyway. I made a statement specifically about ECMA C# and Microsoft patents. The relationship between ECMA C# and Microsoft's patent portfolio has probably been looked into in more detail than any other platform, and nobody has found a smoking gun.
No you didn't say that Dotnet was a standardized platform, you implied it by stating that C Sharp "includes a lot of.NET libraries".
That's an idiotic inference by you. What is standardized about C# is obviously ECMA C#. I neither stated nor implied anything more.
Be aware that Mono proponents have a lot of "previous" regarding this particular bait-and-switch manoeuvre so anyone still trying it on is likely to be quickly "apprehended".
There is no "bait and switch". The Mono project does three things: it is developing an ECMA C# implementation, it is developing a.NET implementation, and it is developing a completely independent stack of open source libraries and bindings. You can use whichever parts you like. Most OSS developers seem to steer clear of the.NET clone, if not for any other reason than because the Gnome APIs are simply better.
3) I have no idea what reassurance we're supposed to find from the statement that all MS IP is "out in the open". Are you implying that it is now somehow in the public domain?
No, I am stating that patents and patent applications are published by the USPTO. Therefore, we don't have to guess what patents Microsoft held or had applied for in 2002, we can just look.
It seems to me rather cavalier to assume that MS will not use expensively acquired patents to protect their core platform, especially as Ballmer is on record as saying that it is precisely their intention to do so.
There is no "assumption" there, there simply are no such patents.
Yes, that is why Java is so successful, as thousands of Java apps can and do use platform specific code: Eclipse is one example.
Eclipse is an attempt by IBM to fight Sun's cross-platform idiocy, an attempt that Sun soundly condemns.
And, no, that's not why Java has achieved the modest success it has. Java became successful because it looked like the only viable response to Microsoft, but those days are over. Java is living on borrowed time.
There is nothing to stop you writing or using platform specific and native code libraries.
There are plenty of things that stop me, like a braindead, cumbersome, and inefficient JNI interface and lack of pre-existing platform-specific bindings included in the Java distribution.
C#, in contrast, gives me native Windows and Gnome bindings on the respective platforms and much easier and much more efficient use of native code and native data.
Yes: it leads to the kind of lousy user interfaces and poor platform integration people produce in Swing/Java.
Perhaps you had better explain that to Perl, C++ and Python developers.
Those are all languages with lots of popular, platform-specific libraries.
The HP VM is clean room, and uses no Sun code, as is Kaffe, and Taurus, and Japhar, and GCC.
Stop the bullshitting. You know full well that a JVM by itself is useless. You know full well that none of the independent implementations have ever passed certification as implementations of the standard-edition Java 2 platform. Dragging up that a tiny bit of the Java platform has been implemented independently when I explicitly talked about independent implementations of the Java platform is highly disingenuous of you.
As if companies such as Oracle, IBM and HP, who are major competitors of Sun would join a process which was not independent and open.
Those companies made a commitment to supporting Java long before Sun created the current mess, when Sun was still pretending that Java was going to be submitted to an independent standards body; those companies can't easily go back on that commitment at this point, given how much their customers have invested in it. And for IBM to start projects like Eclipse (!), SWT, and to get into a public argument with Sun about open sourcing the platform is a slap in the face for Sun.
I'm still intrigued by people who argue that you should share the code that you and a team of 100 or so developers have spent 9-5, 5 days a week, for years on, can make business sense.
That is no more intriguing than the fact that if your competitor lowers their sales prices for an equivalent product from $100 to $50, you have to follow suit or you will not be selling a lot. And if you can't figure out how to make a profit at the lower price, you'll go out of business.
In the case of competition from OSS, your competitor's sales price has been lowered to $0. If you can't figure out how to make a profit in that kind of business environment, you'll go out of business. Quite simple.
Obviously, once the price is down to $0, you'll have to make your profit from something other than software sales, like associated hardware sales, custom development, associated proprietary software, support, or service. Companies like IBM seem to have figured out such a business model.
Incidentally, it's not just OSS that does this: Microsoft's free bundling of some piece of software has pretty much the same effect on competing software businesses.
You are right - its no where near, and will never be until, like Java, all aspects of.Net
That will (thankfully) never be the case, since C#/.NET isn't trying to be like Java. Unlike Java, C# developers are not yoked to a cross-platform philosophy. Just like C++, C# is used with different kinds of frameworks and libraries, many of them platform specific. And, hard as that may be for you to comprehend, many people want that.
Java is controlled by the Java Community Process (JCP). Changes to Java are submitted to the process and voted on. There are no lawyers and no disproportionate benefit.
The fact that Sun, rather than an independent body, actually owns many (all?) of the JCP documents alone proves you wrong (check the copyright notices). Sun also controls the determination of whether third party implementations conform to the specfications or not. And Sun holds many patents that are necessary to practice implementations of the JCP.
Furthermore, even if those legal obstacles didn't exist, since all implementations of the Java platform rely on code licensed from Sun, Sun is ultimately the primary beneficiary of any enhancements to Java; there are no independent third party implementations of the Java platform.
Basically, the notion that the JCP is an open or independent process is laughable.
Did they ask Steve Ballmer? Here's what he said in 2002:
We don't have to guess what patents or patent applications Microsoft had in 2002 because they are public by now; that is exactly what the Mono lawyers looked at. And when you look at that set of patents and patent applications, you'll see that Ballmer was either wrong or lying.
So, in light of the fact that this is an issue that has a clear answer, why do people like you keep talking about non-existent patents threatening open source C# efforts? What is your agenda?
For the record, Dotnet consists of approximately 1200 APIs (classes) of which 120 were "standardized" as part of C Sharp and the CLR. Not by any stretch of the imagination can Dotnet constitute a standardized platform.
Why are you putting words in my mouth? I didn't claim that "Dotnet" was a "standardized platform"--it clearly hasn't been standardized. I said that "C# is simply a decent language and runtime that has an open standard and has received extensive legal scrutiny." C# is not.NET.
(In fact, I expect most open source work in C# won't use anything other than ECMA C# plus bindings to open source libraries like Gnome--.NET is irrelevant to most non-Windows developers.)
this statement has been repeated and immediately refuted so often on/. one really has to question the motives of someone still making it
The statement has not been "refuted"; Microsoft representatives have, at times, stated that as Microsoft's intent. Maybe Microsoft is lying or maybe they are confused or maybe they will change, but those are always possibilities with any company. But, as I was saying, legally, it doesn't matter whether what they said is what they intended because, by now, all the relevant intellectual property is out in the open. What they said is just another "FYI".
But trying to withdraw a PhD sends a misleading message about what a PhD means. It's a certification of having fulfilled certain requirements, not a grant of endorsement. We cannot pretend to alter the past, and say someone did not accomplish what they did,
The article didn't state whether the Ph.D. was revoked for post-Ph.D. conduct or whether his Ph.D. data itself is also in question.
But even if his Ph.D. data is not in question, the university could still argue that his subsequent conduct showed that he was never qualified in the first place, they just happened to miss that fact. Kind of like if they discovered after the fact that he missed a couple of required courses. It seems to me it's at least a defensible argument.
The same way your citizenship or your driver's license can be "revoked" if you obtained them through fraud--you never really had them in the first place.
If we go down this path, we are quickly descending a path whereby many PhD's could be revoked using thin evidence. Do we really want to head down the slippery slope?
Faculty really have better things to do than to sit on committees to try to revoke Ph.D.'s, not to mention the PR backlash and harm to the university should they try to do it in anything other than absolutely clearcut cases. This sort of thing only happens when there is no other choice.
If the University cannot find anything wrong with his work for his graduate program and doctorate research, then I don't believe they should take away something he earned.
The Ph.D. is a statement that you are qualified to do scientific research. Schoen has demonstrated that he isn't, and therefore, one can argue that his Ph.D. was awarded in error.
Whether he actually falsified data on his Ph.D. or not is secondary to that analysis: even if he didn't falsify data in his Ph.D., he still has demonstrated retroactively that he is not qualified.
Also, think of it this way: if you were a graduate from the same university, would you like to have this guy run around with credentials from your university? Why should he be able to?
(In any case, as others have pointed out, it seems like data on his Ph.D. was at least questionable, so this discussion is hypothetical.)
Slashdot Mirror
Setting up open wireless networks that don't connect to the Internet is somewhat anti-social: people may get confused about their network settings or their laptops may connect to the first available network (yours) and then not be able to get out.
If you want a geographic community, why not just give out access cards with a password in person at your place? That way, your population will be local, but you can use a more standard setup. And when your local friend travel, they can still check in over the Internet.
You can say the same thing about NetBSD. But frankly, who cares? You're talking about a wristwatch! No one cares what OS is on a wristwatch. Frankly, an Unix-like OS on a wristwatch is pretty strange to begin with. It's not like it has a shell or any other environment to interact with.
Quite to the contrary: the OS matters a great deal. With Linux running your wrist watch (it's actually a PDA in a wrist watch package) or phone, you can reuse tons of software. And shells are enormously important on those tiny devices because you can connect to them easily (serial port, network) and actually debug and work on them.
But if you don't own a Z Series mainframe, who the hell cares? For 999 out of 1000 Linux users, Linux on a mainframe VM is nothing more than a bragging point. There's nothing wrong with bragging, but it's not a strike against any other operating system.
It's more than a bragging point. The fact that when I start a business, I know that people have demonstrated that Linux works well on big iron means that I know I can get that capability when my business has grown to the point where I need it. If a system hasn't demonstrated that, I know that it's not available and that I would have to switch.
Mainframes are only one example of that. When I go with Linux, I can be pretty certain that someone will have made it work on just about any hardware.
Again, things would be different if FreeBSD had some truly compelling technical advantage, but the two kernels really aren't all that different, so Linux wins in real life because of those practical advantages.
You don't specifically need "six stereoscopic camera pairs" or "180 x 180 LED arrays". What you need is some kind of camera that can model the 3D scene reasonably well (there are many different designs known), and some kind of decent 3D display (it doesn't have to be 180 x 180 LED arrays behind a hemispherical lens, and probably won't be).
In different words, you just need improvements that people are already making any way in 3D cameras and 3D displays. Give it another 10-20 years, and making an "invisibility cloak" or "invisible wall" will be as simple as hooking about a 3D camera to a 3D display, just like today, you may hook up a 2D camera to a 2D display.
I haven't seen any Linux wristwatches.
IBM has demonstrated them. Linux is also used in cell phones and many other embedded devices. Linux on small devices isn't a gimmick, it is widely used.
But as far as I can tell, only IBM ever bothered to put Linux on a mainframe anyway. So it's a pointless argument.
What is "pointless" about IBM delivering a Linux environment to their customers for some of the biggest mainframes in the world? Again, Linux on mainframes is not a gimmick, it's a real and important product.
There is no reason why FreeBSD couldn't be put on a big-iron mainframe.
You're right: there is no reason why it couldn't be. But the fact is: it hasn't been. Among the glut of interchangeable big, monolithic, C-based kernels with UNIX-like APIs, people have to pick something when they need a kernel, and they happen to pick Linux by default.
If FreeBSD actually offered some ground-breaking advantage, people might switch, but merely being "as good as" or even "slight better than" is not compelling enough. If an OS developer wants to lure people away from Linux and Windows NT, they have to do a lot better than either, and so far, nobody has. Put on your thinking cap.
If that patent gets granted, it only goes to show that the USPTO doesn't know what they are doing. The idea itself is old and that "inventor" has contributed nothing to the hard part of making it work.
In about 10-20 years, the hardware to make real invisibility cloaks will be ready, as part of better camera and 3D display technologies. Then, people will be able to build these things with satisfactory performance.
The only benefit of having the patent issued to that guy is that if the development of that display technology takes about 20 years, then his patent will have expired and nobody else will be able to patent the same stupid, obvious, and old idea. But in a well-run patent office, such applications should be rejected as soon as they are submitted.
Yes, you could, in principle. And people are working on those kinds of display technologies, not for making invisibility cloaks, but for general purpose 3D displays. Once you have a good 3D display technology that can be applied to flexible surfaces, you can start doing these kinds of things.
However, such displays are not practical yet, so all you get for now is people playing around with projectors. You can be that as soon as the display technology is there, however, it will be applied to "invisibility cloaks" right away. Give it another decade or two.
I really don't get why this is receiving so much coverage.
The "invisibility cloak" is an old idea (and, no, it's not just this guy's old idea); the difficult part is making it work well, and the guys from U. Tokyo haven't done that. They have done a little to improve things by using different materials to project on ("retro-reflectium"), but that is not sufficient.
And their approach to making "walls invisible" amounts to hooking up a web cam to a projector.
Geez, the threshold for calling something a "new technology" seems to be getting lower and lower.
Yet it only became popular in the last decade. Remember, Sun was a *workstation* company before the mid-1990s. The big-ass UNIX servers we see today really are a fairly recent development--before them were the mainframes. I think it is fair to say that SMP really is only recently proven, regardless of how long various implementations existed.
Mainframes had symmetric multiprocessing going back to the 1960's (!).
And "popularity" is not a useful concept for measuring when something has succeeded in the computer world: because of the spectacular growth of the computer industry, almost any feature you can name has become popular only in the last decade.
However, in terms of fraction of total installed machines, I suspect there may have been more SMP machines in the 1960's than there are today.
Why are more and more people getting their news from amateur websites called blogs? Because they're fast, funny and totally biased
Well, then they have one of the three in common with traditional media, and it isn't being either fast or funny.
But why hasn't FreeBSD become as widespread as Linux? The answers may lie in its history.
That's roughly like asking: why do people eat less chocolate than they eat potatoes?
The answer is not history, it's that they are different kinds of "products" with different strengths and weaknesses.
Now that a lot of SMP technology has matured and proven its worth
You've got to be kidding: "SMP technology" proved its worth decades ago.
OpenBSD philosophy is to do it and do it well make absolutely sure that it is secure.
By itself, a concern over security does not mean that you have long time-to-market for a product. It is possible to implement secure software systems rapidly, but you have to give up on other things (like, for example, an insistence on manual storage management and raw pointer manipulation).
The degree to which OpenBSD's tradeoffs are desired by the market becomes clear from how widely it is used--and I don't mean that cynically: OpenBSD fulfills a significant function for a small market, but most people choose something else. It's good that we have choices like OpenBSD, even if most people choose not to use it.
The IM infrastructure, whether text, voice, or video, should never have become centralized--there is no technical reason for it. And companies like AOL and Microsoft have been poor stewards of the IM infrastructure they have created anyway.
As long as it was "free", it didn't matter much to most people. Now that they have to pay, hopefully they will have an incentive to move to decentralized, non-proprietary systems, and IM will become what it should have been since the start.
As long as Palm keep shipping the same old stuff, why should people upgrade? A Palm from 2004 isn't all that much more useful than a Palm from four years ago: it runs basically the same PIM applications and still has most of the same limitations. Screens have gotten a little better, but a 320x320 screen doesn't really display any more information (even Palm's own applications don't handle smaller fonts correctly), and many applications don't support the 320x480 screens. It's also not really surprising that people haven't come up with new killer apps for the Palm--if you spend fighting with the OS and supporting a dozen different versions, they don't have time.
Internet and phone connectivity are such a pain to figure out on most models, too, that people don't use PDAs for that. They probably don't prefer the bulky phone-PDA combos, but it's the only thing they can get to work.
I suspect the situation is not much different with PocketPC.
Once PDA manufacturers figure out how to do a better job on the OS and libraries, then the PDA market will pick up again.
If you are on VMS, the "best" scripting language may be DCL (or whatever it was called). On Windows, it may be VBscript or Perl. If you write numerical code, it may be Matlab. If you write visualization code, it may be Python with VTK libraries. Etc.
The whole point of scripting languages is that they are well-adapted to their application domain--different domain, different winner.
If you try to develop "general purpose scripting languages", all you are doing is developing a poor implementation of a general-purpose dynamic language (Lisp, Smalltalk, etc.).
Fortunately I have better things to do than participate in the mindless cloning of products merely to extend Microsoft's mindshare in the development community.
.NET or Java provide.
.NET libraries) freely.] So you do make a coy little promise of free Dotnet.
.NET is some kind of attempt to trick people into getting some benefit that they don't get. But most people who use C# don't view cross-platform portability as a benefit; their (my) statement that Mono supports .NET (which it does) is just a statement of fact, not an inducement; I have made it clear that I actually think you shouldn't use those parts of .NET that go beyond ECMA C# and instead use the OSS-based libraries with C#.
.NET and the Gnome-based environments provide it: using Mono's .NET clone, you can run .NET applications on Linux, and using the Gnome port to Windows, you can run Gnome/C# applications on Windows, and both of those work at least as well as Swing (which is really a pretty shitty cross-platform library). Furthermore, there are C# bindings to wxWindows and Qt, which also let you write cross-platform applications. And there will doubtlessly be pure ECMA C# GUI toolkits analogous to Swing (although, hopefully, better designed). But all of those cross-platform capabilities are a side-show for Mono. Most C# applications will be developed using .NET libraries for Windows and using Gnome libraries for Linux, with no intent or desire to port them to other platforms.
.NET-specific APIs (all of Microsoft's published APIs minus what is in ECMA C#), and the Gnome/OSS-based Mono APIs. Of those, most OSS developers use ECMA C# and the Gnome/OSS-based Mono APIs. The Mono project is quite clear about this distinction.
Mono isn't "mindless cloning", since the most important part of it is the development of a fully open source set of C# APIs--a better set of APIs than either
[If you want a legal opinion, go pay for it.] I guess you offer the same advice to all prospective users of "your" platform?
I give the same advice to anybody who wants a well-founded legal opinion.
In fact, if you are a Java user, I strongly recommend you get a well-founded legal opinion about the Java licenses, since Java is heavily patent and IP encumbered. If you are worried about Microsoft suing independent implementors of ECMA C#, go ask your lawyer about the possibility of Sun suing independent implementors of Java and the (I claim) non-existent protection and guarantees such implementors have from Sun.
[Furthermore, Microsoft has publicly stated that it is their intention that people can implement ECMA C# (which includes a lot of
And your point is what? ECMA C# is standardized. ECMA C# shares hundreds of classes with what Microsoft separately calls ".NET". Those statements are both correct. They don't imply that ".NET as a whole" is standardized.
But of course you had to - after all the platform would offer virtually zero portablity without the main libraries, right?
Wrong. The standard library included in ECMA C# is extensive and lets you write portable code if you choose. That level of portability is very useful for writing libraries that work across platforms. However, for applications, most developers choose to go beyond it.
You are still living under the misconception that people want cross-platform portability and that therefore mentioning
Note that if you actually need cross-platform capabilities, both the
Wonder if we'll ever see the day when a Mono proponent comes clean and makes a clear distinction between language and libraries.
That would be a useless distinction since nobody implements just the C# language. The important distinction is between ECMA C# (C# and its standard library), the
Perhaps with your Java blinders, the di
Which "Mono lawyers" and what review are you referring to? Have these findings been made public?
.NET libraries".
.NET implementation, and it is developing a completely independent stack of open source libraries and bindings. You can use whichever parts you like. Most OSS developers seem to steer clear of the .NET clone, if not for any other reason than because the Gnome APIs are simply better.
The Mono project is public. If you participated or at least followed it, instead of badmouthing the project from a state of ignorance, you'd know the status of the review (and, no, the review isn't complete, but they haven't come up with anything related to ECMA C#).
If not, on whose authority are you asserting that Dotnet is unthreatened by patents?
You seem to have trouble distinguishing authoritative legal opinions and general discussions. If you want a legal opinion, go pay for it.
And I never asserted that "Dotnet" (whatever you may be referring to) is "unthreatened by patents" anyway. I made a statement specifically about ECMA C# and Microsoft patents. The relationship between ECMA C# and Microsoft's patent portfolio has probably been looked into in more detail than any other platform, and nobody has found a smoking gun.
No you didn't say that Dotnet was a standardized platform, you implied it by stating that C Sharp "includes a lot of
That's an idiotic inference by you. What is standardized about C# is obviously ECMA C#. I neither stated nor implied anything more.
Be aware that Mono proponents have a lot of "previous" regarding this particular bait-and-switch manoeuvre so anyone still trying it on is likely to be quickly "apprehended".
There is no "bait and switch". The Mono project does three things: it is developing an ECMA C# implementation, it is developing a
3) I have no idea what reassurance we're supposed to find from the statement that all MS IP is "out in the open". Are you implying that it is now somehow in the public domain?
No, I am stating that patents and patent applications are published by the USPTO. Therefore, we don't have to guess what patents Microsoft held or had applied for in 2002, we can just look.
It seems to me rather cavalier to assume that MS will not use expensively acquired patents to protect their core platform, especially as Ballmer is on record as saying that it is precisely their intention to do so.
There is no "assumption" there, there simply are no such patents.
Yes, that is why Java is so successful, as thousands of Java apps can and do use platform specific code: Eclipse is one example.
Eclipse is an attempt by IBM to fight Sun's cross-platform idiocy, an attempt that Sun soundly condemns.
And, no, that's not why Java has achieved the modest success it has. Java became successful because it looked like the only viable response to Microsoft, but those days are over. Java is living on borrowed time.
There is nothing to stop you writing or using platform specific and native code libraries.
There are plenty of things that stop me, like a braindead, cumbersome, and inefficient JNI interface and lack of pre-existing platform-specific bindings included in the Java distribution.
C#, in contrast, gives me native Windows and Gnome bindings on the respective platforms and much easier and much more efficient use of native code and native data.
So cross-platform is some kind of disadvantage?
Yes: it leads to the kind of lousy user interfaces and poor platform integration people produce in Swing/Java.
Perhaps you had better explain that to Perl, C++ and Python developers.
Those are all languages with lots of popular, platform-specific libraries.
The HP VM is clean room, and uses no Sun code, as is Kaffe, and Taurus, and Japhar, and GCC.
Stop the bullshitting. You know full well that a JVM by itself is useless. You know full well that none of the independent implementations have ever passed certification as implementations of the standard-edition Java 2 platform. Dragging up that a tiny bit of the Java platform has been implemented independently when I explicitly talked about independent implementations of the Java platform is highly disingenuous of you.
As if companies such as Oracle, IBM and HP, who are major competitors of Sun would join a process which was not independent and open.
Those companies made a commitment to supporting Java long before Sun created the current mess, when Sun was still pretending that Java was going to be submitted to an independent standards body; those companies can't easily go back on that commitment at this point, given how much their customers have invested in it. And for IBM to start projects like Eclipse (!), SWT, and to get into a public argument with Sun about open sourcing the platform is a slap in the face for Sun.
I'm still intrigued by people who argue that you should share the code that you and a team of 100 or so developers have spent 9-5, 5 days a week, for years on, can make business sense.
That is no more intriguing than the fact that if your competitor lowers their sales prices for an equivalent product from $100 to $50, you have to follow suit or you will not be selling a lot. And if you can't figure out how to make a profit at the lower price, you'll go out of business.
In the case of competition from OSS, your competitor's sales price has been lowered to $0. If you can't figure out how to make a profit in that kind of business environment, you'll go out of business. Quite simple.
Obviously, once the price is down to $0, you'll have to make your profit from something other than software sales, like associated hardware sales, custom development, associated proprietary software, support, or service. Companies like IBM seem to have figured out such a business model.
Incidentally, it's not just OSS that does this: Microsoft's free bundling of some piece of software has pretty much the same effect on competing software businesses.
You are right - its no where near, and will never be until, like Java, all aspects of .Net
That will (thankfully) never be the case, since C#/.NET isn't trying to be like Java. Unlike Java, C# developers are not yoked to a cross-platform philosophy. Just like C++, C# is used with different kinds of frameworks and libraries, many of them platform specific. And, hard as that may be for you to comprehend, many people want that.
Java is controlled by the Java Community Process (JCP). Changes to Java are submitted to the process and voted on. There are no lawyers and no disproportionate benefit.
The fact that Sun, rather than an independent body, actually owns many (all?) of the JCP documents alone proves you wrong (check the copyright notices). Sun also controls the determination of whether third party implementations conform to the specfications or not. And Sun holds many patents that are necessary to practice implementations of the JCP.
Furthermore, even if those legal obstacles didn't exist, since all implementations of the Java platform rely on code licensed from Sun, Sun is ultimately the primary beneficiary of any enhancements to Java; there are no independent third party implementations of the Java platform.
Basically, the notion that the JCP is an open or independent process is laughable.
Did they ask Steve Ballmer? Here's what he said in 2002:
.NET.
/. one really has to question the motives of someone still making it
We don't have to guess what patents or patent applications Microsoft had in 2002 because they are public by now; that is exactly what the Mono lawyers looked at. And when you look at that set of patents and patent applications, you'll see that Ballmer was either wrong or lying.
So, in light of the fact that this is an issue that has a clear answer, why do people like you keep talking about non-existent patents threatening open source C# efforts? What is your agenda?
For the record, Dotnet consists of approximately 1200 APIs (classes) of which 120 were "standardized" as part of C Sharp and the CLR. Not by any stretch of the imagination can Dotnet constitute a standardized platform.
Why are you putting words in my mouth? I didn't claim that "Dotnet" was a "standardized platform"--it clearly hasn't been standardized. I said that "C# is simply a decent language and runtime that has an open standard and has received extensive legal scrutiny." C# is not
(In fact, I expect most open source work in C# won't use anything other than ECMA C# plus bindings to open source libraries like Gnome--.NET is irrelevant to most non-Windows developers.)
this statement has been repeated and immediately refuted so often on
The statement has not been "refuted"; Microsoft representatives have, at times, stated that as Microsoft's intent. Maybe Microsoft is lying or maybe they are confused or maybe they will change, but those are always possibilities with any company. But, as I was saying, legally, it doesn't matter whether what they said is what they intended because, by now, all the relevant intellectual property is out in the open. What they said is just another "FYI".
But trying to withdraw a PhD sends a misleading message about what a PhD means. It's a certification of having fulfilled certain requirements, not a grant of endorsement. We cannot pretend to alter the past, and say someone did not accomplish what they did,
The article didn't state whether the Ph.D. was revoked for post-Ph.D. conduct or whether his Ph.D. data itself is also in question.
But even if his Ph.D. data is not in question, the university could still argue that his subsequent conduct showed that he was never qualified in the first place, they just happened to miss that fact. Kind of like if they discovered after the fact that he missed a couple of required courses. It seems to me it's at least a defensible argument.
it is hard to fathom that it can be "revoked."
The same way your citizenship or your driver's license can be "revoked" if you obtained them through fraud--you never really had them in the first place.
If we go down this path, we are quickly descending a path whereby many PhD's could be revoked using thin evidence. Do we really want to head down the slippery slope?
Faculty really have better things to do than to sit on committees to try to revoke Ph.D.'s, not to mention the PR backlash and harm to the university should they try to do it in anything other than absolutely clearcut cases. This sort of thing only happens when there is no other choice.
If the University cannot find anything wrong with his work for his graduate program and doctorate research, then I don't believe they should take away something he earned.
The Ph.D. is a statement that you are qualified to do scientific research. Schoen has demonstrated that he isn't, and therefore, one can argue that his Ph.D. was awarded in error.
Whether he actually falsified data on his Ph.D. or not is secondary to that analysis: even if he didn't falsify data in his Ph.D., he still has demonstrated retroactively that he is not qualified.
Also, think of it this way: if you were a graduate from the same university, would you like to have this guy run around with credentials from your university? Why should he be able to?
(In any case, as others have pointed out, it seems like data on his Ph.D. was at least questionable, so this discussion is hypothetical.)