I fail to see the point, all of these schemes get cracked in no time. SCMS, Macrovision, PSX and Saturn country code lock-outs and copy protection regimes, even hardware lockouts, et. al., have all been defeated.
It doesn't matter. You can't buy devices that do this in the consumer electronics store in the mall. So it doesn't exist. Just because a handful of high-tech wunderkinds have the ability to crack this stuff doesn't mean it will ever find its way into the hands of the general public -- which is the only time it actually matters.
Any chimp with even a modicum of technical knowledge can circumnavigate these truly pathetic measures.
You're on crack. This means that you and your friends, members of the technological priesthood all, will be able to pirate music. That's all well and good for you. But it does not mean that any lasting change will have been effected in the way the music industry operates. It does not mean that the artists will stop getting screwed the way they are today.
This is how much each player got paid at the end of the game.
Record company: $710,000 Producer: $90,000 Manager: $51,000 Studio: $52,000 Previous label: $50,000 Agent: $7,5000 Lawyer: $12,000 Band member net income each: $4,031.25
The band is not 1/4 of the way through its contract, has made the music industry more than 3 million dollars richer, but is in the hole $14,000 on royalties. The band members have each earned about 1/3 as much as they would working at a 7-11, but they got to ride in a tour bus for a month.
Keep in mind that only devices that adhere to the SDMI specs will be affected. Now, if you were a manufacturer, what incentive would you have to follow this if it only means a smaller selection of music that your customers can listen to?
A nice theory, but DVD players are a counter-example. It's very difficult to buy a DVD player that is not region-coded. Yes, you can buy them, but only mail-order, and they cost 3x as much as normal players. They're irrelevant.
Likewise, you don't see any commercial VCRs with built-in Macrovision suppression. You can buy devices that do it, but only from shady operators with small ads in the back pages of video magazines.
Such things never hit the mainstream, because the content providers and hardware manufacturers and (more importantly) hardware distributors are all in bed with each other.
DUH! I think if you look a little at that "fast scrolling Windoze program" you will find it is using the WIN32 API and not directly writing it's characters to some frame buffer.
After making a function call analagous to what one would do in X, it drops into a library that eventually puts bits in video memory. In the same process. With X, after dropping into that library, some bits get written to a socket, then some time later the X server becomes runnable, reads from that socket, puts bits in video memory, and (depending on the operation) sends a reply back to the (waiting) client. And things get even worse when window creation is involved, because then you get to play hot-potato with a third process, the window manager.
The WIN32 API is exactly equivalent to the Xlib api.
At a superficial level, yes, but the reality of the situation is that one could not have an implementation of X that transparently gave the performance characteristics of a library that didn't implicitly have a client/server model underneath it. That is, the fact that the client program and the frame buffer might be on separate machines permeates all of X. You can't escape it: that design decision influenced many aspects of the API.
So organziations cludged their way through psuedo-OOP GUIs like X/Xt/Motif and SunView.
There is nothing ``pseudo'' about the object-orientedness of Xt and the toolkits built on top of it (Motif and Athena.) The object system they use includes method inheritance (single-inheritance only), runtime typing, and the usual bag of goodies. It's primitive, but it is every bit as object-oriented as anything else that claims that name.
You are right that there is nothing object-oriented about X -- because X is an on-the-wire protocol, and so low level that hardly anybody programs in it directly anyway. That's what toolkits are for.
I suspect that you are laboring under the misapprehension that for something to be ``object oriented'' a so-called ``object-oriented language'' has to be involved. There is no such thing as an ``object-oriented language.'' OO is a programming style, not a syntax. There are some languages that provide useful tools that make an OO style easier to use (like Java, CLOS, and Smalltalk) and there are some languages that provide a huge set of broken and useless tools that get in your way and screw you if you try to use any of them (like C++). But you can write object-oriented code in any language, and you can write assembler in any language too.
GUIs are natural application for OOPs with their hierachical data structures, dynamic memory usage, etc.
This is true. Which is why that's how Xt and Motif and Athena are written, and how one programs in them.
Motif and Athena both suck in their own ways, but the problems have nothing to do with whether they are object-oriented or not. Motif's problems are that it's huge, overly complicated, and insanely buggy. Athena's problems are that it is missing important features, and it has an insanely ugly and hostile look-and-feel. (And both of them use Xrm, the X Resource Manager, which is a completely separate disaster.)
But both (all three) of these toolkits are most assuredly object-oriented. Which just goes to show that being object-oriented doesn't make everything wonderful, like some people seem to assume.
I've spent most of the last ten years squeezing performance out of X programs, and I'm here to tell you that having network transparency as a goal was X's single biggest design flaw.
Go sit down in front of a Windows box and scroll a page of text. Pretty mind-blowing how fast it is, isn't it? You know why? Because the underlying implementation has access to a frame buffer! It doesn't have to squirt all its bits through a straw, hitting at least three processes along the way, and all the blocking and context-switching that that brings with it.
Sure, X has optional ways to sometimes get at the frame buffer, and on some systems in some circumstsances, they even work. After you've written your program's rendering engine twice, once for each method.
X's second biggest design flaw is it's lack of user interface policy. ``There's more than one way to do it'' and they're all different and most of them suck. Most Linux fanboys come from the ``real programmer'' school and hold customizability as the holy grail -- it doesn't matter if the system is completely unusable out of the box, because they see that as an opportunity to tweak the hell out of it for their own use. And maybe some of them will even come up with something usable. For themselves.
Well I'm here to tell you that customizability is a cop-out. ``I'll make it an option'' is almost always another way of saying ``I didn't design it right in the first place, so I'll force the end user to finish designing the program for me.''
Perhaps there are some people who hate Unix and X out of kurmudgeonly spite, but I'm not one of them. I hate them because I've got the scars, and I know where the bodies are buried.
Now this is where someone chimes in, ``well if you hate X and Unix so much, what's better?'' That's the wrong question. Just because B is worse than A doesn't mean that A doesn't suck, and isn't fully worthy of the criticism it receives.
Well, someone had to post this. I first saw this message in, I think, 1987. I don't know where it originated.
OFFICIAL NOTICE - POST IMMEDIATELY
X
DANGEROUS VIRUS
First, a little history. The X window system escaped from Project Athena at MIT where it was being held in isolation. When notified, MIT stated publicly that "MIT assumes no responsibility....". This is a very disturbing statement. It then infiltrated Digital Equipment Corporation, where it has since corrupted the technical judgement of this organization.
After sabotaging Digital Equipment Corporation, a sinister X consortium was created to find a way to use X as part of a plan to dominate and control interactive window systems. X windows is sometimes distributed by this secret consortium free of charge to unsuspecting victims. The destructive cost of X can not even be guessed.
X is truly obese - whether it's mutilating your hard disk or actively infesting your system, you can be sure its up to no good. Innocent users need to be protected from this dangerous virus. Even as you read this, the X source distribution and the executable environment created is being maintained on hundreds of computers - maybe even your own.
Digital Equipment Corporation is already shipping machines that carry this dreaded infestation. It must be destroyed.
This is what happens when software with good intentions goes bad. It victimizes innocent users by distorting their perception of what is and what is not good software. This malignant window system must be destroyed.
Ultimately DEC and MIT must be held accountable for this heinous _software crime_, brought to justice, and made to pay for a _software cleanup_. Until DEC and MIT answer to these charges, they both should be assumed to be protecting dangerous software criminals.
DON'T BE FOOLED!! JUST SAY NO TO X.
X windows. A mistake carried out to perfection. X windows. Dissatisfaction guaranteed. X windows. Don't get frustrated without it. X windows. Even your dog won't like it. X windows. Flakey and built to stay that way. X windows. Complex nonsolutions to simple nonproblems. X windows. Flawed beyond belief. X windows. Form follows malfunction. X windows. Garbage at your fingertips. X windows. Ignorance is our most important reesource. X windows. It could be worse, but it'll take time. X windows. It could happen to you. X windows. Japan's secret weapon. X windows. Let it get in YOUR way. X windows. Live the nightmare. X windows. More than enough rope. X windows. Never had it. Never will. X windows. No hardware is safe. X windows. Power tools for Power Fools. X windows. Power tools for power losers. X windows. Putting new limits on productivity. Simplicity made complex. X windows. The Cutting Edge of Obsolescence. X windows. The art of incompetence. X windows. The defacto substandard. X windows. The first fully modular software disaster. X windows. The joke that kills. X windows. The problem for your problem. X windows. There's got to be a better way. X windows. Warn your friends about it. X windows. You'd better sit down. X windows. You'll envy the dead.
as far as I remember, there is a step-by-step description how to configure.
Where? I haven't found it.
i would suggest not to do this during startup, as you would immediatly reveal that you have crypted data.
Then you believe in security through obscurity. Security through obscurity doesn't work. Repeat it until you believe it.
I think the power of such software relies on the fact, that it is NOT stuffed into a corset of GUI and foolproof(impossible) usage.
Then you believe that software is made more powerful by being obscure enough that only a vanishingly tiny minority of potential users are able to use it. You believe that software that is used by a thousand people is, for that reason, more powerful than software that is used by a million people.
You are wrong.
The more people who use crypto, the more effective cryptography will be for everybody. If one has to even understand what ``NFS'' is in order to install a package like this, then it's still too hard.
That's why PGP and S/MIME are still so marginal that they can be completely discounted: only gurus use them, because they aren't so completely transparent that you don't even know that they're there until they have something to warn you about.
Designing easy-to-use interfaces for crypto is one of the hardest UI tasks there is -- I know, I've tried. But, if you believe in cryptography at all, it's also one of the most important.
And something called TCFS that claims to be an ``improved'' version of CFS.
There is something notable missing from all of these pages: simple, easy-to-follow instructions on how to install and effectively (and securely!) use a file system like this.
From the dearth of documentation, I get the feeling that this has only ever been attempted by file-system gurus, which means that I wouldn't even want to consider attempting it, because reformatting my disk and reinstalling the system is not something I look forward to.
Here is what I would like to end up with:
I power on my machine;
Early in the boot process, it prompts me for a pass-phrase;
If I don't type the correct one, the machine is useless, and all non-trivial data on the disk is encrypted;
If I do type the pass-phrase, the machine boots up normally;
When I put the machine into suspend mode, it again prompts me for a pass-phrase when I try and un-suspend. If I don't type it, the machine remains effectively halted until I get it right.
Is this dream even remotely realizable?
Basically, the situation I want to protect against is simply that of the laptop being stolen while I'm away from the keyboard -- whether it is powered on at the time, or powered off.
The problem here is that the usual crypto-heads are the types who use ssh and pgp and are already used to having to perform nontrivial system-administration tasks to get things up and running, and who don't mind wading through a command-line alphabet soup to do simple tasks, all day long. What we need is someone who is both a crypto-head, and who understands that their agenda is best served by taking the time to make this software be drool-proof.
It doesn't matter how good the math is if no real users are actually using it. Crypto is only effective if widely deployed. If not, those few who use crypto stand out for targetting.
I hadn't heard of Xinerama before. I found a brief description about it on x.org. It sounds fairly limited:
15. Xinerama
The Xinerama extension provides a way for a multi-headed system to function as one large screen. Windows can span multiple screens and can move from one screen to another.
Currently, the Xinerama Extension works in a homogeneous graphics environment. A graphics environment is considered homogeneous if, for example, all of the graphics cards have 8 planes with 6 visuals. Mixing a 24-plane graphics card with a 8-plane card creates a heterogeneous environment.
Unlike other multiple screen implementations, Xinerama provides a solution at the device-independent level. The advantage of this approach is that it reduces the amount of work involved in supporting and maintaining the extension. The number of graphics devices on the market continues to grow; embedding the extension functionality into the device dependent code for each device would be a maintenance nightmare. Since the Xinerama implementation does not require any low-level graphics modifications, existing device-dependent code does not have to be recompiled. In the loadable server world, the Xinerama Extension will work with existing device-dependent shared libraries.
The Xinerama extension is not a standard. It is neither an X Consortium standard nor an X Project Team specification.
I remember, years ago, being blown away when someone showed me a Macintosh with multiple monitors, one of which was a low-resolution 1-bit screen, and the other of which was a giant color screen. They dragged a window so that half was on one screen and half was on the other -- and both sides of the window displayed properly.
I doubt X will ever be able to do that. I think it would require major protocol and API changes.
As far as I'm concerned, this is the best news in their announcement:
8-bit PseudoColor overlays when running in a TrueColor mode (on selected hardware).
This is something SGI has done forever, and it's just incredibly convenient. It's so much nicer to be able to have the default visual be an 8-bit colormapped visual, but have it be possible for specific applications to use 24-bit color as needed. Most applications don't need TrueColor, so all that memory is just wasted on them. And there are things you can do in PseudoColor that are just impossible to do efficiently in TrueColor.
It also makes debugging X programs much easier, because you can test whether your application works in both PseudoColor and TrueColor modes without having to start a second X server to do it.
I wish they wouldn't call this ``overlays'', though. Overlays are something else entirely (that's the term for visuals that have transparency built in at the hardware level. That kind of thing is supported on X servers from all the major players except XFree and Sun: SGI, HP, DEC and IBM.)
It would take more than an addition to 4.0 to support that, it would take a pretty fundamental change in X-Windows itself.
I don't think so.
X fonts are returned to the server from the font server as monochrome pixmaps. Font servers expect to send that, x servers expect to get that, and the client programs all expect that. You'd need to extend the X protocol to support grayscale pixmaps for the fonts, recode the font server to be able to send them, and the clients to be able to understand them.
You could do all of this on the client side:
You want to draw 14-point anti-aliased text.
You request a 28-point version of your font.
You render your text to a scratch bitmap.
You dither it down to half that resolution.
You display that pixmap.
Now obviously that's pretty inefficient, and this could be done much faster on the server side, if the server had support for it. But the basic mechanism would be the same, it's just that instead of using a scratch pixmap, the server would do the blending directly onto the target drawable.
So it's easy to imagine a system where the ``draw an antialiased string'' function would do this negotiation behind the scenes: if the server supported the right extension, it could let the server do it, otherwise, it could do it the hard way. (It could even load the double-sized font for you, by looking at the font you've passed in, and keeping a cache of double-sized versions.)
It would be possible to get the X server to antialias text that is drawn with XDrawText(), but this would probably break some other applications (eg drawing the text again in the background colour to erase it may leave artifacts if antialiasing is used).
That would definitely break things, and probably more than you think. There's no way to do that compatibly. To do this, you'd have to have a different API for drawing anti-aliasted text.
Which isn't to say that adding that API would be a bad idea. I think it could be done in a way that was fairly convenient to use, and would degrade well on servers that didn't support scaled fonts.
That said, Perl has some nice features that could be part of any language:
regular expressions and pattern matching of course
automatic memory allocation and garbage collection
relaxed data typing and argument passing
familiar C-like syntax
convenient primitives for files, lists, stacks, queues, and hash tables
eval
With one exception, you've just described JavaScript.
The one exception is convenient access to files, and that's the killer that has prevented it from being used as a batch-mode shell scripting language until now.
I really wish someone would fix that, because I would love to be writing scripts in JS instead of Perl. (It wouldn't take much: just a little syntactic sugar to make the act of listing, opening, and closing files be a less verbose process.)
Here's a telling example of the differences between the two languages: both allow you to treat everything as text manipulation (streams of bytes, regexps, etc.) And both allow you to construct objects and assign them behavior and manipulate things at a high level.
But there is a particular focus built into the language. Sure, there's ``more than one way to do it,'' but the nature of Perl, the nature of the language's shortcuts, encourages you think about things as matching patterns in text, instead of as communication between objects. While allowing both, JS focuses on the latter.
``All the world's a stream of bytes'' is the most horrible and damaging part of Unix's legacy. It has stunted a whole generation of programmers.
There is not scientific reason, no logical reason, no reason at all why this is necessarily wrong or bad.
No, there's not. As I said, it was an interesting experiment. Nevertheless, Perl blows, and I think its design philosophy is why, rather than some implementation detail or other accident. It was interesting to see what kind of language we would end up with with the design principle of no design principles. Well, the language we ended up with is one that I find egregiously bad. Interesting data point. Let's not try that again. Acknowlege, move on.
You're arguing from a specific opinion and worse, arguing definitions from definitions. Programming languages are X, Perl is not X, so Perl is not a very good programming language. But what if the idea that programming languages are X is disputed? Indeed, this is the case.
And you're arguing syntax. Obviously I was stating my opinion, not trying to offer a proof of why Perl is bad. The ``X'' that Perl is is ``sucky.'' I hold that truth to be self-evident. Beyond that, I suggest that this suckiness is a result of the thing about Perl that is different from prior, less sucky languages: the fact that Perl rejects outdated academic concepts like consistency and simplicity.
You say this fuzziness is inappropriate for a computer language. I disagree. I think it is highly apprpriate. Programming is, to me, art. It is a craft.
And to me. But don't confuse the act of giving the programmer freedom of expression, and the act of giving the programmer a simple, consistent, easy-to-undertand tool. You can do both. Just because a tool is a simple and easy-to-understand device (like a lever, or rope) doesn't mean it restricts the artistic expression of those using it. Help, help, I'm being oppressed!
People can live free with tools that haven't themselves gone hog-wild with baroque gilding.
I consider simplicity, consistency, and orthogonality to be good things in a tool. I think that when you want to provide a tool to solve a problem, you should think the problem through, and cover all the permutations. Figure out what's needed, and do it in a simple way. That's not the Perl approach. The perl approach is much more haphazzard than that, and usually involves a new line-noise syntax and some regular expressions.
And while ``there's more than one way to do it [as long as you use line noise punctuation and regexps]'', Perl most assuredly does encourage a particular programming style. It does this by the shortcuts it provides. Perl encourages you to think about everything as text manipulation, when (news flash!) most things aren't. It encourages use of regular expressions, even when they would be inappropriate (which, news flash, is almost all the time.) It doesn't force you, no, but it makes one path easy and the other path hard, and that's all it takes.
Some people, when confronted with a problem, think "I know, I'll use regular expressions." Now they have two problems.
Furthermore, ``There's more than one way to do it'' is not a virtue in a multiple programmer environment. When someone else is going to see your code (and unless you're doing an art project all on your own, someone will) your responsibility as a programmer is not only to make the program work, but also make it maintainable.
Larry has a consistent philospohy behind the design of Perl (or rather, the intentional lack of overall design.) It's an interesting idea, certainly, and one that I think hasn't been consciously applied to a programming language before. However, if Perl is the kind of language that that approach produces, then I think the experiment is a failure.
While Larry is a smart fellow, the problem is that he is also a linguist. And having spent a few years working with linguists (doing a natural-language understanding boondoggle), my experience is that linguists should never ever be allowed near computers.
Computer languages aren't really languages, not in the sense that linguists know languages. Computer languages are formal mathematical systems, which are a totally different beast. Computers are very literal-minded, not fuzzy at all, so one must talk to them precisely. The fuzziness that appears in human languages is inappropriate in a computer language.
The ``language'' of mathematics doesn't have linguistic drift. Where is the ``slang'' in arithmetic? Where are the ``dialects'' of algebra? It doesn't happen, because mathematical systems exist by design, not by evolutionary pressure and random mutation.
Accretion works well for some things, like DNA, forests, and cities. But I for one am glad that my car's engine was designed to be efficient and self-consistent, and I prefer the software I use (including languages) to be the same, rather than a sprawling Winchester Mystery House of a language like Perl.
Of course, I end up using Perl anyway, because often it's the most convenient tool for the job for any number of not-very-good reasons. The way Perl manages to suck so bad and yet still be marginally useful is probably what makes it the perfect complement to Unix itself. Worse is Better, after all.
Actually, now that I think about it, Tcl is even more horrible than Perl, so it's a wonder it hasn't taken over.
I used to do backups to a SCSI DAT, but I recently broke my drive. Anyway, I wasn't able to fit more than 2G on one tape, and I assumed that was the limit of DATs.
If I want to backup 4G or 8G of data, and I don't want to have to switch media halfway through, what should I buy?
Bonus points if it's media that is still likely to be in fashion (and thus easily readable) five years from now.
I'm leaning toward the idea of not using tapes for backups at all, but just cloning everything to a spare hard disk, that is only ever mounted during the backup process.
SGI takes it to ridiculous extremes, however. What does Jot do, for example, that requires GLX?
I'm guessing you know the answer to this already, but the reason Jot requires GLX is that it was written using a GUI toolkit that happens to be built on OpenGL instead of on Xlib. I haven't used that toolkit, so I don't know what its merits are, but it's sure not hard to imagine a GUI toolkit whose API recommends it over Xt or Motif.
Jot is also a very old program; most of SGI's tools use Motif these days.
But, you know, there are technical reasons why one might want to use GL in something like a text editor, too: because when you only use raw X, performance sucks. For example, you're not going to be able to do things like, say, scroll text smoothly without using an API that gives you more direct access to the frame buffer than the baseline X protocol gives you.
Even for non-3d applications, the performance improvements you can get by using GL instead of X are amazing. I mean, my god, raw X can't even do double buffering properly. (And before you mention the ``double-buffering extension,'' try it with XFree86: the performance is identical to copying pixmaps yourself by hand, meaning that's doubtless how it's implemented in the server.)
I use 4Dwm daily; its features pale in comparison to the linux offerings.
I'd sure like to hear what features you're talking about, because I can't imagine how anyone could think this. SGI's desktop tools are the best I've seen on Unix, bar none.
it has a major flaw in that many of the features available on the desktop are not available to a non-SGI X-Server
I think by ``non-SGI X server'' you actually mean ``X servers that do not support the GLX server extension.'' Is is really a surprise that SGI, who invented OpenGL, would write a lot of code that takes advantage of it?
It seems quite unfair to me to blame SGI for the failings of X servers shipped by other vendors.
You can argue that SGI should have met the least-common-denominator of all other vendors with these tools, but if they did, they would be throwing away all the technology related to their area of expertise.
What people *don't* know is that the way this is implemented is by still performing 128 bit encryption, but supplying a "help field" which contains the remaining 88 bits of key encrypted with the NSA's public key. This means that the NSA can easily break the (for them) 40-bit encryption, but for anyone else(such as the european governments), they face the encryption full strength at 128 bit.
This is demonstrably nonsense.
It's true that the way the key strength is reduced from 128 bits to 40 bits is by sending 40 bits of the key in the clear. Everything you wrote beyond that is fantasy.
Things encrypted using the exportable version of Communicator can be easily decrypted by anyone with equal ease. It really is 40 bits.
Furthermore, the article itself said:
The report offered evidence that [...] deals had been struck with Microsoft, Lotus, and Netscape to alter their products for foreign use.
Um, hello, there's no deal involved here. The only deal is that the US Government has made it illegal to export strong crypto. The deal is, alter your product to use weak crypto in the export versions, or go to jail. Everyone who hasn't been living under a rock for the last six years knows this already.
I don't know about you, but I'm wearing Mozilla underwear right now! Unfortunately, it seems to have been discontinued: along with all other Mozilla items! I can't find any of them in the Netscape store. There used to be a ton of things with Mozilla on them: beach towels, hats, there was even a Mozilla beanie baby. But no more.
This is a sad day.
(A few weeks ago I was riding my bicycle in downtown SF, and someone saw my mozilla.org sticker and yelled out, ``Go Mozilla!'' I thought that was pretty cool.)
I'm amazed that so many people here say they were able to get vgetty working; you guys must all lead charmed lives, because I spent months fighting with it, and couldn't ever get it to correctly answer the phone and record a message twice in a row.
I settled for having my machine simply use the modem to listen to the caller ID info, and pop up a big old dialog box telling me who's calling, then let my real answering machine take the call.
Features:
I can read the dialog box from across the room;
It also checks for the incoming number in my address book ( BBDB);
The phone doesn't ring if it's late at night or early in the morning and the screen saver is active;
It securely logs calls to my web server, so if I'm at another site, I get asynchronous notification that someone has called me at home, and I know to call in and check my messsage!
Slashdot Mirror
It doesn't matter. You can't buy devices that do this in the consumer electronics store in the mall. So it doesn't exist. Just because a handful of high-tech wunderkinds have the ability to crack this stuff doesn't mean it will ever find its way into the hands of the general public -- which is the only time it actually matters.
You're on crack. This means that you and your friends, members of the technological priesthood all, will be able to pirate music. That's all well and good for you. But it does not mean that any lasting change will have been effected in the way the music industry operates. It does not mean that the artists will stop getting screwed the way they are today.
It is so much worse than you imagine. Read this: http://www.apk.net/cihs/verbal/albini.html
The summary from that article:
Record company: $710,000
Producer: $90,000
Manager: $51,000
Studio: $52,000
Previous label: $50,000
Agent: $7,5000
Lawyer: $12,000
Band member net income each: $4,031.25
The band is not 1/4 of the way through its contract, has made the music industry more than 3 million dollars richer, but is in the hole $14,000 on royalties. The band members have each earned about 1/3 as much as they would working at a 7-11, but they got to ride in a tour bus for a month.
Burn, Hollywood, Burn.
A nice theory, but DVD players are a counter-example. It's very difficult to buy a DVD player that is not region-coded. Yes, you can buy them, but only mail-order, and they cost 3x as much as normal players. They're irrelevant.
Likewise, you don't see any commercial VCRs with built-in Macrovision suppression. You can buy devices that do it, but only from shady operators with small ads in the back pages of video magazines.
Such things never hit the mainstream, because the content providers and hardware manufacturers and (more importantly) hardware distributors are all in bed with each other.
After making a function call analagous to what one would do in X, it drops into a library that eventually puts bits in video memory. In the same process. With X, after dropping into that library, some bits get written to a socket, then some time later the X server becomes runnable, reads from that socket, puts bits in video memory, and (depending on the operation) sends a reply back to the (waiting) client. And things get even worse when window creation is involved, because then you get to play hot-potato with a third process, the window manager.
At a superficial level, yes, but the reality of the situation is that one could not have an implementation of X that transparently gave the performance characteristics of a library that didn't implicitly have a client/server model underneath it. That is, the fact that the client program and the frame buffer might be on separate machines permeates all of X. You can't escape it: that design decision influenced many aspects of the API.
...can be found on this page. It even comes with instructions!
There is nothing ``pseudo'' about the object-orientedness of Xt and the toolkits built on top of it (Motif and Athena.) The object system they use includes method inheritance (single-inheritance only), runtime typing, and the usual bag of goodies. It's primitive, but it is every bit as object-oriented as anything else that claims that name.
You are right that there is nothing object-oriented about X -- because X is an on-the-wire protocol, and so low level that hardly anybody programs in it directly anyway. That's what toolkits are for.
I suspect that you are laboring under the misapprehension that for something to be ``object oriented'' a so-called ``object-oriented language'' has to be involved. There is no such thing as an ``object-oriented language.'' OO is a programming style, not a syntax. There are some languages that provide useful tools that make an OO style easier to use (like Java, CLOS, and Smalltalk) and there are some languages that provide a huge set of broken and useless tools that get in your way and screw you if you try to use any of them (like C++). But you can write object-oriented code in any language, and you can write assembler in any language too.
This is true. Which is why that's how Xt and Motif and Athena are written, and how one programs in them.
Motif and Athena both suck in their own ways, but the problems have nothing to do with whether they are object-oriented or not. Motif's problems are that it's huge, overly complicated, and insanely buggy. Athena's problems are that it is missing important features, and it has an insanely ugly and hostile look-and-feel. (And both of them use Xrm, the X Resource Manager, which is a completely separate disaster.)
But both (all three) of these toolkits are most assuredly object-oriented. Which just goes to show that being object-oriented doesn't make everything wonderful, like some people seem to assume.
Go sit down in front of a Windows box and scroll a page of text. Pretty mind-blowing how fast it is, isn't it? You know why? Because the underlying implementation has access to a frame buffer! It doesn't have to squirt all its bits through a straw, hitting at least three processes along the way, and all the blocking and context-switching that that brings with it.
Sure, X has optional ways to sometimes get at the frame buffer, and on some systems in some circumstsances, they even work. After you've written your program's rendering engine twice, once for each method.
X's second biggest design flaw is it's lack of user interface policy. ``There's more than one way to do it'' and they're all different and most of them suck. Most Linux fanboys come from the ``real programmer'' school and hold customizability as the holy grail -- it doesn't matter if the system is completely unusable out of the box, because they see that as an opportunity to tweak the hell out of it for their own use. And maybe some of them will even come up with something usable. For themselves.
Well I'm here to tell you that customizability is a cop-out. ``I'll make it an option'' is almost always another way of saying ``I didn't design it right in the first place, so I'll force the end user to finish designing the program for me.''
Perhaps there are some people who hate Unix and X out of kurmudgeonly spite, but I'm not one of them. I hate them because I've got the scars, and I know where the bodies are buried.
Now this is where someone chimes in, ``well if you hate X and Unix so much, what's better?'' That's the wrong question. Just because B is worse than A doesn't mean that A doesn't suck, and isn't fully worthy of the criticism it receives.
Well, someone had to post this. I first saw this message in, I think, 1987. I don't know where it originated.
X
DANGEROUS VIRUS
First, a little history. The X window system escaped from Project Athena at MIT where it was being held in isolation. When notified, MIT stated publicly that "MIT assumes no responsibility....". This is a very disturbing statement. It then infiltrated Digital Equipment Corporation, where it has since corrupted the technical judgement of this organization.
After sabotaging Digital Equipment Corporation, a sinister X consortium was created to find a way to use X as part of a plan to dominate and control interactive window systems. X windows is sometimes distributed by this secret consortium free of charge to unsuspecting victims. The destructive cost of X can not even be guessed.
X is truly obese - whether it's mutilating your hard disk or actively infesting your system, you can be sure its up to no good. Innocent users need to be protected from this dangerous virus. Even as you read this, the X source distribution and the executable environment created is being maintained on hundreds of computers - maybe even your own.
Digital Equipment Corporation is already shipping machines that carry this dreaded infestation. It must be destroyed.
This is what happens when software with good intentions goes bad. It victimizes innocent users by distorting their perception of what is and what is not good software. This malignant window system must be destroyed.
Ultimately DEC and MIT must be held accountable for this heinous _software crime_, brought to justice, and made to pay for a _software cleanup_. Until DEC and MIT answer to these charges, they both should be assumed to be protecting dangerous software criminals.
DON'T BE FOOLED!! JUST SAY NO TO X.
X windows. A mistake carried out to perfection. X windows. Dissatisfaction guaranteed. X windows. Don't get frustrated without it. X windows. Even your dog won't like it. X windows. Flakey and built to stay that way. X windows. Complex nonsolutions to simple nonproblems. X windows. Flawed beyond belief. X windows. Form follows malfunction. X windows. Garbage at your fingertips. X windows. Ignorance is our most important reesource. X windows. It could be worse, but it'll take time. X windows. It could happen to you. X windows. Japan's secret weapon. X windows. Let it get in YOUR way. X windows. Live the nightmare. X windows. More than enough rope. X windows. Never had it. Never will. X windows. No hardware is safe. X windows. Power tools for Power Fools. X windows. Power tools for power losers. X windows. Putting new limits on productivity. Simplicity made complex. X windows. The Cutting Edge of Obsolescence. X windows. The art of incompetence. X windows. The defacto substandard. X windows. The first fully modular software disaster. X windows. The joke that kills. X windows. The problem for your problem. X windows. There's got to be a better way. X windows. Warn your friends about it. X windows. You'd better sit down. X windows. You'll envy the dead.
Where? I haven't found it.
Then you believe in security through obscurity. Security through obscurity doesn't work. Repeat it until you believe it.
Then you believe that software is made more powerful by being obscure enough that only a vanishingly tiny minority of potential users are able to use it. You believe that software that is used by a thousand people is, for that reason, more powerful than software that is used by a million people.
You are wrong.
The more people who use crypto, the more effective cryptography will be for everybody. If one has to even understand what ``NFS'' is in order to install a package like this, then it's still too hard.
That's why PGP and S/MIME are still so marginal that they can be completely discounted: only gurus use them, because they aren't so completely transparent that you don't even know that they're there until they have something to warn you about.
Designing easy-to-use interfaces for crypto is one of the hardest UI tasks there is -- I know, I've tried. But, if you believe in cryptography at all, it's also one of the most important.
There is something notable missing from all of these pages: simple, easy-to-follow instructions on how to install and effectively (and securely!) use a file system like this.
From the dearth of documentation, I get the feeling that this has only ever been attempted by file-system gurus, which means that I wouldn't even want to consider attempting it, because reformatting my disk and reinstalling the system is not something I look forward to.
Here is what I would like to end up with:
Is this dream even remotely realizable?
Basically, the situation I want to protect against is simply that of the laptop being stolen while I'm away from the keyboard -- whether it is powered on at the time, or powered off.
The problem here is that the usual crypto-heads are the types who use ssh and pgp and are already used to having to perform nontrivial system-administration tasks to get things up and running, and who don't mind wading through a command-line alphabet soup to do simple tasks, all day long. What we need is someone who is both a crypto-head, and who understands that their agenda is best served by taking the time to make this software be drool-proof.
It doesn't matter how good the math is if no real users are actually using it. Crypto is only effective if widely deployed. If not, those few who use crypto stand out for targetting.
I remember, years ago, being blown away when someone showed me a Macintosh with multiple monitors, one of which was a low-resolution 1-bit screen, and the other of which was a giant color screen. They dragged a window so that half was on one screen and half was on the other -- and both sides of the window displayed properly.
I doubt X will ever be able to do that. I think it would require major protocol and API changes.
This is something SGI has done forever, and it's just incredibly convenient. It's so much nicer to be able to have the default visual be an 8-bit colormapped visual, but have it be possible for specific applications to use 24-bit color as needed. Most applications don't need TrueColor, so all that memory is just wasted on them. And there are things you can do in PseudoColor that are just impossible to do efficiently in TrueColor.
It also makes debugging X programs much easier, because you can test whether your application works in both PseudoColor and TrueColor modes without having to start a second X server to do it.
I wish they wouldn't call this ``overlays'', though. Overlays are something else entirely (that's the term for visuals that have transparency built in at the hardware level. That kind of thing is supported on X servers from all the major players except XFree and Sun: SGI, HP, DEC and IBM.)
I don't think so.
You could do all of this on the client side:
Now obviously that's pretty inefficient, and this could be done much faster on the server side, if the server had support for it. But the basic mechanism would be the same, it's just that instead of using a scratch pixmap, the server would do the blending directly onto the target drawable.
So it's easy to imagine a system where the ``draw an antialiased string'' function would do this negotiation behind the scenes: if the server supported the right extension, it could let the server do it, otherwise, it could do it the hard way. (It could even load the double-sized font for you, by looking at the font you've passed in, and keeping a cache of double-sized versions.)
That would definitely break things, and probably more than you think. There's no way to do that compatibly. To do this, you'd have to have a different API for drawing anti-aliasted text.
Which isn't to say that adding that API would be a bad idea. I think it could be done in a way that was fairly convenient to use, and would degrade well on servers that didn't support scaled fonts.
With one exception, you've just described JavaScript.
The one exception is convenient access to files, and that's the killer that has prevented it from being used as a batch-mode shell scripting language until now.
I really wish someone would fix that, because I would love to be writing scripts in JS instead of Perl. (It wouldn't take much: just a little syntactic sugar to make the act of listing, opening, and closing files be a less verbose process.)
Here's a telling example of the differences between the two languages: both allow you to treat everything as text manipulation (streams of bytes, regexps, etc.) And both allow you to construct objects and assign them behavior and manipulate things at a high level.
But there is a particular focus built into the language. Sure, there's ``more than one way to do it,'' but the nature of Perl, the nature of the language's shortcuts, encourages you think about things as matching patterns in text, instead of as communication between objects. While allowing both, JS focuses on the latter.
``All the world's a stream of bytes'' is the most horrible and damaging part of Unix's legacy. It has stunted a whole generation of programmers.
No, there's not. As I said, it was an interesting experiment. Nevertheless, Perl blows, and I think its design philosophy is why, rather than some implementation detail or other accident. It was interesting to see what kind of language we would end up with with the design principle of no design principles. Well, the language we ended up with is one that I find egregiously bad. Interesting data point. Let's not try that again. Acknowlege, move on.
And you're arguing syntax. Obviously I was stating my opinion, not trying to offer a proof of why Perl is bad. The ``X'' that Perl is is ``sucky.'' I hold that truth to be self-evident. Beyond that, I suggest that this suckiness is a result of the thing about Perl that is different from prior, less sucky languages: the fact that Perl rejects outdated academic concepts like consistency and simplicity.
And to me. But don't confuse the act of giving the programmer freedom of expression, and the act of giving the programmer a simple, consistent, easy-to-undertand tool. You can do both. Just because a tool is a simple and easy-to-understand device (like a lever, or rope) doesn't mean it restricts the artistic expression of those using it. Help, help, I'm being oppressed!
People can live free with tools that haven't themselves gone hog-wild with baroque gilding.
I consider simplicity, consistency, and orthogonality to be good things in a tool. I think that when you want to provide a tool to solve a problem, you should think the problem through, and cover all the permutations. Figure out what's needed, and do it in a simple way. That's not the Perl approach. The perl approach is much more haphazzard than that, and usually involves a new line-noise syntax and some regular expressions.
And while ``there's more than one way to do it [as long as you use line noise punctuation and regexps]'', Perl most assuredly does encourage a particular programming style. It does this by the shortcuts it provides. Perl encourages you to think about everything as text manipulation, when (news flash!) most things aren't. It encourages use of regular expressions, even when they would be inappropriate (which, news flash, is almost all the time.) It doesn't force you, no, but it makes one path easy and the other path hard, and that's all it takes.
Some people, when confronted with a problem, think "I know, I'll use regular expressions." Now they have two problems.
Furthermore, ``There's more than one way to do it'' is not a virtue in a multiple programmer environment. When someone else is going to see your code (and unless you're doing an art project all on your own, someone will) your responsibility as a programmer is not only to make the program work, but also make it maintainable.
Larry has a consistent philospohy behind the design of Perl (or rather, the intentional lack of overall design.) It's an interesting idea, certainly, and one that I think hasn't been consciously applied to a programming language before. However, if Perl is the kind of language that that approach produces, then I think the experiment is a failure.
While Larry is a smart fellow, the problem is that he is also a linguist. And having spent a few years working with linguists (doing a natural-language understanding boondoggle), my experience is that linguists should never ever be allowed near computers.
Computer languages aren't really languages, not in the sense that linguists know languages. Computer languages are formal mathematical systems, which are a totally different beast. Computers are very literal-minded, not fuzzy at all, so one must talk to them precisely. The fuzziness that appears in human languages is inappropriate in a computer language.
The ``language'' of mathematics doesn't have linguistic drift. Where is the ``slang'' in arithmetic? Where are the ``dialects'' of algebra? It doesn't happen, because mathematical systems exist by design, not by evolutionary pressure and random mutation.
Accretion works well for some things, like DNA, forests, and cities. But I for one am glad that my car's engine was designed to be efficient and self-consistent, and I prefer the software I use (including languages) to be the same, rather than a sprawling Winchester Mystery House of a language like Perl.
Of course, I end up using Perl anyway, because often it's the most convenient tool for the job for any number of not-very-good reasons. The way Perl manages to suck so bad and yet still be marginally useful is probably what makes it the perfect complement to Unix itself. Worse is Better, after all.
Actually, now that I think about it, Tcl is even more horrible than Perl, so it's a wonder it hasn't taken over.
Maximal obscurity! Now!
If I want to backup 4G or 8G of data, and I don't want to have to switch media halfway through, what should I buy?
Bonus points if it's media that is still likely to be in fashion (and thus easily readable) five years from now.
I'm leaning toward the idea of not using tapes for backups at all, but just cloning everything to a spare hard disk, that is only ever mounted during the backup process.
I'm guessing you know the answer to this already, but the reason Jot requires GLX is that it was written using a GUI toolkit that happens to be built on OpenGL instead of on Xlib. I haven't used that toolkit, so I don't know what its merits are, but it's sure not hard to imagine a GUI toolkit whose API recommends it over Xt or Motif.
Jot is also a very old program; most of SGI's tools use Motif these days.
But, you know, there are technical reasons why one might want to use GL in something like a text editor, too: because when you only use raw X, performance sucks . For example, you're not going to be able to do things like, say, scroll text smoothly without using an API that gives you more direct access to the frame buffer than the baseline X protocol gives you.
Even for non-3d applications, the performance improvements you can get by using GL instead of X are amazing. I mean, my god, raw X can't even do double buffering properly. (And before you mention the ``double-buffering extension,'' try it with XFree86: the performance is identical to copying pixmaps yourself by hand, meaning that's doubtless how it's implemented in the server.)
As Don Hopkins so eloquently put it, `` The X approach to device independence is to treat everything like a MicroVAX framebuffer on acid.'' All the associated layers of pseudo-generalism make it impossible to actually take any real advantage of the underlying hardware.
I'd sure like to hear what features you're talking about, because I can't imagine how anyone could think this. SGI's desktop tools are the best I've seen on Unix, bar none.
I think by ``non-SGI X server'' you actually mean ``X servers that do not support the GLX server extension.'' Is is really a surprise that SGI, who invented OpenGL, would write a lot of code that takes advantage of it?
It seems quite unfair to me to blame SGI for the failings of X servers shipped by other vendors.
You can argue that SGI should have met the least-common-denominator of all other vendors with these tools, but if they did, they would be throwing away all the technology related to their area of expertise.
I wrote:
Math is hard, let's go shopping. 128 - 40 = 88 bits sent in the clear.
This is demonstrably nonsense.
It's true that the way the key strength is reduced from 128 bits to 40 bits is by sending 40 bits of the key in the clear. Everything you wrote beyond that is fantasy.
Things encrypted using the exportable version of Communicator can be easily decrypted by anyone with equal ease. It really is 40 bits.
Furthermore, the article itself said:
Um, hello, there's no deal involved here. The only deal is that the US Government has made it illegal to export strong crypto. The deal is, alter your product to use weak crypto in the export versions, or go to jail. Everyone who hasn't been living under a rock for the last six years knows this already.
I don't know about you, but I'm wearing Mozilla underwear right now! Unfortunately, it seems to have been discontinued: along with all other Mozilla items! I can't find any of them in the Netscape store. There used to be a ton of things with Mozilla on them: beach towels, hats, there was even a Mozilla beanie baby. But no more.
This is a sad day.
(A few weeks ago I was riding my bicycle in downtown SF, and someone saw my mozilla.org sticker and yelled out, ``Go Mozilla!'' I thought that was pretty cool.)
I'm amazed that so many people here say they were able to get vgetty working; you guys must all lead charmed lives, because I spent months fighting with it, and couldn't ever get it to correctly answer the phone and record a message twice in a row.
I settled for having my machine simply use the modem to listen to the caller ID info, and pop up a big old dialog box telling me who's calling, then let my real answering machine take the call.
Features:
Works pretty good. Get the code and read all about it.
Are you going to tell us that you can hear the difference between optical and non-optical outputs? Please.