As I read it, the patent doesn't apply to just the specific stem cell lines that were created at the University, but to all primate embyronic stem cell lines. The odd thing about the patent is that many of its claims could have been written before human stem cells were ever cultured: it describes what people wanted to achieve. It's like patenting desktop fusion or anti-gravity without telling people how to achieve it (other claims of the patent do describe methods, but those are separate claims).
This crosses another threshold in the patenting of living things. Up to now, patents have been on specific, identifiable species, cell lines, DNA sequences, or organisms, and even that has met with considerable resistance. But this patent is on any cell line that has desirable properties, whether found by these researchers or by anybody else. Another analogy is that if you discover the first apple tree, you claim a patent on any tree bearing sweet fruit.
I think society needs to think carefully about whether these kinds of patents are in the public interest. It might be defensible to let the university make claims on specific cell lines and on methods for creating those cell lines (and even that seems dubious to me), but I see no basis in patent law for the more general claims to all primate stem cell lines. If you do, maybe you can explain how you think this is justified by patent law and specifically how society benefits from such patents.
Biology makes excellent nanosystems, and it may well turn out the only way to go. However, I would keep an open mind. Biology has had only a very limited range of materials to work with, and it needs to work under a lot of oddball constraints. The cellular architecture of life, where every unit of life is almost identical and carries a complete blueprint, is convenient for biological systems, but it represents only one of many possible ways of organizing small machinery.
In fact, physicists have developed a number of techniques that let us manipulate atoms in ways that nature does not use for building complex structures. For example, STMs and lasers allow us to move single atoms. And we have found out that individual atoms and assemblies are much more stable than previously thought.
Maybe a few years ago, the SCO kernel was a bit better than the Linux kernel, but today, I see little or no advantage. In fact, Linux has better driver support and a more active user community. And being able the modify the kernel source code is useful even for end users (a quick hack to get a slightly different version of some piece of hardware working, for example).
If you want reliability, use the user space NFS server--it has been around for years, and it can be restarted easily. Or, you could, of course, just keep running a 2.2 kernel until whatever bugs you in 2.4 has stabilized.
As for Solaris, its record is hardly stellar. For example, Solaris NFS for many years had a bug that would randomly replace blocks of data with blocks of nulls in big files (people often spent weeks trying to figure out what was wrong with their software until they finally traced it to Solaris). There have been memory leaks driver problems, and backwards incompatibilities with Solaris. Most production users of Solaris are a couple of years behind the releases in order to avoid the bugs in the new releases. And many people never wanted to switch from SunOS to Solaris at all (I think we are still running some SunOS machines).
As they say, "the grass is always greener". I can tell you from many years living with SunOS/Solaris that Linux isn't bad in comparison.
OS X is a major upgrade, but I don't see where you see significant innovative contributions. OS X is NeXTStep with Java and MacOS 9 compatibility libraries. NeXTStep itself is the CMU Mach kernel, Stepstone's Objective-C language, and lots of libraries. The NeXTStep libraries and Objective-C were an attempt to bring Smalltalk technology to a UNIX workstation audience. OS X (and NeXTStep) are good software engineering efforts and good practical compromises. But I can't think of any large, new idea that they contributed to the world. Maybe you can share what you think they contributed.
In 1984???? Hardly. Perhaps if you were using SGI's at $40,000 and up and even then they did not have built in networking or a GUI etc etc etc...
Both Xerox and MIT had workstations with GUIs, desktops, and built-in networking, and you could buy those commercially. Apollo and several other companies also made such workstations. Tektronix had several workstations (and had had a much longer history, based on their graphics terminals). By 1984, people had already built Smalltalk machines out of commodity hardware.
As far as the Dynabook goes, yes Alan did conceptualize it twenty years or more ago, but it was a concept. It never came to fruition.
There were lots of handhelds before the Newton. One of particular note is the ParcTAB, a device in the Palm form factor, with handwriting recognition, wireless networking, and lots of other features. The Apple Newton, if anything, was a detour on the road to Palm and PocketPC--an inconvenient form factor, too small for real work and too large for putting in your pocket.
Apple did hit a sweet spot in the market, with nice looking, well-designed personal computers that were stripped down versions of the real things. That does not constitute "innovation" however. And whether it has been a good thing for the industry as a whole is an open question. I think the horrendously awkward design of the Macintosh toolbox has influenced the thinking of programmers for the last 15 years and had a very negative effect on even modern GUI libraries.
Cringely is just horribly confused. Microsoft will almost certainly continue to support ActiveX plugins, as well as enabling C# to be used for such plugins.
Eolas is a non-issue--they are leeches, but they won't kill Microsoft or Sun--they just want to suck some blood. And the only victory that they have won so far is to keep Microsoft from claiming the same technology with a later patent filing. The Eolas patent should get killed based on prior art, but if it isn't, it won't be the end of the world. (The founder of Eolas believes he invented all sorts of widely-used technology. The term "ignorance is bliss" comes to mind. Too bad our patent system encourages these kinds of misfilings.)
Dropping Java support from XP was something Microsoft had to do--they couldn't continue shipping their completely outdated version. This is good for Microsoft and it is good for users. Contrary to what Cringely is saying, Sun didn't just start writing Java for Windows, they've always had it--and a good ipmlementation, too.
Sun really can't expect Microsoft to ship Java after all the legal fights. Sun should stop whining and complaining, make Java an ActiveX component, and distribute Java widely through PC vendors and on CDs that ship with computer magazines. Writing and including some Java applications end-users actually want to run might give end users the incentive to stick the CD into the drive. Just about every CD in the world forces me to install the latest version of IE and DirectX--why can't Sun do the same with Java?
Your history is just completely messed up, and you get just about every point wrong.
When the Macintosh came out, it was basically a low-cost, stripped down version of desktop workstations at the time. Desktop workstations had good graphics, built-in Ethernet networking, lots of memory, and a large screen.
CD drives, USB, Firewire, and other technologies were developed for the PC or consumer market. Yes, Apple could deliver them a little earlier, but only because their machines were already premium priced.
In terms of laptops and handhelds, Apple was late to the party. The laptop form factor was most clearly described by Alan Kay with his Dynabook, more than a decade before Apple did anything. The TRS-80 Model 100 was much more portable than even today's Apple laptops. Handhelds predate the Newton by many years as well, and they were going to happen with or without Apple.
I think if you examine it closely, Apple has invented and innovated very little. What they do have is style, better taste than Microsoft, and a customer base that is willing to pay a premium price for the latest, slickest hardware (within limits). But I don't think that makes Apple an essential part of the computer industry.
Apple stopped playing the R&D lab for the industry years ago. Microsoft has finally stepped up to the plate and started pouring money into research (although Microsoft research hasn't produced much yet).
Apple's significance today is largely that it is the only alternative to Microsoft/Intel that's still around. But they fulfill that role only at Microsoft's pleasure--Microsoft could pull the rug out from under Apple whenever they like.
A lot of Unices, MacOS and Windows are built on these two languages.
This is actually a liability: just look at the endless stream of buffer overflow problems, core dumps, data corruption, etc. that applications in all these systems exhibit.
Component, object and application frameworks like MFC, KDE, QT are written in them.
And those systems are complex, fragile, difficult to extend, and resource intensive because they are written in C/C++.
A very large application base is written in them and it will not be replaced overnight.
Adopting Java or another new language doesn't mean you have to give up on using your favorite C/C++ applications. However, in a HLL (not necessarily Java, which is still pretty pedestrian), many of the KDE and Gnome applications that have taken a long time to write and debug are quick little hacks.
I don't think Java will ever completely take over C/C++, simply because the hardware accessibility just isn't in Java
Neither C nor C++ have "built in" functionality for "hardware accessibility". It happens to be the case that many C/C++ implementations use cast notation for giving you access to low-level features, but those extensions are not defined by the standard, and they do not work everywhere. Using cast notation in this way is a rather bad way of doing things anyway because programmers can't easily tell what kinds of low-level, unsafe, or unportable features a program uses.
The right way to provide hardware access is via a special library that contains all the operations C/C++ programs use. Then, programmers can tell when unsafe, low-level features are being used. The compiler can still optimize implementations of these features as much as in C/C++. I believe some of the embedded versions of Java offer these features.
Divorce statistics are skewed in that way because getting divorced influences the statistic directly by changing the size of the population. Programming in Java doesn't create more people or kill people. Your analogy doesn't hold. Statements involving "almost 60 percent of developers..." are well defined and meaningful. You may disagree with whether this results in more or better software, but that's a separate debate. I think the faster applications programmers dump C, the better for all of us.
I suspect Palm bought BeOS for the programmers, not the software. But if they did buy it because they want to put a BeOS derivative on future Palms (and they need a more powerful OS than they have), it just shows again how much in love the Palm culture is with proprietary systems. I think with this strategy, they are going to face a difficult battle in the marketplace, as they are competing against Java, Linux and WinCE (which is, of course, proprietary as well, but often not viewed as such).
The real question is where does that live the desktop OS that showed som much promise?
In my opinion, BeOS was too conservative. While it is a cleaner, more streamlined implementation of well-known concepts, I don't think that constitutes innovation. I think Apple made the right choice by going with NeXTStep, and Be's lack of success in the market was well justified.
D looks like a stripped down version of C++, limited to the features that an application programmer who grew up in the Windows environment might find useful. But we already have simplified, limited, easy-to-use languages: Java and C#. C++ is a complex language, and it isn't a particularly well designed language, but the complex features that it has are useful and powerful. Language design should go more in the direction of figuring out how to simplify providing those features, not in stripping C++ down to something from the 1960s again. Two thumbs down.
Good steganography is essentially the same as adding random noise to an image. You can structure the noise any way you like. There are lots of images that plausibly contain lots of noise, for example images taken in low light and images scanned from film. As long as you don't insist on a very efficient steganographic embedding, there are undetectable steganographic methods. Farid's research is pointless, and it is scary to think that courts may start relying on it.
When worms were common for UNIX platforms, UNIX was a proprietary system, and the number of programmers with access to the UNIX source code was probably no larger than the number of programmers with access to the NT source code is today. Also, for Internet servers, UNIX was pretty much the only game in town.
Linux, BSD, and UNIX is in a different boat today. There are multiple Internet-capable operating systems, and the sources for Linux, BSD, and many UNIX utilities are widely available. I don't know what this will work out to, but we can't predict from the past: the UNIX community was vastly different then from the way it is now.
The best protection would be if there were a dozen or so common Internet operating systems and a dozen or so widely used implementations of Internet servers and clients. You know, like an efficient, free market with real competition. Unfortunately, it isn't happening.
If some service is proprietary and not sufficiently well documented to be replicated by competitors or in free software, then that service isn't a "web service". "Web" implies that the service is based entirely on HTTP, HTML, DOM, and a few other W3C standards.
Microsoft and other companies shouldn't be allowed to misappropriate the good will that web services have, only to deliver something proprietary.
Cost. Right now, you can get 386SX CPU's for a couple of dollars.
Well, they are so cheap because there is lower demand, because the costs of the production line have been amortized, and because the profit margins are lower. The only thing that has kept the manufacturer from upgrading is the capital investment. Nice deal for you, but it can't last forever.
Power. Compare the latest generation of 386 CPUs to even a slow PII. HUUUGE difference here.
But technology is getting better all the time. If you wanted to build a low-performance, 386-class processor these days, you could do even better than running an outdated design.
Board space. The embedded 386's are a little bigger than an american nickle. Pentium class CPU's... well... are big.
See above: the old chip may satisfy your needs, but with new technology, you can do even better.
Longevity. When we bought these, we got committments from our suppliers that the CPU would be around for at least X months/years. This is REALLLLY important to us.
Unless you get contractual commitments from your vendor and you are willing to pay for it, you can't expect this. If it is "REALLLLY" important for you, you can pay for it.
Intel is still supporting and selling 80186 CPU's, for embedded controller uses.
And doubtlessly, Intel customers are paying for the privilege, and probably, these are actually revised designs produced with new facilities. Motorola is also still shipping embedded 68000 chips.
Basically, people who complain about this sort of thing expect their vendor to pay the opportunity cost of continuing to produce outdated chips. Sorry, but you can't expect that.
If you want low power, you have to pay for it. If you want a long-lived product line, you have to pay for it. If you want both, you have to pay for both. If some manufacturer like AMD happens to squeeze some cheap desktop chips from an aging production line that meet your needs, count your blessings, use it, and don't expect it to last. After all, you probably prefer AMD to stay in business, right? If they subsidize your products by keeping an unprofitable production line around, they won't.
Of course, what you might do is suggest to AMD that you are willing to pay a significantly higher price for their chips.
This isn't all that surprising. Loki's ports often came out long after the Windows versions--most serious game players had already bought the Windows version (after all, you can't help but get Windows shipped with your PC anyway). Also, Linux 3D graphics support has been too difficult to install until recently.
If they can hold on for another year or so, things may start looking up. Linux 3D support is getting better, and with MacOS X, game developers may start thinking more about non-Windows platforms anyway.
In C, this is a never ending battle. Even with Purify, you are going to spend lots of time introducing bugs, then tracking them down. If you must stick with C, consider using one of the C interpreters (EiC, cint, etc.). Machines have gotten fast enough that you can use them for debugging your code. Or stop worrying about it and just use the Boehm garbage collector as a garbage collector.
I switched from C to C++ basically because I couldn't get Purify for Linux. C++ has allowed me to adopt clear, well-defined memory management strategies and automate various pointer checks. I hardly ever get memory leaks or pointer errors in my C++ code anymore.
But no matter what you do in your own code, if you are using C or C++, you will always be exposed to numerous pointer bugs and leaks in library code. Most real-world C++ code commits the same memory allocation sins and has the same pointer bugs as real-world C code--people aren't taking sufficient advantage of C++'s smart pointer facilities (even STL is flawed in that way). Therefore, for multiprogrammer projects, I wouldn't use anything but Java or another safe language anymore.
Can this new approach to Linux clusters be used here?
Use PVM or MPI. Both exist prepackaged for most major Linux distributions.
I'm trying to design a specialized data-fitting program to be used for accelerator-based condensed matter physics.
I think this may be a case where a bit more thinking and literature research about the problem would help a great deal. People solve extremely complex data fitting problems on modern PCs without the need for parallel processing, and there are very sophisticated algorithms for doing this. You should probably talk to local experts in statistics, computer science, and pattern recognition.
economies of scale and externalities
on
Windows in 2020
·
· Score: 2, Insightful
I fully agree. And at the heart of it is that economists and politicians neglected externalities.
Yes, you do get economies of scale if you have huge companies. Coca Cola can ship beverages cheaper and more reliably than 10000 local bottling plants all over the country. You do derive benefits from comparative advantage if you have completely open trade.
The problem is that the megacorp approach sacrifices the diversity that underlies a healthy free market just as much as a healthy ecology. In effect, the cheaper soft drink or the cheaper PC is bought by opportunity costs: society and the market lose the ability to adapt to changing conditions quickly because there are no alternative players that can take over. Instead, the leading players need to laboriously restructure and adapt, with all the speed and efficiency of the Soviet (planned) economy.
What can be done about it? Giving the states more autonomy helps. Allowing states and cities to adopt a wide variety of local regulations helps. Taxing interstate and international commerce helps. A progressive taxation system for corporate profits might help. But all of those are fighting words to conservative economists, as well as corporate backed politicians. And such approaches are not without risk of abuse and inherent problems either.
There is something you can do as a customer, though: be aware of the importance of diversity. Buy local, buy from small companies, and buy the non-mainstream product. Pay a little more for the high-quality specialty item. Don't worry about what the Joneses do. Do without, or do something different. Don't make a habit of eating at big chains, watching a lot of TV, etc. In addition too creating economic diversity, your health and your wallet will thank you, too. But don't obsess about it, either: moderate change in a lot of people is far better than obsessive change in a few.
Internet accessible cameras were around long before that coffee pot. Even CuSeeMe predates the coffee pot by years. And Internet accessible utilitarian devices (elevators, coke machines, etc.) go back to the 1970's.
I don't quite see how the coffee pot achieved this fame. Maybe what makes history is what is tangible to journalists? And I suppose that's why history will record that Bill Gates invented the Internet and the coffee pot is the first web cam.
I nominate you for the "Sweeping Statements Award." I especially like the way you say "The object models of Python, Perl, and Ruby."
Maybe you haven't noticed, but Python, Perl, and Ruby all represent objects as general purpose dictionary types, in contrast to the Lisp and Smalltalk approaches.
Beyond that, I have no idea what you railing against. Did I say scripting languages were bad? Did I say people should switch to Lisp? What is your problem?
Actual programming language researchers" are typically not even interested in designing languages for general purpose use.
Neither are scripting language developers. But many good, powerful languages were developed for real-world use by people with a lot of background in programming languages:
Lisp: symbolic AI
Scheme: planning
Smalltalk: Dynabook, educational software
SML: proof systems
How were Kernighan and Richie programming language researchers but not Van Rossum and Wall?
They weren't, which is probably why C/C++ are as flawed as Perl. All three share an almost complete disregard for error checking and safety. And all three of them are closely tied to the environments where they were developed, with little regard for long-term evolution. Their approach is quite successful: do a quick-and-dirty job and fix things up later.
Slashdot Mirror
This crosses another threshold in the patenting of living things. Up to now, patents have been on specific, identifiable species, cell lines, DNA sequences, or organisms, and even that has met with considerable resistance. But this patent is on any cell line that has desirable properties, whether found by these researchers or by anybody else. Another analogy is that if you discover the first apple tree, you claim a patent on any tree bearing sweet fruit.
I think society needs to think carefully about whether these kinds of patents are in the public interest. It might be defensible to let the university make claims on specific cell lines and on methods for creating those cell lines (and even that seems dubious to me), but I see no basis in patent law for the more general claims to all primate stem cell lines. If you do, maybe you can explain how you think this is justified by patent law and specifically how society benefits from such patents.
In fact, physicists have developed a number of techniques that let us manipulate atoms in ways that nature does not use for building complex structures. For example, STMs and lasers allow us to move single atoms. And we have found out that individual atoms and assemblies are much more stable than previously thought.
Maybe a few years ago, the SCO kernel was a bit better than the Linux kernel, but today, I see little or no advantage. In fact, Linux has better driver support and a more active user community. And being able the modify the kernel source code is useful even for end users (a quick hack to get a slightly different version of some piece of hardware working, for example).
As for Solaris, its record is hardly stellar. For example, Solaris NFS for many years had a bug that would randomly replace blocks of data with blocks of nulls in big files (people often spent weeks trying to figure out what was wrong with their software until they finally traced it to Solaris). There have been memory leaks driver problems, and backwards incompatibilities with Solaris. Most production users of Solaris are a couple of years behind the releases in order to avoid the bugs in the new releases. And many people never wanted to switch from SunOS to Solaris at all (I think we are still running some SunOS machines).
As they say, "the grass is always greener". I can tell you from many years living with SunOS/Solaris that Linux isn't bad in comparison.
OS X is a major upgrade, but I don't see where you see significant innovative contributions. OS X is NeXTStep with Java and MacOS 9 compatibility libraries. NeXTStep itself is the CMU Mach kernel, Stepstone's Objective-C language, and lots of libraries. The NeXTStep libraries and Objective-C were an attempt to bring Smalltalk technology to a UNIX workstation audience. OS X (and NeXTStep) are good software engineering efforts and good practical compromises. But I can't think of any large, new idea that they contributed to the world. Maybe you can share what you think they contributed.
Both Xerox and MIT had workstations with GUIs, desktops, and built-in networking, and you could buy those commercially. Apollo and several other companies also made such workstations. Tektronix had several workstations (and had had a much longer history, based on their graphics terminals). By 1984, people had already built Smalltalk machines out of commodity hardware.
As far as the Dynabook goes, yes Alan did conceptualize it twenty years or more ago, but it was a concept. It never came to fruition.
There were lots of handhelds before the Newton. One of particular note is the ParcTAB, a device in the Palm form factor, with handwriting recognition, wireless networking, and lots of other features. The Apple Newton, if anything, was a detour on the road to Palm and PocketPC--an inconvenient form factor, too small for real work and too large for putting in your pocket.
Apple did hit a sweet spot in the market, with nice looking, well-designed personal computers that were stripped down versions of the real things. That does not constitute "innovation" however. And whether it has been a good thing for the industry as a whole is an open question. I think the horrendously awkward design of the Macintosh toolbox has influenced the thinking of programmers for the last 15 years and had a very negative effect on even modern GUI libraries.
Eolas is a non-issue--they are leeches, but they won't kill Microsoft or Sun--they just want to suck some blood. And the only victory that they have won so far is to keep Microsoft from claiming the same technology with a later patent filing. The Eolas patent should get killed based on prior art, but if it isn't, it won't be the end of the world. (The founder of Eolas believes he invented all sorts of widely-used technology. The term "ignorance is bliss" comes to mind. Too bad our patent system encourages these kinds of misfilings.)
Dropping Java support from XP was something Microsoft had to do--they couldn't continue shipping their completely outdated version. This is good for Microsoft and it is good for users. Contrary to what Cringely is saying, Sun didn't just start writing Java for Windows, they've always had it--and a good ipmlementation, too.
Sun really can't expect Microsoft to ship Java after all the legal fights. Sun should stop whining and complaining, make Java an ActiveX component, and distribute Java widely through PC vendors and on CDs that ship with computer magazines. Writing and including some Java applications end-users actually want to run might give end users the incentive to stick the CD into the drive. Just about every CD in the world forces me to install the latest version of IE and DirectX--why can't Sun do the same with Java?
When the Macintosh came out, it was basically a low-cost, stripped down version of desktop workstations at the time. Desktop workstations had good graphics, built-in Ethernet networking, lots of memory, and a large screen.
CD drives, USB, Firewire, and other technologies were developed for the PC or consumer market. Yes, Apple could deliver them a little earlier, but only because their machines were already premium priced.
In terms of laptops and handhelds, Apple was late to the party. The laptop form factor was most clearly described by Alan Kay with his Dynabook, more than a decade before Apple did anything. The TRS-80 Model 100 was much more portable than even today's Apple laptops. Handhelds predate the Newton by many years as well, and they were going to happen with or without Apple.
I think if you examine it closely, Apple has invented and innovated very little. What they do have is style, better taste than Microsoft, and a customer base that is willing to pay a premium price for the latest, slickest hardware (within limits). But I don't think that makes Apple an essential part of the computer industry.
Apple's significance today is largely that it is the only alternative to Microsoft/Intel that's still around. But they fulfill that role only at Microsoft's pleasure--Microsoft could pull the rug out from under Apple whenever they like.
This is actually a liability: just look at the endless stream of buffer overflow problems, core dumps, data corruption, etc. that applications in all these systems exhibit.
Component, object and application frameworks like MFC, KDE, QT are written in them.
And those systems are complex, fragile, difficult to extend, and resource intensive because they are written in C/C++.
A very large application base is written in them and it will not be replaced overnight.
Adopting Java or another new language doesn't mean you have to give up on using your favorite C/C++ applications. However, in a HLL (not necessarily Java, which is still pretty pedestrian), many of the KDE and Gnome applications that have taken a long time to write and debug are quick little hacks.
I don't think Java will ever completely take over C/C++, simply because the hardware accessibility just isn't in Java
Neither C nor C++ have "built in" functionality for "hardware accessibility". It happens to be the case that many C/C++ implementations use cast notation for giving you access to low-level features, but those extensions are not defined by the standard, and they do not work everywhere. Using cast notation in this way is a rather bad way of doing things anyway because programmers can't easily tell what kinds of low-level, unsafe, or unportable features a program uses.
The right way to provide hardware access is via a special library that contains all the operations C/C++ programs use. Then, programmers can tell when unsafe, low-level features are being used. The compiler can still optimize implementations of these features as much as in C/C++. I believe some of the embedded versions of Java offer these features.
Divorce statistics are skewed in that way because getting divorced influences the statistic directly by changing the size of the population. Programming in Java doesn't create more people or kill people. Your analogy doesn't hold. Statements involving "almost 60 percent of developers ..." are well defined and meaningful. You may disagree with whether this results in more or better software, but that's a separate debate. I think the faster applications programmers dump C, the better for all of us.
I suspect Palm bought BeOS for the programmers, not the software. But if they did buy it because they want to put a BeOS derivative on future Palms (and they need a more powerful OS than they have), it just shows again how much in love the Palm culture is with proprietary systems. I think with this strategy, they are going to face a difficult battle in the marketplace, as they are competing against Java, Linux and WinCE (which is, of course, proprietary as well, but often not viewed as such).
In my opinion, BeOS was too conservative. While it is a cleaner, more streamlined implementation of well-known concepts, I don't think that constitutes innovation. I think Apple made the right choice by going with NeXTStep, and Be's lack of success in the market was well justified.
D looks like a stripped down version of C++, limited to the features that an application programmer who grew up in the Windows environment might find useful. But we already have simplified, limited, easy-to-use languages: Java and C#. C++ is a complex language, and it isn't a particularly well designed language, but the complex features that it has are useful and powerful. Language design should go more in the direction of figuring out how to simplify providing those features, not in stripping C++ down to something from the 1960s again. Two thumbs down.
Good steganography is essentially the same as adding random noise to an image. You can structure the noise any way you like. There are lots of images that plausibly contain lots of noise, for example images taken in low light and images scanned from film. As long as you don't insist on a very efficient steganographic embedding, there are undetectable steganographic methods. Farid's research is pointless, and it is scary to think that courts may start relying on it.
Linux, BSD, and UNIX is in a different boat today. There are multiple Internet-capable operating systems, and the sources for Linux, BSD, and many UNIX utilities are widely available. I don't know what this will work out to, but we can't predict from the past: the UNIX community was vastly different then from the way it is now.
The best protection would be if there were a dozen or so common Internet operating systems and a dozen or so widely used implementations of Internet servers and clients. You know, like an efficient, free market with real competition. Unfortunately, it isn't happening.
Microsoft and other companies shouldn't be allowed to misappropriate the good will that web services have, only to deliver something proprietary.
Well, they are so cheap because there is lower demand, because the costs of the production line have been amortized, and because the profit margins are lower. The only thing that has kept the manufacturer from upgrading is the capital investment. Nice deal for you, but it can't last forever.
Power. Compare the latest generation of 386 CPUs to even a slow PII. HUUUGE difference here.
But technology is getting better all the time. If you wanted to build a low-performance, 386-class processor these days, you could do even better than running an outdated design.
Board space. The embedded 386's are a little bigger than an american nickle. Pentium class CPU's... well... are big.
See above: the old chip may satisfy your needs, but with new technology, you can do even better.
Longevity. When we bought these, we got committments from our suppliers that the CPU would be around for at least X months/years. This is REALLLLY important to us.
Unless you get contractual commitments from your vendor and you are willing to pay for it, you can't expect this. If it is "REALLLLY" important for you, you can pay for it.
Intel is still supporting and selling 80186 CPU's, for embedded controller uses.
And doubtlessly, Intel customers are paying for the privilege, and probably, these are actually revised designs produced with new facilities. Motorola is also still shipping embedded 68000 chips.
Basically, people who complain about this sort of thing expect their vendor to pay the opportunity cost of continuing to produce outdated chips. Sorry, but you can't expect that.
If you want low power, you have to pay for it. If you want a long-lived product line, you have to pay for it. If you want both, you have to pay for both. If some manufacturer like AMD happens to squeeze some cheap desktop chips from an aging production line that meet your needs, count your blessings, use it, and don't expect it to last. After all, you probably prefer AMD to stay in business, right? If they subsidize your products by keeping an unprofitable production line around, they won't.
Of course, what you might do is suggest to AMD that you are willing to pay a significantly higher price for their chips.
If they can hold on for another year or so, things may start looking up. Linux 3D support is getting better, and with MacOS X, game developers may start thinking more about non-Windows platforms anyway.
I switched from C to C++ basically because I couldn't get Purify for Linux. C++ has allowed me to adopt clear, well-defined memory management strategies and automate various pointer checks. I hardly ever get memory leaks or pointer errors in my C++ code anymore.
But no matter what you do in your own code, if you are using C or C++, you will always be exposed to numerous pointer bugs and leaks in library code. Most real-world C++ code commits the same memory allocation sins and has the same pointer bugs as real-world C code--people aren't taking sufficient advantage of C++'s smart pointer facilities (even STL is flawed in that way). Therefore, for multiprogrammer projects, I wouldn't use anything but Java or another safe language anymore.
Use PVM or MPI. Both exist prepackaged for most major Linux distributions.
I'm trying to design a specialized data-fitting program to be used for accelerator-based condensed matter physics.
I think this may be a case where a bit more thinking and literature research about the problem would help a great deal. People solve extremely complex data fitting problems on modern PCs without the need for parallel processing, and there are very sophisticated algorithms for doing this. You should probably talk to local experts in statistics, computer science, and pattern recognition.
Yes, you do get economies of scale if you have huge companies. Coca Cola can ship beverages cheaper and more reliably than 10000 local bottling plants all over the country. You do derive benefits from comparative advantage if you have completely open trade.
The problem is that the megacorp approach sacrifices the diversity that underlies a healthy free market just as much as a healthy ecology. In effect, the cheaper soft drink or the cheaper PC is bought by opportunity costs: society and the market lose the ability to adapt to changing conditions quickly because there are no alternative players that can take over. Instead, the leading players need to laboriously restructure and adapt, with all the speed and efficiency of the Soviet (planned) economy.
What can be done about it? Giving the states more autonomy helps. Allowing states and cities to adopt a wide variety of local regulations helps. Taxing interstate and international commerce helps. A progressive taxation system for corporate profits might help. But all of those are fighting words to conservative economists, as well as corporate backed politicians. And such approaches are not without risk of abuse and inherent problems either.
There is something you can do as a customer, though: be aware of the importance of diversity. Buy local, buy from small companies, and buy the non-mainstream product. Pay a little more for the high-quality specialty item. Don't worry about what the Joneses do. Do without, or do something different. Don't make a habit of eating at big chains, watching a lot of TV, etc. In addition too creating economic diversity, your health and your wallet will thank you, too. But don't obsess about it, either: moderate change in a lot of people is far better than obsessive change in a few.
I don't quite see how the coffee pot achieved this fame. Maybe what makes history is what is tangible to journalists? And I suppose that's why history will record that Bill Gates invented the Internet and the coffee pot is the first web cam.
Maybe you haven't noticed, but Python, Perl, and Ruby all represent objects as general purpose dictionary types, in contrast to the Lisp and Smalltalk approaches.
Beyond that, I have no idea what you railing against. Did I say scripting languages were bad? Did I say people should switch to Lisp? What is your problem?
Neither are scripting language developers. But many good, powerful languages were developed for real-world use by people with a lot of background in programming languages:
How were Kernighan and Richie programming language researchers but not Van Rossum and Wall?
They weren't, which is probably why C/C++ are as flawed as Perl. All three share an almost complete disregard for error checking and safety. And all three of them are closely tied to the environments where they were developed, with little regard for long-term evolution. Their approach is quite successful: do a quick-and-dirty job and fix things up later.