CMG was founded in the 1960's. I can't tell when they developed their Samba product or trademarked the name, but it was in widespread use in 1997 (120 licensees, big for that kind of package). Interestigly , CMG sappears to be a Samba (as in the SMB implementation) user and sent mail to the mailing list in 1999 about a configuration problem.
The SMB implementation seems to have been around since 1991, but doesn't seem to have been called "Samba" until 1994.
The CMG trademark claim may be legitimate under the current trademark categories in Germany (and probably US categories as well).
As an aside, the UK trademark office is down overnight (CMG's Samba is used in the UK as well), and the German trademark office charges $2/search, with a $75 minimum. The US PTO web services seem really nice in comparison (and it lists lots of "Samba" trademarks, although all of them seem to be "typed drawings" rather than words).
I think the problem here is that the German trademark office has dumped all computer programs into a single category, so if two programs, even with completely different fields of application, use the same trademark, they conflict. That makes about as much sense as dumping all "metal products" into the same category.
In any case, another important question will be when CMG applied for their trademark. If Samba (the free SMB implementation) was in common use in Germany before then, it will likely be exempted from claims, even from someone holding a registered trademark, just like it would be in the US.
There are lots of better and cheaper alternatives out there, depending on your needs. You can get yourself a laptop. Or you can build something around a PC-104 or SBC system. Or you can buy a WinCE machine (e.g., the Compaq iPAQ) and install Linux on it.
Maybe it's because it's -- true? In some debates, you reach a point where it simply doesn't make sense anymore to treat two viewpoints on equal footing.
Besides, I think we have had lots of articles saying that Linux/UNIX sucks as well--but there seems to be some agreement that it sucks less.
Even using Moody's own reasoning and the data he refers to, Linux beats NT by a wide margin. But he misquotes the numbers. How do you suggest one can compete with deliberately erroneous reporting? Perhaps pay Moody more money than Microsoft did?
I guess while the government hasn't quite become "Big Brother" yet, Apple is trying hard to be "Big Brother" to their employees. Yes, the legal system allows them to do this, but that doesn't make it the right thing to do, in particular for a company with the pretensions that Apple has.
What matters for the security of a system is the vulnerabilities in the the system you are actually running and exposed to, not the vulnerabilities in software that happens to be included in the distribution.
For building a web server, for example, it's easy to strip down a Linux system to just a web server and ssh for remote administration, with no other exposures.. Then, the only vulnerabilities you are concerned with are those in the packet filtering code, the web server, and sshd. It's considerably harder to strip down NT to that degree, in particular if you want to keep some kind remote administrability.
Moody is either simply clueless, or he writes deliberately biased pieces. Which leaves me wondering: can't ABC get people with a sense of ethics and some competence anymore?
I was referring to the PageWriter 2000X. It is based on a 68000 and Sun+Motorola were showing them at JavaOne 1999 (and probably 2000 as well). I forget the exact specs, but the JavaOne version had more than 4Mbytes of memory and ran at a decent clock speed. The retail versions have less available memory, but are still pretty powerful.
A big fraction of the articles here is about how "bloated" X is supposed to be. If people keep saying it enough, I guess everybody will start believing it. But the facts are different.
On my RH6.2 distribution, the SVGA server is about 1.7Mbytes. That's code that's optimized for speed, not space, and includes a lot of extensions and features. The full libX11.a is 1.1Mbytes; most of that stuff isn't needed to write applications for a handheld and would never get linked, and could probably even be stripped out. And toolkits like FLTK show that even a reasonably nice toolkit under X doesn't need to take up a lot of space.
I've run X11 just fine on a 4M 80386 machine, less powerful than the handhelds in use today (in fact, less powerful than a Motorola pager). X11 was designed to run on those kinds of environments. It has a number of provisions for dealing with restrictions on simple devices (e.g., backing store is not guaranteed). And it has acquired surprisingly little extra stuff in its core since those days (although there are lots of useful, loadable, optional modules).
Well, as far as toolkits are concerned, I agree (and so does the article). But X11 is mainly a remote graphics library, and it adapts just fine to whatever screen size you want to use with it. If anything, its pixel-accurate rendering and low level control, which make it an occasional pain to toolkit implementors, are an advantage in such an environment.
X11 originated on machines that were less powerful and had less memory than the iPaq or Itsy (I used to run it on a 4Mbyte 386). The core protocols haven't changed in a decade and there isn't any significant dead wood due to backwards compatibility. And I would think that network transparency is particularly useful for a little portable device; one big problem I have with my PalmPilot is that I can't just pop its applications up on my desktop.
I can't think of any widely used windowing system that would be more suitable for the task. But maybe you have some suggestions?
I don't know what you are running, but XF86_VGA16 3.? is about 1.74M of "text" (code) on RH6.2 Presumably, the PDA version throws out quite a number of features.
In some places, the X11 code explicitly traded code size for speed on RISC machines (e.g., loop unrolling, etc.), so those are obvious places to make it smaller if you need to squeeze.
Beyond that, there are probably some things that can be cleaned up, and it's good that someone looks at them. But please don't get melodramatic: the savings aren't going to be earth shattering, and they don't have to be. The standard X11 server isn't all that bad. I used to run X11 on a 4Mbyte 80386 (under SVR3) and even that worked just fine; a handheld is going to be faster than that.
Perhaps you are looking at the VSZ and RSS columns in ps? Those are big (64Mbytes on my machine), but they include the shared memory used for the frame buffer and I/O, as well as a lot of internal buffers.
The screen resolution on the iPaq is higher, I believe (320x200?).
In any case, the reason why you aren't seeing handhelds with eyepieces is that they are still too expensive. When the prices come down, you'll probably first see them on digital cameras. There are also some tricky UI issues.
No, it's not "yours". Society has granted you certain rights for a limited time, as a tradeoff to encourage you to share. But, by law, that's not the same as owning a sock or any other kind of physical property.
And it would be bad if it were otherwise. For example, multiple people may have developed the same "intellectual property" at roughly the same time, but only one person will be granted rights. Why should that person own ideas that the other person invested just as much time and effort in? A limited time grant of rights is a compromise. "Intellectual property" is different from physical property for those and many other reasons.
But if RomNet is really Napster for video game ROMs, it's illegal as all hell.
That's not at all clear. Many kinds of swapping may well fall under "fair use". The legal system and legislation will ultimately clarify those issues.
And it is also well worth debating whether content that is decades old, not available commercially, and of social interest, should, in fact, receive copyright protection. 100 years ago, the copyright on many things being swapped would already have run out, and it is well worth discussing (IMO) whether we should bring copyright back into such a more sensible, conservative framework.
Of course, the most important component of a CD is the artist?s effort in developing that music. Artists spend a large portion of their creative energy on writing song lyrics and composing music or working with producers and A&R executives to find great songs from great writers.
If you look at the prices for classical music CDs, where the "great music" is free and the artists are long dead, it shows that that argument is nonsense.
In fact, the classical music CD market shows clearly what is happening: record labels limit the choice of consumers by picking only a few artists, marketing the recordings to the hilt, and charging enormous amounts of money for those CDs. Artists likely don't see much of that. And, frankly, I doubt the situation is much different for other genres.
Another factor commonly overlooked in assessing CD prices is to assume that all CDs are equally profitable. In fact, the vast majority is never profitable.
And why aren't they profitable? For most artists, it can't be the small percentage the artist gets. With digital technology technical production costs are minimal. And pressing CDs is, what, a few cents now? So where does the red ink come from? It must be the money they spend on buyin shelf space, endorsements, artwork, marketing and promoting artists that wouldn't stand a chance by word of mouth or true consumer preferences.
In fact, flooding the market with promotional materials for your product does not add value to the product. Neither does buying shelf space to the exclusion of other, smaller players. So, the lack of profitability is not related to any benefit to the consumer. Rather, the consumer pays record labels to allow them to limit the consumer's choice.
In the past, with limited shelf space, there may have been some justification for this. With on-line music, there is none. The record industry and its money-gobbling corporate structure is an inefficient anachronism, made obsolete by the Internet and technology. Let's hope that they can't use their accumulated wealth to interfere with the free market mechanisms that, rightfully, ought to drive them out of business.
NT can, of course, handle Hotmail. That's not the issue. And Microsoft has to do this if they want to appear credible at all. They also have to do it in order to figure out what is wrong with Windows 2000.
The question is whether it's cost effective for customers to deploy Windows 2000 in that way. There are several components to the cost:
The Microsoft software licenses. Expensive for business customers, a non-issue for Microsoft.
Software licenses for 3rd party tools that plug holes. Probably also given almost freely to Microsoft by companies hoping to get acquired.
Hardware costs. Windows 2000, in practice, probably needs more hardware to achieve similar levels of reliability and performance as UNIX machines (I'm not talking raw hits/second).
Maintenance and administration costs. Windows 2000 scores very poorly in that regard in my opinion. But for a Windows-only shop like Microsoft, it's probably cheaper to go with Windows than with BSD.
So, can it be done? Sure. And Microsoft needs to do it if they want to play at all. But it is not a convincing demonstration that it's a cost-effective solution.
If I were to start another big web project, I'd still not pick Windows 2000--except for niche server applications, I believe it's still too expensive to license the required MS and non-MS software, and it requires too much manpower to administer. It also doesn't have any place to grow right now: a multiprocessor Xeon is it.
Actually, it shows us one thing: the fact that Microsoft has been playing around with this for, what, three years, suggests that you can't easily create the software for a Hotmail-like service rom scratch and with complete specifications on the NT platform within that time period even if you have unlimited amounts of money and all the Windows expertise in the world. Perhaps that's the most important lesson of that exercise, and something aspiring web startups should take note of.
Of course, Shamoon's company will make a pretty penny, since they are pushing their technology to be the basis for these new content management systems. Oh, right now, they are saying that it will only be used to exclude songs that are identfiably copyrighted.
But that's nonsense and based on selling snake oil. Watermarking technologies fundamentally aren't robust, and even if those kinds of "open" players with some rights management ever made it to the market, within months, people would hack the managed content and make it unmanaged. The industry would then scream "crisis" and "starving artists" and release the next version of the player such that it only plays music that has identifiable keys, keys held by the major record labels and nobody else.
In fact, Shamoon states clearly himself that he doesn't expect open players to survive, so all this other stuff about watermarking etc. is just posturing:
[T]he industry will adopt a common encrypted format and CDs will go away the way LPs went away.
Once that happens, the incentive for hardware providers (often in conglomerates with content providers anyway) to produce players capable of playing open formats will go away, and you'll be left with proprietary formats, proprietary closed-source encoders, and authoring controlled by a few big companies.
Oh, and if that is not enough, after throwing out all your LPs and buying everything in CD format (guaranteed to oxydize out of existence in a few years), we are now supposed to pay for all that music yet again in the form of some future encrypted format that we can do even less with. How greedy can these people get?
On the plus side, their greed may kill their business. More and more musicians will find it easier to just record and publish outside the mainstream media conglomerates. And streaming Internet access (wired and wireless), as well as small, general purpose wearable computers, will make control of player formats meaningless.
What the industry should do is forget about all this player and encryption nonsense and simply gear up for a future in which everybody can have their own personalized radio station, with just enough ads thrown in to cover the costs but not enough to bother people sufficiently to switch to something else.
Oh, yes, that probably means lower profits. But the music industry right now is an anachronism, like weavers or blacksmiths were after the industrial revolution. It used to take lots of sound engineers, record factories, broadcasters, producers, etc. to get a piece of music to the end users. These days, it takes none of that. Of course their profits should be much lower because their product has gone from being a premium product that's difficult to produce and distribute to something that's almost free to produce and distribute.
Designing a whole cross-platfrom GUI library for the fairly simple GUI that Mozilla has seems like overkill, and it makes the browers more complex, more buggy, and bigger than it needs to be.
Even if people had wanted that, they could have used an existing cross-platform toolkit like wxWindows, FLTK, or Tcl/Tk. Even supporting the cross-platform GTK efforts would have been faster. But ultimately, egos apparently got in the way, and the Mozilla team thought they could do better in a year or two with no track record of doing a cross-platform GUI as a group, even though those other groups had been working on cross-platform GUIs for years and delievered several versions, and even though the Mozilla group also had a browser to deliver at the same time.
As for Mozilla needs an editor to do mail, I think it should do neither. Maybe there should be a loosely coupled Mozilla-branded mail client and a loosely coupled Mozilla-branded editor, together with a simple mechanisms for them to exchange data (open a pipe/socket/...). The fact that Netscape comes with an integrated, preferred E-mail client and editor is a disadvantage, not an advantage, because people have their own mailers already.
Mozilla suffers from the typical second system effect and the not-invented-here syndrome. Let's hope that the useful bits and pieces it actually contains will survive in better designed systems like Galeon or TkZilla.
Can you name any significantly large piece of software written in [Modula-3 or Ada] that I could examine?
For Modula-3, go to www.m3.org and follow the links (a whole operating system with various network services has been written at it and is still in use at U. Washington). For Ada, you'll have to talk to your local defense contractor; lots of real-time military systems are written in it, so it definitely gets the performance (Ada is a bit too pedestrian for my taste, so I don't follow it much). For Oberon, the entire Oberon operating system, drivers, compiler, web browser, and other things are written in it, and they are open source.
you must be talking about run-time fault-tolerance and correction. When you need to do this sort of thing, then people most certainly break things down into modules seperated by process lines. A dataabase server or the TCP stack are both great examples of this.
If you haven't noticed, relational database performance on UNIX sucks. It takes milliseconds to get any data out of the damned thing, which is why everybody is using stored procedures, which means they put code back into a single process. I have not seen any TCP/IP stack under UNIX systems that is "split up along process lines"; if the Linux or SystemV TCP/IP stack crashes, so does the whole kernel. Both of these examples make my point.
Although it can be done to some degree, it would of course be incredibly difficult to create a class of smart pointers for each and every type of pointer use. Also, as you note, you would have to use those pointer types everywhere, which is another big strike against them. This kind of wrapping is not what I'm talking about.
But it's the kind of wrapping I'm talking about, and it's the kind of wrapping that is necessary to make C++ a safe language.
The claim was that you can have other pointer models and not sacrifice any speed. I'm having a hard time imagining this, as "the C pointer model" mirrors the hardware very closely. I'm very, very willing to be corrected.
The problem with C/C++ pointers is not that they model the hardware very closely. The problem is that they aren't typed sufficiently finely: heap and stack allocated arrays, displaced arrays, references to stack variables, references to locations in data structures, heap allocated data structures, etc. are all represented by a single type, a "pointer". Other languages use different static types to represent those different constructs. And those constructs are different because they are associated with different object lifetimes and different opportunities for (optional) runtime error checking.
Adding those extra static types to distinguish the different meanings of "pointers" has no runtime overhead at all. And if you (for some reason) need to convert among the different static types, a call to "unsafe::convert_..." would do the trick, again, with no overhead, and would indicate that something funny was going on.
The way it is in C/C++ right now, the compiler just doesn't have the information to give meaningful compile time warnings or errors. It also doesn't have enough information to insert efficient runtime error checks if the programmer wants that for debugging. Ultimately, the lack of static type information is even counterproductive for generating efficient code on upcoming architectures.
Since so many institutions (the government, your ISP, your neighbors on the same cable branch, the guy with the keys to the phone closet, etc.) can hack into your E-mail and other network transmissions anyway, maybe one should just make it legal. That way, every user will understand that they need to use cryptography for all messages.
In order to make laws like in the UK that require giving up keys meaningless, I think we should also start keeping random data on our hard drives (e.g., filling the empty blocks with random data) and adding random bits to our communications (for images and speech, the low order bits are usually already random enough). That's good security anyway. Here is a start--or is it a secret message... ?
GNU Sather and SmallEiffel compile to C, and there are versions of the DEC Modula-3 compiler that compile to C as well. Java, of course, also has implementations for many platforms.
As I said myself, those languages have smaller user communities, and that means they have fewer libraries and tools for them. But you can call C and C++ code from them and they are quiet usable, in particular on Linux.
I don't recommend doing everything in them, but give them a try for some projects, in particular open source projects for Linux. That's the only way this chicken-and-egg problem of moving beyond C++ will get addressed.
Both the "C pointer model" and the manual memory management are easily wrappable.
They are wrappable only in special cases. They are not wrappable in general.
For example, you can't "wrap" call-by-reference or the address-of operator because smart pointers aren't really pointers--inheritance gets screwed up.
Using string manipulation as a specific example, exactly what about std::string "severely limits language semantics"?
You can make strings reasonably safe, but strings are probably the easiest case. The hard part is data structures that refer to each other.
Sure there is [a way to achieve fault isolation in C++]. See man 2 fork, or CORBA
That's not fault isolation in C++, it's fault isolation in the operating system. That kind of approach has a lot of overhead. That's why programs like Netscape or Emacs are multi-megabyte executables composed of dozens of libraries, rather than a bunch of small, communicating, separate processes.
It also doesn't help a lot, since even running in separate processes, it's really easy for a process to corrupt (e.g., array index error) the data it then sends on to another process via CORBA; you still can't tell who did it in C++.
Whether you believe me or not that fault isolation through processes can't be used in many cases, the fact is that people don't use it, and that alone is indication enough that we need a different mechanism.
No, good programming practices are what prevents bugs. IMHO there isn't much difference between the various type-safe languages in bug prevention, but there is a huge difference between the various programming practices and quality standards.
There isn't much difference among the various type safe languages in terms of bug prevention, but there is a huge difference between them and C/C++.
I have talked with plenty of folks who claim that there's "no performance penalty or other drawbacks" to not having the power of C/C++'s low-level control, but I haven't seen anyone back that up with proof. I would really enjoy for someone, anyone, to prove otherwise.
Go use Modula-3 or Ada or any of the other languages. If you want to, you can write code in them that is identical to C++, including all the unsafe constructs you want: C++ constructs translate one-to-one into those languages.
The difference is that those languages have a well-defined, safe subset that people can use to write programs in.
Of course, the compilers and tools for those languages are inferior to C++--because of their smaller user community. Many Modula-3 compilers don't do cross-module inlining, for example, so they will look worse on benchmarks. But that's a chicken-and-egg problem: because of the small user communities, they compilers don't get better, so everybody keeps suffering with C++.
*NIX had the luxury of running on some pretty powerful hardware right from the start.
UNIX started out on a PDP-7, hardware that was less powerful than even the original IBM PC. BSD versions ran just fine on PDP-11 machines with 64k or 128k of RAM and fairly sluggish processors. Xerox PARC had also some version of Smalltalk on early PC hardware, including GUI. People had multitasking systems with hierarchical file systems even on 8bit processors.
In fact, it appears that even IBM had a good multitasking OS ready for the IBM PC. But they couldn't ship it because they had been under investigation by the justice department for tying software and hardware sales.
The limitations of the original PC hardware (which, themselves, were a result of IBM's greed unwillingness to cut into its own business) are no excuse for the lousy design of DOS or Windows.
DOS/Win is the real hobbiest OS. When MS was serving the PC community, *NIX was still just for business.
That's because volume and marketing from IBM drove the cost down, not because of any technical features of DOS/Windows.
The story of Windows is similar. Systems like the Atari ST, the Macintosh, and the Amiga also showed that you could do a lot better than Windows when it came to designing a Windows-like OS (simple, no protection, etc.). Windows again was technically the bottom of the barrel and only caught on because of greed and strategic errors by their competitors, and aggressive marketing and cut-throat business tactics by Microsoft.
Slashdot Mirror
The SMB implementation seems to have been around since 1991, but doesn't seem to have been called "Samba" until 1994.
The CMG trademark claim may be legitimate under the current trademark categories in Germany (and probably US categories as well).
As an aside, the UK trademark office is down overnight (CMG's Samba is used in the UK as well), and the German trademark office charges $2/search, with a $75 minimum. The US PTO web services seem really nice in comparison (and it lists lots of "Samba" trademarks, although all of them seem to be "typed drawings" rather than words).
In any case, another important question will be when CMG applied for their trademark. If Samba (the free SMB implementation) was in common use in Germany before then, it will likely be exempted from claims, even from someone holding a registered trademark, just like it would be in the US.
There are lots of better and cheaper alternatives out there, depending on your needs. You can get yourself a laptop. Or you can build something around a PC-104 or SBC system. Or you can buy a WinCE machine (e.g., the Compaq iPAQ) and install Linux on it.
Besides, I think we have had lots of articles saying that Linux/UNIX sucks as well--but there seems to be some agreement that it sucks less.
Even using Moody's own reasoning and the data he refers to, Linux beats NT by a wide margin. But he misquotes the numbers. How do you suggest one can compete with deliberately erroneous reporting? Perhaps pay Moody more money than Microsoft did?
I guess while the government hasn't quite become "Big Brother" yet, Apple is trying hard to be "Big Brother" to their employees. Yes, the legal system allows them to do this, but that doesn't make it the right thing to do, in particular for a company with the pretensions that Apple has.
Ah, you got the Apache servers that they changed the "Server:" line on to say "Microsoft-IIS/5.0" :-)
For building a web server, for example, it's easy to strip down a Linux system to just a web server and ssh for remote administration, with no other exposures.. Then, the only vulnerabilities you are concerned with are those in the packet filtering code, the web server, and sshd. It's considerably harder to strip down NT to that degree, in particular if you want to keep some kind remote administrability.
Moody is either simply clueless, or he writes deliberately biased pieces. Which leaves me wondering: can't ABC get people with a sense of ethics and some competence anymore?
I was referring to the PageWriter 2000X. It is based on a 68000 and Sun+Motorola were showing them at JavaOne 1999 (and probably 2000 as well). I forget the exact specs, but the JavaOne version had more than 4Mbytes of memory and ran at a decent clock speed. The retail versions have less available memory, but are still pretty powerful.
On my RH6.2 distribution, the SVGA server is about 1.7Mbytes. That's code that's optimized for speed, not space, and includes a lot of extensions and features. The full libX11.a is 1.1Mbytes; most of that stuff isn't needed to write applications for a handheld and would never get linked, and could probably even be stripped out. And toolkits like FLTK show that even a reasonably nice toolkit under X doesn't need to take up a lot of space.
I've run X11 just fine on a 4M 80386 machine, less powerful than the handhelds in use today (in fact, less powerful than a Motorola pager). X11 was designed to run on those kinds of environments. It has a number of provisions for dealing with restrictions on simple devices (e.g., backing store is not guaranteed). And it has acquired surprisingly little extra stuff in its core since those days (although there are lots of useful, loadable, optional modules).
Well, as far as toolkits are concerned, I agree (and so does the article). But X11 is mainly a remote graphics library, and it adapts just fine to whatever screen size you want to use with it. If anything, its pixel-accurate rendering and low level control, which make it an occasional pain to toolkit implementors, are an advantage in such an environment.
I can't think of any widely used windowing system that would be more suitable for the task. But maybe you have some suggestions?
In some places, the X11 code explicitly traded code size for speed on RISC machines (e.g., loop unrolling, etc.), so those are obvious places to make it smaller if you need to squeeze.
Beyond that, there are probably some things that can be cleaned up, and it's good that someone looks at them. But please don't get melodramatic: the savings aren't going to be earth shattering, and they don't have to be. The standard X11 server isn't all that bad. I used to run X11 on a 4Mbyte 80386 (under SVR3) and even that worked just fine; a handheld is going to be faster than that.
Perhaps you are looking at the VSZ and RSS columns in ps? Those are big (64Mbytes on my machine), but they include the shared memory used for the frame buffer and I/O, as well as a lot of internal buffers.
In any case, the reason why you aren't seeing handhelds with eyepieces is that they are still too expensive. When the prices come down, you'll probably first see them on digital cameras. There are also some tricky UI issues.
And it would be bad if it were otherwise. For example, multiple people may have developed the same "intellectual property" at roughly the same time, but only one person will be granted rights. Why should that person own ideas that the other person invested just as much time and effort in? A limited time grant of rights is a compromise. "Intellectual property" is different from physical property for those and many other reasons.
That's not at all clear. Many kinds of swapping may well fall under "fair use". The legal system and legislation will ultimately clarify those issues.
And it is also well worth debating whether content that is decades old, not available commercially, and of social interest, should, in fact, receive copyright protection. 100 years ago, the copyright on many things being swapped would already have run out, and it is well worth discussing (IMO) whether we should bring copyright back into such a more sensible, conservative framework.
If you look at the prices for classical music CDs, where the "great music" is free and the artists are long dead, it shows that that argument is nonsense.
In fact, the classical music CD market shows clearly what is happening: record labels limit the choice of consumers by picking only a few artists, marketing the recordings to the hilt, and charging enormous amounts of money for those CDs. Artists likely don't see much of that. And, frankly, I doubt the situation is much different for other genres.
And why aren't they profitable? For most artists, it can't be the small percentage the artist gets. With digital technology technical production costs are minimal. And pressing CDs is, what, a few cents now? So where does the red ink come from? It must be the money they spend on buyin shelf space, endorsements, artwork, marketing and promoting artists that wouldn't stand a chance by word of mouth or true consumer preferences.
In fact, flooding the market with promotional materials for your product does not add value to the product. Neither does buying shelf space to the exclusion of other, smaller players. So, the lack of profitability is not related to any benefit to the consumer. Rather, the consumer pays record labels to allow them to limit the consumer's choice.
In the past, with limited shelf space, there may have been some justification for this. With on-line music, there is none. The record industry and its money-gobbling corporate structure is an inefficient anachronism, made obsolete by the Internet and technology. Let's hope that they can't use their accumulated wealth to interfere with the free market mechanisms that, rightfully, ought to drive them out of business.
The question is whether it's cost effective for customers to deploy Windows 2000 in that way. There are several components to the cost:
So, can it be done? Sure. And Microsoft needs to do it if they want to play at all. But it is not a convincing demonstration that it's a cost-effective solution.
If I were to start another big web project, I'd still not pick Windows 2000--except for niche server applications, I believe it's still too expensive to license the required MS and non-MS software, and it requires too much manpower to administer. It also doesn't have any place to grow right now: a multiprocessor Xeon is it.
Actually, it shows us one thing: the fact that Microsoft has been playing around with this for, what, three years, suggests that you can't easily create the software for a Hotmail-like service rom scratch and with complete specifications on the NT platform within that time period even if you have unlimited amounts of money and all the Windows expertise in the world. Perhaps that's the most important lesson of that exercise, and something aspiring web startups should take note of.
But that's nonsense and based on selling snake oil. Watermarking technologies fundamentally aren't robust, and even if those kinds of "open" players with some rights management ever made it to the market, within months, people would hack the managed content and make it unmanaged. The industry would then scream "crisis" and "starving artists" and release the next version of the player such that it only plays music that has identifiable keys, keys held by the major record labels and nobody else.
In fact, Shamoon states clearly himself that he doesn't expect open players to survive, so all this other stuff about watermarking etc. is just posturing:
Once that happens, the incentive for hardware providers (often in conglomerates with content providers anyway) to produce players capable of playing open formats will go away, and you'll be left with proprietary formats, proprietary closed-source encoders, and authoring controlled by a few big companies.
Oh, and if that is not enough, after throwing out all your LPs and buying everything in CD format (guaranteed to oxydize out of existence in a few years), we are now supposed to pay for all that music yet again in the form of some future encrypted format that we can do even less with. How greedy can these people get?
On the plus side, their greed may kill their business. More and more musicians will find it easier to just record and publish outside the mainstream media conglomerates. And streaming Internet access (wired and wireless), as well as small, general purpose wearable computers, will make control of player formats meaningless.
What the industry should do is forget about all this player and encryption nonsense and simply gear up for a future in which everybody can have their own personalized radio station, with just enough ads thrown in to cover the costs but not enough to bother people sufficiently to switch to something else.
Oh, yes, that probably means lower profits. But the music industry right now is an anachronism, like weavers or blacksmiths were after the industrial revolution. It used to take lots of sound engineers, record factories, broadcasters, producers, etc. to get a piece of music to the end users. These days, it takes none of that. Of course their profits should be much lower because their product has gone from being a premium product that's difficult to produce and distribute to something that's almost free to produce and distribute.
Even if people had wanted that, they could have used an existing cross-platform toolkit like wxWindows, FLTK, or Tcl/Tk. Even supporting the cross-platform GTK efforts would have been faster. But ultimately, egos apparently got in the way, and the Mozilla team thought they could do better in a year or two with no track record of doing a cross-platform GUI as a group, even though those other groups had been working on cross-platform GUIs for years and delievered several versions, and even though the Mozilla group also had a browser to deliver at the same time.
As for Mozilla needs an editor to do mail, I think it should do neither. Maybe there should be a loosely coupled Mozilla-branded mail client and a loosely coupled Mozilla-branded editor, together with a simple mechanisms for them to exchange data (open a pipe/socket/...). The fact that Netscape comes with an integrated, preferred E-mail client and editor is a disadvantage, not an advantage, because people have their own mailers already.
Mozilla suffers from the typical second system effect and the not-invented-here syndrome. Let's hope that the useful bits and pieces it actually contains will survive in better designed systems like Galeon or TkZilla.
For Modula-3, go to www.m3.org and follow the links (a whole operating system with various network services has been written at it and is still in use at U. Washington). For Ada, you'll have to talk to your local defense contractor; lots of real-time military systems are written in it, so it definitely gets the performance (Ada is a bit too pedestrian for my taste, so I don't follow it much). For Oberon, the entire Oberon operating system, drivers, compiler, web browser, and other things are written in it, and they are open source.
If you haven't noticed, relational database performance on UNIX sucks. It takes milliseconds to get any data out of the damned thing, which is why everybody is using stored procedures, which means they put code back into a single process. I have not seen any TCP/IP stack under UNIX systems that is "split up along process lines"; if the Linux or SystemV TCP/IP stack crashes, so does the whole kernel. Both of these examples make my point.
But it's the kind of wrapping I'm talking about, and it's the kind of wrapping that is necessary to make C++ a safe language.
The problem with C/C++ pointers is not that they model the hardware very closely. The problem is that they aren't typed sufficiently finely: heap and stack allocated arrays, displaced arrays, references to stack variables, references to locations in data structures, heap allocated data structures, etc. are all represented by a single type, a "pointer". Other languages use different static types to represent those different constructs. And those constructs are different because they are associated with different object lifetimes and different opportunities for (optional) runtime error checking.
Adding those extra static types to distinguish the different meanings of "pointers" has no runtime overhead at all. And if you (for some reason) need to convert among the different static types, a call to "unsafe::convert_..." would do the trick, again, with no overhead, and would indicate that something funny was going on.
The way it is in C/C++ right now, the compiler just doesn't have the information to give meaningful compile time warnings or errors. It also doesn't have enough information to insert efficient runtime error checks if the programmer wants that for debugging. Ultimately, the lack of static type information is even counterproductive for generating efficient code on upcoming architectures.
In order to make laws like in the UK that require giving up keys meaningless, I think we should also start keeping random data on our hard drives (e.g., filling the empty blocks with random data) and adding random bits to our communications (for images and speech, the low order bits are usually already random enough). That's good security anyway. Here is a start--or is it a secret message... ?
QUDIHKOO DPKAPOAM REFPQTII ITOXOBWF WANELCSO RCOHRPUJ TZYKTHTB AHYOJUUF UHKFKCUC FIJXXEGR EFBXMUYM CXBMSVSN DCTNFNPK VZHSDOKH TLEFGDRJ ATVSONFR QYEVLUGG TNZXCJFV VJBBNSKN MGFAUKRK JVGUQMBJ AAHCKMXG WYIJRTWD ZCETMVEV
As I said myself, those languages have smaller user communities, and that means they have fewer libraries and tools for them. But you can call C and C++ code from them and they are quiet usable, in particular on Linux.
I don't recommend doing everything in them, but give them a try for some projects, in particular open source projects for Linux. That's the only way this chicken-and-egg problem of moving beyond C++ will get addressed.
They are wrappable only in special cases. They are not wrappable in general.
For example, you can't "wrap" call-by-reference or the address-of operator because smart pointers aren't really pointers--inheritance gets screwed up.
Using string manipulation as a specific example, exactly what about std::string "severely limits language semantics"?
You can make strings reasonably safe, but strings are probably the easiest case. The hard part is data structures that refer to each other.
Sure there is [a way to achieve fault isolation in C++]. See man 2 fork, or CORBA
That's not fault isolation in C++, it's fault isolation in the operating system. That kind of approach has a lot of overhead. That's why programs like Netscape or Emacs are multi-megabyte executables composed of dozens of libraries, rather than a bunch of small, communicating, separate processes.
It also doesn't help a lot, since even running in separate processes, it's really easy for a process to corrupt (e.g., array index error) the data it then sends on to another process via CORBA; you still can't tell who did it in C++.
Whether you believe me or not that fault isolation through processes can't be used in many cases, the fact is that people don't use it, and that alone is indication enough that we need a different mechanism.
No, good programming practices are what prevents bugs. IMHO there isn't much difference between the various type-safe languages in bug prevention, but there is a huge difference between the various programming practices and quality standards.
There isn't much difference among the various type safe languages in terms of bug prevention, but there is a huge difference between them and C/C++.
I have talked with plenty of folks who claim that there's "no performance penalty or other drawbacks" to not having the power of C/C++'s low-level control, but I haven't seen anyone back that up with proof. I would really enjoy for someone, anyone, to prove otherwise.
Go use Modula-3 or Ada or any of the other languages. If you want to, you can write code in them that is identical to C++, including all the unsafe constructs you want: C++ constructs translate one-to-one into those languages.
The difference is that those languages have a well-defined, safe subset that people can use to write programs in.
Of course, the compilers and tools for those languages are inferior to C++--because of their smaller user community. Many Modula-3 compilers don't do cross-module inlining, for example, so they will look worse on benchmarks. But that's a chicken-and-egg problem: because of the small user communities, they compilers don't get better, so everybody keeps suffering with C++.
UNIX started out on a PDP-7, hardware that was less powerful than even the original IBM PC. BSD versions ran just fine on PDP-11 machines with 64k or 128k of RAM and fairly sluggish processors. Xerox PARC had also some version of Smalltalk on early PC hardware, including GUI. People had multitasking systems with hierarchical file systems even on 8bit processors.
In fact, it appears that even IBM had a good multitasking OS ready for the IBM PC. But they couldn't ship it because they had been under investigation by the justice department for tying software and hardware sales.
The limitations of the original PC hardware (which, themselves, were a result of IBM's greed unwillingness to cut into its own business) are no excuse for the lousy design of DOS or Windows.
That's because volume and marketing from IBM drove the cost down, not because of any technical features of DOS/Windows.
The story of Windows is similar. Systems like the Atari ST, the Macintosh, and the Amiga also showed that you could do a lot better than Windows when it came to designing a Windows-like OS (simple, no protection, etc.). Windows again was technically the bottom of the barrel and only caught on because of greed and strategic errors by their competitors, and aggressive marketing and cut-throat business tactics by Microsoft.