Can't be done.... Now we make a master and press the living crap out of that. this digital watermark id? a new master must be created for every pressing.
Imagine how it could work, rather than stating it can't. You are probably right (probably) about not being feasable to make each set of content unique. (But don't assume.)
Assuming you are right, one way it could work is thus. The content is not watermarked, as recorded on the disk. The bits on each disk are identical. But the hardware that plays it will only extract, even at some low level, watermarked data. That is, as the data comes off the disk, the drive watermarks it, even before it ever leaves the drive mechanism and hits your ide cable.
It works kind of how CD Audio and CD Data are different. Data is recorded on the disk differently from "a movie". You must issue one command to the drive mechanism to read sectors of data. You issue different commands to the drive to start the streaming transfer of "a movie". The streaming movie comes out of the drive watermarked with the disk's unique id.
This is just one hypothetical scenerio. I'm sure clever slashdotters could imagine other horrors that these terrorists could embed into our drives.
He who controls the hardware, controls the universe! -- Maud Dibb (or something like that)
That's the beauty of VHS - they're virtually indestructable in the hands of a 3-year-old
While this is true of the tapes, it is not true of the recorders. The slot on the front of a vcr has been carefully designed so that it easily will accept an unwanted peanut butter and jelly sandwich.
Thank goodness the vcrs are now super cheapo.
But, yes, I agree that the tapes are virtually indestructable. Our original Lion King tape has finally bit the dust. But it played for years, even with crayon markings, etc. on the cartridge. Now that LK is available on tape again, it is possible to re-buy it. Now the only question is, do I want to. It seems of less interest to a 9 yr. old. So the original tape served it's purpose and survived the period of early childhood years where it was of major interest.
In high school English, it is much more important to be a grammar and spelling nazi than to worry about literature or poison young minds with subversive notions of literacy and thinking for themselves. Get them to focus on the mechanical details, Montag.
So who gets to decide what information is "obviously harmful" and "has no redeeming value?"
The DeCSS code is obviously harmful (just ask the MPAA!) and has no redeeming value. Piracy is bad. A product of hackers and terrorists in order to enable people to illegally watch movies without the MPAA's blessing on each and every viewing.
And please don't respond with any blasphemy about how corporate profits are not sacred.
Other examples of obviously harmful and no reedeming value:
Software to enable you to read e-books in an uncontrolled manner, including reading bedtime stories aloud!
Compression algorithms which act as enabling technologies so that you can listen to music in an un-sanctioned manner
Speeches on how insecure certian audio watermarks are, which is nothing more than an attempt to embarrass the RIAA and SDMI and show people how to commit serious crimes
Even a respectable corporation like Microsoft wrote an article complaining about the "weapons" that these terrorist hackers reveal to the world without first giving the vendor a several year opportunity to fix the vulnerability, which was only a theoretical vulnerability.
These are all examples of harmful information with no reedeming value.
as far as I can tell there is no legitimate use for a tool designed specifically for DoS attacks
Like the absurdity of the counter argument (I gave above) to my point of view, there is no legitimate use for guns other than to murder people. Obviously, this is wrong. Aren't guns a great way to test bullet proof vests?
Writing a DoS tool is not a crime. Using it on someone else is.
Did you understand my silly counterargument? The reason I wrote it was because it was so stupid. I thought I made this obvious.
Doctors study illness not to cause it, but to cure it.
And hence, we should study weapons and attacks to defend against them. And hence we should be able to study DOS tools, packet sniffers, etc. I did start my post explaining that I completely agreed with the parent post, and than gave a very silly counter argument to it.
For those trivial assignments such as generate a list of fibonacci numbers or primes, or compute the factorial of an arbitrary input number, a fun approach for the lab assistants might be a trivial interpreter which interprets a trival bytecode in which is written the trivial assignment. All as a neat compact little program with an array initializer of the data which actually implements the algorithm. Explain to the prof. how it works.
Writing a DoS tool is not a crime. Using it on someone else is.
I agree. In support of that viewpoint, I would give the following example counter argument.
Guns are bad. Nuclear weapons are bad. Let's remove them both from the military. Studying how these things are built and used is not a worthwhile endevor. Since we don't believe in attacking someone for no reason, we don't need any weapons. We also don't need to study how offensive weapons might be used against us. Therefore there is no reason for their existance. Let's just pass a WMCA (Weapons Millenium Contraband Act) law and outlaw anyone even thinking about how weapons work or how reinforcements might be vulnerable to weapons.
(Disclaimer: I don't own anything which was designed to be used as a weapon; lest someone pigenhole me into a certian group.)
I see (at least) 3 distinct levels, and I'm not sure which one your question addresses.
1. Low level graphics manipulation. I would put X here, although X includes network transparency. What I see at this level is graphics primitives. How to draw a circle, a line, a rectangle, draw characters of text in a certian font, etc.
2. A window manager / widget toolkit. There are already five million of these for Linux. They can be fun to write and educational. But don't have any delusions of gaining significant market/mind share.
3. Human-Computer interaction. User Interface. This is more about human psychology than it is about technology. Read some good books like The Design Of Everyday Things. Apple Human Interface Guidelines. (Apple's developer web site.)
Your question makes fairly clear you aren't interested in (1). But it is ambiguous whether you are interested in (2) or (3). If you're interested in (3), then join either the GNOME or KDE projects and contribute ideas and effort that don't involve writing code.
I'm talking about the UCSD ***>PASCAL not the p-System! SHEESH!
Just to clarify what each is. UCSD Pascal is a compiler, a component of the UCSD p-System. The UCSD p-System is an operating system. The p-System OS and all applications and utilities are executed as p-Code, not native code. The USCD Pascal compiler compiles source programs to p-Code to run on the p-System. I think you already know this, but I just want to point it out.
You know darned well that they first ported the UCSD Pascal system to the Lisa then the Mac, which is why suddenly the topic is the p-system? Sorry, Charlie.
Okay, I'll restate. Apple did not ever port UCSD Pascal to either the Lisa or Mac. They bought a third party 68000 Pascal compiler.
What do you mean by UCSD Pascal system ? There is nothing which goes by that name.
If you mean the p-System, then they did not port that. The Lisa OS was a new OS. The Mac OS was a new OS.
If you mean the USCD Pascal compiler, they did not port that. They bought a third party 68000 Pascal compiler.
What is confusing here?
Even into the late 80's, you could get the "Trident" UCSD Pascal logo to come up, complete with copyright notices from the Reagents of the State of California.
I would not be surprised that the third party 68000 Pascal compiler was at some point derrived from the USCD Pascal p-Code compiler. (In fact, I seem to recall that it was.) But that was not Apple's doing. The fact that the compiler had some licensed source code from the Regents of the University of California, doesn't say anything about Apple's OS. When running the compiler, you might see copyright notices reflecting such.
But what about the OS? I'd sure like to know how to get either the Lisa OS or the Mac OS to display such a copyright notice.
The Lisa and Mac OS'se were based on a port of the original OS of UCSD ***>PASCAL
Are you saying an OS is based on a compiler? Or what?
If you mean the Lisa OS and Mac OS were based on the p-System OS, they were not. I'm more familiar with the Mac OS. Nothing about it is the same. Most obviously the entire GUI philosophy. Most of the code in Mac OS was to do with gui support. Window Manager, Control Manager, Dialog Manager, QuickDraw, Resource Manager, etc., all the managers you had to initialize early in your program. As for the traditional OS parts of the OS, such as memory manager and file manager, the memory manager was nothing like the p-System. The heap worked quite differently. The file manager was based on the notion of a stream of bytes, rather than being block-oriented as in the p-System. There was nothing resembling the limitations of the p-System volumes, 77 files limits, files must be contiguous. Not to mention that the ROM of the original Mac was written in assembly language, with it's functions obeying the stack rules and calling conventions of the Pascal compiler they were using. Everything in the p-System, even the OS itself is p-Code not 68000 code. Is there anything at all, other than possibly superficial resemblances, that you can point out which would indicate that the Mac OS is "based on" or "ported from" the UCSD p-System?
So Let's take a closer look at your long list of Apple's so-called innovations
I'm not suggesting that Apple necessarily invented all of the technologies, but they were way ahead of the curve in bringing many technologies to the masses. I give that list as an example of how Apple was an innovatior, where you claimed they are not.
SOS on Apple///. The point here is that on a machine of the Apple///'s class (128K 6502 microprocessor, floppy disks) nobody had a hierarchical filesystem. I don't know about Xenix, but I certianly know MS didn't. I'm not comparing to Unix. My point is that Apple was an innovator.
GUI on an affordable microcomputer. and no compiler My point is that the Mac was useful to people in a way that traditional computers were not. It started an entire revolution among microcomputers. Sure you could already get gui's on systems that cost more than your house. As for the compiler, yes, you had to cross develop for Mac from a Lisa, for a couple years. So what? Are you suggesting that not having a native compiler somehow makes the mac NOT be an innovation? You don't seem to make any point other than some complaints about the Mac. Just because you might have complaints about something innovative does not make it not innovative. [Yeah, newfangled cars are a pain, got to crank start them, they don't always work, gotta have fuel, etc., etc.] Its obvious that you hate everything about the Mac and Apple. That's not the point I'm debating.
QuickDraw. GUESS YOU NEVER HEARD OF EVANS AND SOUTHERLAND No I have not. Question. I had played with computer graphics in the late 70's on super minicomputers, and in the early pre-Mac 80's on various microcomputers. If QuickDraw was NOT so amazing, then why was nobody else doing what Mac did? QuickDraw was amazing because of it's fundamentally different approach. Not because it was the first graphics package. If you don't see QD's funadmentally different approach, then you've never compared it to everything prior. QD was a raster graphics package, not vector. Powerful and efficient primitives. A different way of thinking about coordinates. Extremely ingenious region algorithms for clipping, filling, etc.
MacPaint was unlike anything before it. Isn't this an example of innovation? The general concept is used in many pixel "paint" type programs today. You complain about it, but don't seem to counter that it is an innovation.
Apple Human Interface Guidelines was a product of much Apple research. Apple did a huge amount of their own user interface research. Testing on groups of non-computer people, etc. Lots of it described. A lot of new work, all at significant expense. I understand this. As a third party developer, never connected to Apple in any way, I managed to earn a copy of an earlier work Apple User Interface Guidelines autographed by Bruce Tognazini.
3-1/2" hard shell floppies. You don't counter my point. You just complain about the fact that programs might request a little bit from disk 1, then from disk 2, then from disk 1, causing the OS to alternately prompt you for each disk. How is this different from an MS DOS program copying from A: to B:, when you only have one floppy drive and B: is simulated on the same drive as A? This is not a deadlock problem. You obviously don't understand the problem. You fail to counter that using 3-1/2" hard shell disks was an innovation.
User friendliness in hardware. Yes, I mean not being able to open it up, for the first 3 years. Look at the problems that Mac users avoided. When the Mac finally did get expansion slots, after Scully made it happen over Jobs resistance, and way later than it should have taken IMO, they did that right too. User friendliness was a concept that went all the way down to the bare metal. Not just a software afterthought. Nonetheless, however much you might complain about the philosophy of not letting users have hardware conflicts or have to know a bunch of technical detail, you still don't counter that it was an Apple innovation.
First to implement SCSI on a cheap microcomputer. Which I had on my Sun workstation for years before that. Did I say the first to implement SCSI ever? Or do you confuse your Sun workstation with a cheap microcomputer? How long did it take rest of the microcomputer industry to adopt SCSI? How was this very early adoption of SCSI not an innovation? Users could just buy an external hard drive and plug it in! No fuss. Compare to how PC users had to add a hard drive. Only internal. Lots of fuss, compatability issues, limits, etc. I merely suggest that adding SCSI to Mac in 1985 was an innovation way ahead of everyone else. You don't seem to counter this other than to point out that SCSI did exist earlier in expensive systems.
Laser Printer with Postscript which kicked off the entire Desktop Publishing revolution. Hey now what a bright idea. Use Adobe's language combined with HP's hardware...oh wait, those were HP printers all along with the apple logo on them Who was Adobe before Apple picked up PostScript and ran with it? I don't know a lot of facts about who made the Laser Printer, I doubt it was HP. Nonetheless, nobody even WAS making laser printers for microcomputers. Apple's was an industry first. Seemless graphical integration with the Mac OS. None of the nonsense that PC users had to go through to print (or even Linux users today in some cases). It is a well established fact that this started the whole desktop publishing revolution. How is this not an Apple innovation?
AppleTalk protocol. You don't seem to counter this one at all. Apple hired some really bright networking guys. Designed an entire network protocol stack, layer on top of layer. Self-configuring routers. Non-technical users could plug-and-play build fairly big networks using AppleTalk. It just magically all worked. Now one might argue that AppleTalk has drawbacks. But wnat doesn't? Most people would not care when they can buy a bunch of computers, cables, routers, plug it all together into a network and it all just works! That's an innovation. You don't say anything about it, other than to complain about a quirk in how Apple put an RS232 port on their laser printer.
High quality color graphics designed by videophiles. Which were better on my Sun, better on my SGI, better on my E&S, better on...just about everything. I'm comparing to microcomputers here. Try comparing the Mac II color graphics in 1987 to the IBM PC CGA, EGA, VGA, and generally inferior monitors, etc. Apples hardware was priced at a premium over PC's, but was far superior in both hardware and the seemless software integration and immediate usability. How is the improved level of color graphics Apple introduced not an innovation? It took MS until Windows 95 to figure out how to properly manage colors as a limited resource when the palette is limited to 256 colors. X still hasn't figured it out AFAIK. I don't mean any slight here, I just mean that there is no systematic way to manage the colors so that the frontmost window can "claim" the hardware color table entries at the expense of the quality of displayed images in the windows which are obscured. I failed to mention QuickDraw32 when Macs were the first to be able to MAKE GOOD USE of 32-bit color graphics cards. (I mean other than run a demo program that says, look! my pc can display a beautiful graphic in 32 bits!)
HyperCard. There was nothing like HyperCard. How is C++ like HyperCard? Do you understand what HyperCard was? Other than the MacSyma you mention, I know what Maple, MatLab, C and C++ are. What possible comparison are you trying to make with HyperCard?
Cheap easy sound input was introduced in about 1990 on the Mac IIsi. There were inexpensive third party (Farallon) solutions (MacRecorder) available a couple years prior. A little box. Just plug it into the computer and you've got sound input. Compare to the fuss of a "sound card" that PC's got. It is also amusing that the sound for some PC programs was captured on a Mac. My point is that Apple was an innovator. Not the quality of their sound. Now how long it took since the first Mac shipped. But that they had cheap easy sound long before anyone else. You don't ofter any counter to this.
Self configuring slots [NuBus]. How long did it take any of them to get a VME bus and 64-bit processing? And since when was a bus standard that nobody else uses a good thing (tm)? You seem to compare to non-microcompter systems a lot. How many PC's have VME bus? How many PCs have 64-bit processing -- even today in 2002? What is your point? A low cost self configuring plug-and-play expansion card bus in 1987 was an innovation. You don't say anything to suggest that it was not. Just plug in an expansion card and it works. No dip switches. No IRQs, I/O addresses, etc. No conflicts. Well I can't run a FooBar card because I've got a Frobulator card installed that uses the same IRQ. How was this not an innovation?
TrueType scalable fonts. I won't compare to other font technologies. I'm sure there were reason for Apple to invent their own. So why did Microsoft license TrueType technology rather than use something else you suggest? Could it possibly be that TrueType was a superior technology? How was this not an innovation for microcomputers? [Bonus: why do Linux gui systems seem to be moving towards TT support? One of several reasons might be availability of a large number of fonts and tools to create them. Obviously a fallout of what Apple, then Microsoft did.] You mention TeX. TeX is not the Mac way. I'm not saying TeX is bad. Just saying its not the vision Apple was working towards. But I'm sure someone will take this as though I'm slighting TeX somehow.
MultiFinder. No mainstream microcomputer OS ran multiple applications at the same time. I know that today it seems laughable. But think back to a time when microcomputers ran one program at a time. You quit it. Then run another program. Switcher and later MultiFinder were true innovations. You could mention Amiga, but that had even less market share than the Mac. At the time of MultiFinder, if I have my timing right, the Amiga was very uncommon, not being promoted anymore. I'm not badmouthing Amiga. Why is this so funny? Compared to the state of the industry at the time, MultiFinder was a big innovation. You don't seem to offer any contrary evidence.
AppleTalk on Ethernet. Choose to run it or not. A lot of people happily ran it because it was SIMPLE, not because it was EFFICIENT. I often notice a huge fixation on efficiency of the computer vs. efficiency of the human. There may be a lot of sound reasons to not run AppleTalk on a very large network. But if I'm setting up an Ethernet with a couple hundred Macs, then nobody complains about AppleTalk. Compare to setting up a PC network of a couple hundred. Talk about $$$$ and need for expertise. With AppleTalk you just plug it in and it works. It was not designed for 10,000 computers or a global network. It is an innovation that solves problems for lots of small networks. You don't offer any counter to the fact that it was an innovation.
QuickTime. not interesting when you've got SGI, expensive Lab, etc. Good for you. As for the tens of millions of people who didn't have an SGI, QuickTime was an innovation. You don't seem to offer any real counterpoint.
MacTCP. I'm not comparing to Unixes. I'm comparing to mainstream microcomputers. Apple's introduction of MacTCP for Mac's was an innovation. Way ahead of Microsoft, who was the only other player at the time. On a Mac, in 1989 I had a Mac on the Internet with a static IP address. I even set up my own NNTP leaf node off of our Sun systems. I asked for and got a sub-domain name off our main domain name for my Mac, etc. The software/hardware on the Mac was all off-the-shelf. And the key word here S-I-M-P-L-E. When did WinSock first appear? How is MacTCP not an innovation in the desktop microcomputer world?
PowerBooks. I won't make a statement that PowerBooks were the first laptops. I don't really know of any that predate it though. I do know that the PowerBook caused a stir in mainstream trade rags. So, let's suppose, that PowerBooks were not an innovation? This makes Apple not a big innovater, as you say.
CD-ROM drives. So your definition of "innovation" is that Apple did it before Microsloth Yes, my definition is that Apple did it way before Microsoft. Like many other things before, you might have had them in a Lab or on an expensive system. But they were not common on desktop microcomputers. Apple made them common. This is an innovation.
PowerPC risc. I think it is obvious that IBM had risc before Apple. After all Apple got PowerPC from IBM. Apple studied several different risc architectures. It was an innovation for Apple to switch their product line to risc. It was even an innovation for them to be able to switch. It was an innovation that they switched seemlessly. You don't offer anything to coutner this. Either you think risc is an innovation or not. If not, then it was not an innovation for expensive systems (Sun) to adopt it either. If so, then Apple was an innovator for being first to bring it to mainstream microcomputers.
QuickDraw 3D. As I recall, there was no widespread standard. 3D was certianly not a common application on microcomputers. It was the domain of much more powerful systems. IIRC, QD3D was the first to realize the promises that OpenGL now is. That is, a universal API that applications can write to and get whatever, if any, hardware assist is available. OpenGL achieves this. But I suspect that QD3D was depolyed and doing this on a larger numerical scale with actual Mac 3D applications befoer OpenGL became the standard. My point is that it was an innovation to bring a 3D API to developers to a computer that was targeted at the masses -- not the domain of expensive systems in labs or studios with huge budgets. In retrospect, I am glad that OpenGL is a cross platform standard and that QD3D is dead. Nonetheless how is this not an innovation?
QuickDraw VR. How many ordinary people had seen or had access to any of this technology prior to QuickTime VR? This question actually is the theme running through all my points here.
In summary, Apple brought lots of technology to the masses before anyone else, and in an affordable way, and in an approachable way. I didn't say invented. I didn't say created. What they did introduce many technologies to people for the first time. Apple seems to be widely recognized as the innovator to follow during those years. Microsoft certianly did.
You haven't really shown that Apple was not an innovator. This was your original claim that I responded to with the long list of Apple innovations.
Apple took UCSD Pascal and ported it to the Lisa then Mac.
What are you talking about?
Apple DID NOT EVER port the UCSD p-System to eithe Lisa or Mac. They bought a third party native 68000 Pascal compiler.
When you compile the source of an OS to a different machine using a different compiler, that is called a PORT of the operating system. How is it not?
Apple never ported an OS to Mac or Lisa. The Lisa OS was written from scratch. Ditto for Mac OS. Both used a different Pascal compiler. In what way is this a port? In what possible way is a newly written OS, which has no resemblance to the p-System, using a totally different compiler (although a similar source language Pascal), a "port"?
If I wrote a new OS which bore no resemblance to *nix, on a new processor architecture, but wrote it in C, compiled using a commercial third party C compiler; then by your definition this would qualify as a "port" of Linux.
Eventually SofTech ported the p-System to the Mac, but it was ugly, had no Mac UI whatsoever, and happened long after the Mac was a commercial product.
Apple paints itself as the big innovator here, but it's not. They're just big rip-off artists, and they're ruining a bad BSD rip-off now just like they ruined a bad UCSD Pascal rip-off.
Let's see now, what are some the long litany of Apple innovations? [Byte magazine said in 1992 that the history of the microcomputer industry was a huge effort to keep up with Apple.]
SOS on Apple/// had a hierarchical file system. A year later when MS-DOS 2 came out, PC Magazine proclaimed MS-DOS 2 as the first microcomputer OS ever to have a tree structured file system.
GUI on an affordable microcomputer (Mac)
QuickDraw, an amazing 23K raster graphics package capable of amazing feats on hardware of the day
MacPaint
Apple Human Interface Guidelines -- product of much research
first to use 3-1/2" hard shell floppies
sound and clock standard (not afterthought as PC)
User friendliness in HARDWARE, not just software. The hardware was designed to be friendly. Thus no IRQ conflicts, which com port for my mouse?, etc.
first to implement SCSI on a cheap microcomputer
Laser Printer with Postscript which kicked off the entire Desktop Publishing revolution
AppleTalk protocol, which could run on cheap twisted pair wire. AppleTalk was more than just a "fileserver". Lots of other network applications. Later, in the PC world, the word "network" was synonomous with "fileserver".
High quality color graphics on Mac II designed by videophiles
HyperCard
Cheap easy sound input
Self-configuring expansion slots. [Texas Instrument's NuBus in 1987 Mac II.] When the Mac finally got expansion slots, they did it right. Nothing to configure, nothing to go wrong. How long did it take PC's to get PCI?
TrueType scalable fonts, subsequently licensed by Microsoft, quashed Adobe's extortionate licensing of Type-1 fonts.
MultiFinder (run multiple applications at the same time on the computer) [but first there had been Switcher to do the same]
AppleTalk protocol running on Ethernet frames in addition to their cheapo twisted pair
QuickTime (which was way ahead of its time -- for hardware of the day)
MacTCP, a tcp/ip implementation before Microsoft was even aware such a thing existed. (Compare when apple.com and microsoft.com were first registered.)
PowerBooks. Later, PC's would become available in a new form called a "laptop". Prior to the PowerBook, there was an even earlier portable Mac called the MacPortable. (Should have been called the ClunkyMacPortable.)
CD-ROM drives (how many more years was it until PC's started getting this feature? Then eventually PC's figured out that they also needed to make their CD's bootable, in a clunky el-torito way.)
PowerPC risc architecture microprocessor, with seamless backward compatibility through emulation, but no noticable performance penalty for emulated software (much of the OS ran under emulation for a long time)
QuickDraw 3D
QuickTime VR
I'm sure I'm leaving some out. But my point is that Apple was a big innovator. For a long time, everything exciting happened first on the Mac.
The first time I used the UCSD p-System (not Pascal System) was on Apple ][ and/// in about 1981. Later on IBM PC. When the IBM PC came out, two different OSes were offered for it: MS-DOS and p-System. The p-System did not run under DOS, but was a bootable OS on its own partition.
We got our p-System from SofTech for the IBM PC. Later, we got it from a Canadian company called NCI. NCI had a source license to the p-System and had made numerous improvements to it. Later we got a DOS-hosted p-System from a company called Datalex.
Meantime, we got a Corvus Concept (anyone remember those beasts?) and it also had the p-System, licensed from SofTech.
Meantime, there were other computers, in fact, just about everything under the sun IIRC, had a port of the p-System.
My understanding had been that demand for the p-System was so high that the simple disk duplication fees that UCSD was charging for it was making so much money that they risked loosing their tax code status and the p-System becomming a profit-making venture. AFAIK the p-System was then licensed to SofTech to market, develop, and commercially exploit. And they did.
So how is this Apple's fault?
This was all fine and dandy until APPLE OFFERED THEM MONEY FOR IT. In exclusive licensing deals which made other companies unable to obtain and implement UCSD Pascal on their machines afterwards.
Apple didn't have exclusive licensing. SofTech had a license, seperate from Apple's. SofTech become the sole place for non-Apple system's to get their p-System from. Other systems did have the UCSD p-System afterwards. IBM. Corvus. NCI. Datalex. I think some other pre-IBMPC era. computers also had the p-System for the remainder of their short lifetimes. The p-System was available for Z80 machines from SofTech as an alternative to CP/M. SofTech sold a "porting" kit with all kinds of useful stuff to help you get the PME ported to other hardware. Source code licenses were available. SofTech's version IV of the p-System was vastly superior to version II that they licensed from UCSD.
So it is Apple's fault that the Regents of the University of California saw the great commercial potential of the p-System and licensed to SofTech?
Apple took UCSD Pascal and ported it to the Lisa then Mac and further developed the UI using ideas copied from Xerox PARC and SUN Windows
Apple never ported UCSD p-System (or its Pascal compiler) to anything other than the Apple ][ or///. The 68000 Pascal compiler Apple had was purchased from a third party. It was so long ago that I cannot remember the name. Apple did experiment with the compiler, dabbling with things such as "Clascal" to do OO on Lisa, but I never saw anything come out of it that was available to us grunt developers.
While Apple's UI was inspired by Xerox Parc, Apple added many genuine new innovations that Parc never had. The menu bar. Dialog boxes. Automatic redrawing of underlying areas when they become exposed by a moved or closed window. Apple contributed many new ideas of their own. Microsoft, by contrast, did not add any innovations to the UI for a very, very long time.
All your corrections to the parent post were correct. But one minor nit...
UCSD Pascal was never ported to either system [Mac or Lisa] AFAIK.
Actually, UCSD p-System was ported to the Mac. Later on by SofTech. It was pretty crummy. We had a p-System application which we ported to a DOS-hosted p-System, thus giving the illusion (very convincingly) that the application was a native DOS app. We put the same app on Mac under SofTech's p-System, and we hated it. Then we developed real mac software instead. Meanwhile, eventually, that p-System application, was ported to MPW Pascal and compiled to native code -- albeit still having a text interface in a window.
I am not aware of UCSD p-System ever being ported to the Lisa OS. (Although there was MacWorks.:-)
Not only was Gracenote's suit without merit, but Roxio might have sent some signals that they would challenge Gracenote's very ownership of the data. Both together would have been, um, bad for Gracenote.
but having the compiler compile itself does not help you to do this - you could introduce such trojans to the compiler and then compile it with some other compiler - the result would be the same.
You miss a critical point. Doing as you suggest requires that you keep the trojan in the source code of the compiler. With an open-source compiler, that trojan is in the source in front of God and everyone, plain for all to see.
Much better is to get the binary of the compiler trojaned in such a way that it will re-trojan subsequent compilations of the compiler; but the compiler source code has no evidence of a trojan.
The java language has built-in limitations that would prevent this. Also, what's the point? Java is a language that is equally poor on all platforms.
There is nothing particularly poor about the language. But that is a matter of opinion. The language certianly has lots of great features, from a certian perspective. Perhaps the implementations are equally poor, but I disagree with this premise also. Some implementations are not so poor as others.
First I'll define some terms. The "Program" is the whole thing. It consists of two major components, the "Code" and the "Data". Both the Code and the Data are written in the language of the Program. The "Payload" is some more code that is reproduced along with the Code, but is not used in printing the entire Program.
The Program starts out with a bunch of data declarations which are the Data. In C, this could be an array declaration with an initializer which contains a bunch of static strings. Then after the Data (in this example, a huge array declaration) comes the Code.
The way the Code works is that it has two sections, one that prints the Data declarations, using the Data declarations; and, a second section that uses the Data to print the Code.
Obviously, the Data is a bunch of strings which make up the source code of the Code and the Payload, but not the entire Program.
I hope this explanation is clear. I haven't actually implemented it, but the explanation should tell you how to do it in a fairly language-neutral way. I hope this wasn't your homework assignment. I hope I didn't make some major blunder due to insufficient caffine. If I have, I'm sure someone here will embarrass me or mod me as Stupid (-2) or something.
I don't think you need to understand this to understand compilers. But understanding this is one element necessary to understand how to trojan a compiler's source code so that when the unmodified source of the compiler is recompiled using the compiler, that the trojan is inserted into the binary output (a new compiler), even though the trojan is no longer present in any of the compiler's source code. The Payload is then useful to further trojan the compiler such that when it compiles the source to the login program, it compiles in a back door, even though the source to the login program has no back door.
Can someone who has had more caffeine plese provide a link to the famous article describing this before I scream.
This is a very interesting viewpoint. Suppose Microsoft planted similar 'bugs' in.NET compilers. Could we use Mono's implementation to find them?
Maybe not. After all, if mono was bootstrapped on C#, then there is the theoretical possibility to propagate stuff into the Free implementation.
Of course, this would require more foresight on MS part than I give them credit for. Plus there is the practical problem of how to you alter your compiler such that it can recognize that it is compiling a competitive but yet unwritten compiler.
How likely it is that you can crash a sat into a target (ground or other sat) is irrelevant. I agree. You probably can't bring down a sat onto a specific target, such as the MS campus.
What I haven't seen posted here yet is what the human reaction would be in the population. Imagine the terror this would cause. Everyone would be afraid of a sat comming down on their head. Can you see daytime talk shows telling people not to go outside, and other such nonsense.
Just look at what the reaction to anthrax was. That was not even militarily significant and look at the fallout. Just like Iraq's scud missles during the 1991 gulf war. Militarily insignificant, but terrorize the population, and expend significant time/effort talking about it.
The only reason that KaZaa are in trouble is because they blocked people who thought that they should share their file sharing software. If they hadn't been so megalomanic, they wouldn't be in this trouble.
There was a movie back in the mid-80's that predicted this. One of the major plot elements was that this mega corp came up with a way to render computer generated actors that looked completely real.
When I saw Final Fantasy, I remembered back to the movie Looker.
Of course, the other major plot element was that now that they could make human actors obsolete, they started killing off all of the humans who looked "perfect". Young women who were "lookers" would suddenly turn up dead. The monopolistic mega corps wanted to have a monopoly on actors, and saw no problem with this.
Up until some years ago I still could find the movie in larger video stores. Haven't seen it on the shelves lately though. (Probably a mega corp conspiracy.)
Perhaps a question that RMS and other free software advocates should ask themselves is: Why do some people choose to run non-free software?
To be clear, let me state several things. I'm not talking about people who don't conciously make a choice. (i.e. I run Microsoft because it came with my PC.) I'm talking about people who make an informed choice to run (some) non-free software.
I'm not against non-free software, although I prefer free software, when it offers a viable alternative. (This last sentence, strongly hinting at my answer to the first question I asked above.)
My supposed answer to my question is: people choose non-free software when there is no free alternative, or when the free alternative is not up to par with the non-free alternative, and it is therefore *much* cheaper to use the non-free software. Imagine that. Is it possible that in certian settings, non-free could be cheaper dollar wise, than free? I said I prefer free. But some people need to take their blinders off and recognize that free software does not (yet?) provide acceptable solutions for every person for every possible problem to be solved, in every possible setting. Maybe someday it will, and I'll be glad to see it.
Slashdot Mirror
Abide by MS's rules.
Don't release CIFS code under the GPL. Instead, write a new license that is extremely similar.
Can't be done.... Now we make a master and press the living crap out of that. this digital watermark id? a new master must be created for every pressing.
Imagine how it could work, rather than stating it can't. You are probably right (probably) about not being feasable to make each set of content unique. (But don't assume.)
Assuming you are right, one way it could work is thus. The content is not watermarked, as recorded on the disk. The bits on each disk are identical. But the hardware that plays it will only extract, even at some low level, watermarked data. That is, as the data comes off the disk, the drive watermarks it, even before it ever leaves the drive mechanism and hits your ide cable.
It works kind of how CD Audio and CD Data are different. Data is recorded on the disk differently from "a movie". You must issue one command to the drive mechanism to read sectors of data. You issue different commands to the drive to start the streaming transfer of "a movie". The streaming movie comes out of the drive watermarked with the disk's unique id.
This is just one hypothetical scenerio. I'm sure clever slashdotters could imagine other horrors that these terrorists could embed into our drives.
He who controls the hardware, controls the universe! -- Maud Dibb (or something like that)
That's the beauty of VHS - they're virtually indestructable in the hands of a 3-year-old
While this is true of the tapes, it is not true of the recorders. The slot on the front of a vcr has been carefully designed so that it easily will accept an unwanted peanut butter and jelly sandwich.
Thank goodness the vcrs are now super cheapo.
But, yes, I agree that the tapes are virtually indestructable. Our original Lion King tape has finally bit the dust. But it played for years, even with crayon markings, etc. on the cartridge. Now that LK is available on tape again, it is possible to re-buy it. Now the only question is, do I want to. It seems of less interest to a 9 yr. old. So the original tape served it's purpose and survived the period of early childhood years where it was of major interest.
This thread sums it up.
In high school English, it is much more important to be a grammar and spelling nazi than to worry about literature or poison young minds with subversive notions of literacy and thinking for themselves. Get them to focus on the mechanical details, Montag.
The DeCSS code is obviously harmful (just ask the MPAA!) and has no redeeming value. Piracy is bad. A product of hackers and terrorists in order to enable people to illegally watch movies without the MPAA's blessing on each and every viewing.
And please don't respond with any blasphemy about how corporate profits are not sacred.
Other examples of obviously harmful and no reedeming value:
- Software to enable you to read e-books in an uncontrolled manner, including reading bedtime stories aloud!
- Compression algorithms which act as enabling technologies so that you can listen to music in an un-sanctioned manner
- Speeches on how insecure certian audio watermarks are, which is nothing more than an attempt to embarrass the RIAA and SDMI and show people how to commit serious crimes
- Even a respectable corporation like Microsoft wrote an article complaining about the "weapons" that these terrorist hackers reveal to the world without first giving the vendor a several year opportunity to fix the vulnerability, which was only a theoretical vulnerability.
These are all examples of harmful information with no reedeming value.as far as I can tell there is no legitimate use for a tool designed specifically for DoS attacks
Like the absurdity of the counter argument (I gave above) to my point of view, there is no legitimate use for guns other than to murder people. Obviously, this is wrong. Aren't guns a great way to test bullet proof vests?
Writing a DoS tool is not a crime. Using it on someone else is.
Did you understand my silly counterargument? The reason I wrote it was because it was so stupid. I thought I made this obvious.
Doctors study illness not to cause it, but to cure it.
And hence, we should study weapons and attacks to defend against them. And hence we should be able to study DOS tools, packet sniffers, etc. I did start my post explaining that I completely agreed with the parent post, and than gave a very silly counter argument to it.
For those trivial assignments such as generate a list of fibonacci numbers or primes, or compute the factorial of an arbitrary input number, a fun approach for the lab assistants might be a trivial interpreter which interprets a trival bytecode in which is written the trivial assignment. All as a neat compact little program with an array initializer of the data which actually implements the algorithm. Explain to the prof. how it works.
Writing a DoS tool is not a crime. Using it on someone else is.
I agree. In support of that viewpoint, I would give the following example counter argument.
Guns are bad. Nuclear weapons are bad. Let's remove them both from the military. Studying how these things are built and used is not a worthwhile endevor. Since we don't believe in attacking someone for no reason, we don't need any weapons. We also don't need to study how offensive weapons might be used against us. Therefore there is no reason for their existance. Let's just pass a WMCA (Weapons Millenium Contraband Act) law and outlaw anyone even thinking about how weapons work or how reinforcements might be vulnerable to weapons.
(Disclaimer: I don't own anything which was designed to be used as a weapon; lest someone pigenhole me into a certian group.)
I see (at least) 3 distinct levels, and I'm not sure which one your question addresses.
1. Low level graphics manipulation. I would put X here, although X includes network transparency. What I see at this level is graphics primitives. How to draw a circle, a line, a rectangle, draw characters of text in a certian font, etc.
2. A window manager / widget toolkit. There are already five million of these for Linux. They can be fun to write and educational. But don't have any delusions of gaining significant market/mind share.
3. Human-Computer interaction. User Interface. This is more about human psychology than it is about technology. Read some good books like The Design Of Everyday Things. Apple Human Interface Guidelines. (Apple's developer web site.)
Your question makes fairly clear you aren't interested in (1). But it is ambiguous whether you are interested in (2) or (3). If you're interested in (3), then join either the GNOME or KDE projects and contribute ideas and effort that don't involve writing code.
Just to clarify what each is. UCSD Pascal is a compiler, a component of the UCSD p-System. The UCSD p-System is an operating system. The p-System OS and all applications and utilities are executed as p-Code, not native code. The USCD Pascal compiler compiles source programs to p-Code to run on the p-System. I think you already know this, but I just want to point it out.
You know darned well that they first ported the UCSD Pascal system to the Lisa then the Mac, which is why suddenly the topic is the p-system? Sorry, Charlie.
Okay, I'll restate. Apple did not ever port UCSD Pascal to either the Lisa or Mac. They bought a third party 68000 Pascal compiler.
What do you mean by UCSD Pascal system ? There is nothing which goes by that name.
If you mean the p-System, then they did not port that. The Lisa OS was a new OS. The Mac OS was a new OS.
If you mean the USCD Pascal compiler, they did not port that. They bought a third party 68000 Pascal compiler.
What is confusing here?
Even into the late 80's, you could get the "Trident" UCSD Pascal logo to come up, complete with copyright notices from the Reagents of the State of California.
I would not be surprised that the third party 68000 Pascal compiler was at some point derrived from the USCD Pascal p-Code compiler. (In fact, I seem to recall that it was.) But that was not Apple's doing. The fact that the compiler had some licensed source code from the Regents of the University of California, doesn't say anything about Apple's OS. When running the compiler, you might see copyright notices reflecting such.
But what about the OS? I'd sure like to know how to get either the Lisa OS or the Mac OS to display such a copyright notice.
The Lisa and Mac OS'se were based on a port of the original OS of UCSD ***>PASCAL
Are you saying an OS is based on a compiler? Or what?
If you mean the Lisa OS and Mac OS were based on the p-System OS, they were not. I'm more familiar with the Mac OS. Nothing about it is the same. Most obviously the entire GUI philosophy. Most of the code in Mac OS was to do with gui support. Window Manager, Control Manager, Dialog Manager, QuickDraw, Resource Manager, etc., all the managers you had to initialize early in your program. As for the traditional OS parts of the OS, such as memory manager and file manager, the memory manager was nothing like the p-System. The heap worked quite differently. The file manager was based on the notion of a stream of bytes, rather than being block-oriented as in the p-System. There was nothing resembling the limitations of the p-System volumes, 77 files limits, files must be contiguous. Not to mention that the ROM of the original Mac was written in assembly language, with it's functions obeying the stack rules and calling conventions of the Pascal compiler they were using. Everything in the p-System, even the OS itself is p-Code not 68000 code. Is there anything at all, other than possibly superficial resemblances, that you can point out which would indicate that the Mac OS is "based on" or "ported from" the UCSD p-System?
So Let's take a closer look at your long list of Apple's so-called innovations
I'm not suggesting that Apple necessarily invented all of the technologies, but they were way ahead of the curve in bringing many technologies to the masses. I give that list as an example of how Apple was an innovatior, where you claimed they are not.
In summary, Apple brought lots of technology to the masses before anyone else, and in an affordable way, and in an approachable way. I didn't say invented. I didn't say created. What they did introduce many technologies to people for the first time. Apple seems to be widely recognized as the innovator to follow during those years. Microsoft certianly did.
You haven't really shown that Apple was not an innovator. This was your original claim that I responded to with the long list of Apple innovations.
It seems to me like there is a group of dedicated people doing active development on GCC.
What are you talking about?
Apple DID NOT EVER port the UCSD p-System to eithe Lisa or Mac. They bought a third party native 68000 Pascal compiler.
When you compile the source of an OS to a different machine using a different compiler, that is called a PORT of the operating system. How is it not?
Apple never ported an OS to Mac or Lisa. The Lisa OS was written from scratch. Ditto for Mac OS. Both used a different Pascal compiler. In what way is this a port? In what possible way is a newly written OS, which has no resemblance to the p-System, using a totally different compiler (although a similar source language Pascal), a "port"?
If I wrote a new OS which bore no resemblance to *nix, on a new processor architecture, but wrote it in C, compiled using a commercial third party C compiler; then by your definition this would qualify as a "port" of Linux.
Eventually SofTech ported the p-System to the Mac, but it was ugly, had no Mac UI whatsoever, and happened long after the Mac was a commercial product.
Apple paints itself as the big innovator here, but it's not. They're just big rip-off artists, and they're ruining a bad BSD rip-off now just like they ruined a bad UCSD Pascal rip-off.
Let's see now, what are some the long litany of Apple innovations? [Byte magazine said in 1992 that the history of the microcomputer industry was a huge effort to keep up with Apple.]
I'm sure I'm leaving some out. But my point is that Apple was a big innovator. For a long time, everything exciting happened first on the Mac.
Apple *bought* the UCSD Pascal system
/// in about 1981. Later on IBM PC. When the IBM PC came out, two different OSes were offered for it: MS-DOS and p-System. The p-System did not run under DOS, but was a bootable OS on its own partition.
The first time I used the UCSD p-System (not Pascal System) was on Apple ][ and
We got our p-System from SofTech for the IBM PC. Later, we got it from a Canadian company called NCI. NCI had a source license to the p-System and had made numerous improvements to it. Later we got a DOS-hosted p-System from a company called Datalex.
Meantime, we got a Corvus Concept (anyone remember those beasts?) and it also had the p-System, licensed from SofTech.
Meantime, there were other computers, in fact, just about everything under the sun IIRC, had a port of the p-System.
My understanding had been that demand for the p-System was so high that the simple disk duplication fees that UCSD was charging for it was making so much money that they risked loosing their tax code status and the p-System becomming a profit-making venture. AFAIK the p-System was then licensed to SofTech to market, develop, and commercially exploit. And they did.
So how is this Apple's fault?
This was all fine and dandy until APPLE OFFERED THEM MONEY FOR IT. In exclusive licensing deals which made other companies unable to obtain and implement UCSD Pascal on their machines afterwards.
Apple didn't have exclusive licensing. SofTech had a license, seperate from Apple's. SofTech become the sole place for non-Apple system's to get their p-System from. Other systems did have the UCSD p-System afterwards. IBM. Corvus. NCI. Datalex. I think some other pre-IBMPC era. computers also had the p-System for the remainder of their short lifetimes. The p-System was available for Z80 machines from SofTech as an alternative to CP/M. SofTech sold a "porting" kit with all kinds of useful stuff to help you get the PME ported to other hardware. Source code licenses were available. SofTech's version IV of the p-System was vastly superior to version II that they licensed from UCSD.
So it is Apple's fault that the Regents of the University of California saw the great commercial potential of the p-System and licensed to SofTech?
Apple took UCSD Pascal and ported it to the Lisa then Mac and further developed the UI using ideas copied from Xerox PARC and SUN Windows
///. The 68000 Pascal compiler Apple had was purchased from a third party. It was so long ago that I cannot remember the name. Apple did experiment with the compiler, dabbling with things such as "Clascal" to do OO on Lisa, but I never saw anything come out of it that was available to us grunt developers.
Apple never ported UCSD p-System (or its Pascal compiler) to anything other than the Apple ][ or
While Apple's UI was inspired by Xerox Parc, Apple added many genuine new innovations that Parc never had. The menu bar. Dialog boxes. Automatic redrawing of underlying areas when they become exposed by a moved or closed window. Apple contributed many new ideas of their own. Microsoft, by contrast, did not add any innovations to the UI for a very, very long time.
All your corrections to the parent post were correct. But one minor nit...
:-)
UCSD Pascal was never ported to either system [Mac or Lisa] AFAIK.
Actually, UCSD p-System was ported to the Mac. Later on by SofTech. It was pretty crummy. We had a p-System application which we ported to a DOS-hosted p-System, thus giving the illusion (very convincingly) that the application was a native DOS app. We put the same app on Mac under SofTech's p-System, and we hated it. Then we developed real mac software instead. Meanwhile, eventually, that p-System application, was ported to MPW Pascal and compiled to native code -- albeit still having a text interface in a window.
I am not aware of UCSD p-System ever being ported to the Lisa OS. (Although there was MacWorks.
Not only was Gracenote's suit without merit, but Roxio might have sent some signals that they would challenge Gracenote's very ownership of the data. Both together would have been, um, bad for Gracenote.
but having the compiler compile itself does not help you to do this - you could introduce such trojans to the compiler and then compile it with some other compiler - the result would be the same.
You miss a critical point. Doing as you suggest requires that you keep the trojan in the source code of the compiler. With an open-source compiler, that trojan is in the source in front of God and everyone, plain for all to see.
Much better is to get the binary of the compiler trojaned in such a way that it will re-trojan subsequent compilations of the compiler; but the compiler source code has no evidence of a trojan.
The java language has built-in limitations that would prevent this. Also, what's the point? Java is a language that is equally poor on all platforms.
There is nothing particularly poor about the language. But that is a matter of opinion. The language certianly has lots of great features, from a certian perspective. Perhaps the implementations are equally poor, but I disagree with this premise also. Some implementations are not so poor as others.
My (untested) solution.
First I'll define some terms. The "Program" is the whole thing. It consists of two major components, the "Code" and the "Data". Both the Code and the Data are written in the language of the Program. The "Payload" is some more code that is reproduced along with the Code, but is not used in printing the entire Program.
The Program starts out with a bunch of data declarations which are the Data. In C, this could be an array declaration with an initializer which contains a bunch of static strings. Then after the Data (in this example, a huge array declaration) comes the Code.
The way the Code works is that it has two sections, one that prints the Data declarations, using the Data declarations; and, a second section that uses the Data to print the Code.
Obviously, the Data is a bunch of strings which make up the source code of the Code and the Payload, but not the entire Program.
I hope this explanation is clear. I haven't actually implemented it, but the explanation should tell you how to do it in a fairly language-neutral way. I hope this wasn't your homework assignment. I hope I didn't make some major blunder due to insufficient caffine. If I have, I'm sure someone here will embarrass me or mod me as Stupid (-2) or something. I don't think you need to understand this to understand compilers. But understanding this is one element necessary to understand how to trojan a compiler's source code so that when the unmodified source of the compiler is recompiled using the compiler, that the trojan is inserted into the binary output (a new compiler), even though the trojan is no longer present in any of the compiler's source code. The Payload is then useful to further trojan the compiler such that when it compiles the source to the login program, it compiles in a back door, even though the source to the login program has no back door.
Can someone who has had more caffeine plese provide a link to the famous article describing this before I scream.
This is a very interesting viewpoint. Suppose Microsoft planted similar 'bugs' in .NET compilers. Could we use Mono's implementation to find them?
Maybe not. After all, if mono was bootstrapped on C#, then there is the theoretical possibility to propagate stuff into the Free implementation.
Of course, this would require more foresight on MS part than I give them credit for. Plus there is the practical problem of how to you alter your compiler such that it can recognize that it is compiling a competitive but yet unwritten compiler.
Nonetheless, an amusing idea.
How likely it is that you can crash a sat into a target (ground or other sat) is irrelevant. I agree. You probably can't bring down a sat onto a specific target, such as the MS campus.
What I haven't seen posted here yet is what the human reaction would be in the population. Imagine the terror this would cause. Everyone would be afraid of a sat comming down on their head. Can you see daytime talk shows telling people not to go outside, and other such nonsense.
Just look at what the reaction to anthrax was. That was not even militarily significant and look at the fallout. Just like Iraq's scud missles during the 1991 gulf war. Militarily insignificant, but terrorize the population, and expend significant time/effort talking about it.
The only reason that KaZaa are in trouble is because they blocked people who thought that they should share their file sharing software. If they hadn't been so megalomanic, they wouldn't be in this trouble.
Can you please elaborate? How is this so?
There was a movie back in the mid-80's that predicted this. One of the major plot elements was that this mega corp came up with a way to render computer generated actors that looked completely real.
When I saw Final Fantasy, I remembered back to the movie Looker.
Of course, the other major plot element was that now that they could make human actors obsolete, they started killing off all of the humans who looked "perfect". Young women who were "lookers" would suddenly turn up dead. The monopolistic mega corps wanted to have a monopoly on actors, and saw no problem with this.
Up until some years ago I still could find the movie in larger video stores. Haven't seen it on the shelves lately though. (Probably a mega corp conspiracy.)
Perhaps a question that RMS and other free software advocates should ask themselves is: Why do some people choose to run non-free software?
To be clear, let me state several things. I'm not talking about people who don't conciously make a choice. (i.e. I run Microsoft because it came with my PC.) I'm talking about people who make an informed choice to run (some) non-free software.
I'm not against non-free software, although I prefer free software, when it offers a viable alternative. (This last sentence, strongly hinting at my answer to the first question I asked above.)
My supposed answer to my question is: people choose non-free software when there is no free alternative, or when the free alternative is not up to par with the non-free alternative, and it is therefore *much* cheaper to use the non-free software. Imagine that. Is it possible that in certian settings, non-free could be cheaper dollar wise, than free? I said I prefer free. But some people need to take their blinders off and recognize that free software does not (yet?) provide acceptable solutions for every person for every possible problem to be solved, in every possible setting. Maybe someday it will, and I'll be glad to see it.