In the 100 GB extant fragment you mention, there should have been at least a hundred copies.
What, stuck in the middle of a piece of video? No.
You have a shiny platter and a drive motor that hasn't worked for centuries; how would you retrieve even a byte stream from the platter?
Well, there you go. That's why electronic storage is a controversial topic for archivists. Its use is a compromise.
Also, we simply don't know how to store video and audio for the centuries. Text is easy: c.f. the Dead Sea Scrolls. If you want to go back farther than a few thousand years, etch words and simple pictures into stone or, better, metal. But for video and audio, we just don't have a good solution. There's a very real possibility that these vast volumes of information will simply be lost to history.
a small team of scholars can create a perfect automated translator for a programming language
Sure. And a small team of scholars can translate Middle English to Modern English, too. But every aspect of the story that involves the use of the phrase "a small team of scholars" reduces the likelihood that the information will ever be recovered.
And who's to say that automatic computers will even exist in the distant future?
These are, in fact, exactly the kinds of questions archivists have to deal with.
"Farther" and "further" are not interchangeable. "Farther" refers to distance in space, while "further" refers to some other type of extent. It's easy to remember this because "far" means "separated by a great distance."
You'd say "I walked farther," but you'd say "I will look into this further."
Sometimes people may get them wrong, but that's an error, not interchangeable usage.
The actions of picking which subsystems to use for audio/video (hence the 'multi' in multimedia) capture/output belong together.
Trust me, they really don't. "Sound" is one thing, and it has a whole set of controls that belong together. "Video" is a whole 'nother thing, and it has controls that belong together. There are lots of reasons to manipulate sound and video controls that don't involve picking the inputs and outputs. Splitting those controls off and moving them someplace else is just bad human interface design.
Think of the interface as a grocery store. Somebody walks into the store and thinks, "I want paprika." They're not going to go over to some kind of index and look under "P," nor are they going to stop an employee and ask where the paprika is. Instead, they generalize: "Paprika is a spice, and spices are usually on the baking aisle, so I'll walk until I see baking stuff."
When somebody uses your computer and thinks, "I want to adjust the volume," they generalize: "I'm looking for sound controls." When they think, "I want to select the headphones instead of the speakers," they generalize: "I'm looking for sound controls." When they think, "I want to adjust the gain on the microphone," they generalize: "I'm looking for sound controls."
Sending your users all over God's creation to find different controls for related functions is a great way to piss everybody off.
I may wish to select one of the video sinks that records a stream to disk, shunts it accross a network, or calculates MD5sums of the data stream.
Um. Yeah. Stupid examples of nonsense situations that nobody would ever, ever do in the real world do not help your case. You may want to use your computer as a boat anchor, too, but that doesn't mean welding an anchor chain to the top of the case is a wonderful idea.
If you want to know more about it, google some of the terms you don't know about.
Tell me again why this "Linux" thing is gonna take over the world? Is it the "this control is unnecessarily complex" attitude that's gonna be the key to their success, or the "this is not meant for you to understand" attitude that's gonna win the hearts and minds?
It's named that because that's exactly what it is.
No, it's named that because somebody decided to try to make it sound like more than it was. "Sound output?" Oh, God, no. Far too mundane. "Audio controls?" Still to pedestrian. "I know! Multimedia system selector!" Throw a random plural in there and erroneously capitalize that second "M" and you've got a winner!
Panels are the bars at the top and bottom of the screen.
And they're not called "bars" why? Could it be the "not invented here" phenomenon? Apple called it a "menu bar" in 1984; the term is ubiquitous and universally understood. But we have to be cool, so we'll come up with a different name. We'll call it...a panel! That's it, a panel. That's a word that nobody relates to human-computer interfaces. It makes the learning curve steeper for absolutely no reason. It's perfect!
they hold programs called applets.
Applets are little doohickeys that used to run inside a Web browser back in 1994 before everybody realized that they were basically stupid. Things that appear on the screen and that can be manipulated are called controls. Oh, but wait, we can't use the term everybody else uses. We have to make up our own. This time, rather than choosing a word nobody understands (like "panel"), we'll choose a word everybody understands and use it in a completely foreign way: applet. Perfect.
See the little speaker icon at the top right? That's what any user trying to change the volume would go to
Not necessarily. A user who didn't know to look for controls in the menu bar --oh, crap, sorry, the "panel" --wouldn't, particularly one who's used to Windows. Windows puts on-screen controls in the bottom right corner, you see. A user who's familiar with Windows would look for the volume control -- dammit, "applet" --in the usual place, not find it, and default to looking at the sound control panel.
it's an advanced configuration program not meant for most users to deal with
Then why is it there at all? Given that Gnome is so obviously unfinished, why is effort being put into features that nobody will use when basic features remain incomplete? I mean, the fonts are obviously not finished. They're just bitmapped placeholders. The "close" buttons all have a black placeholder mark on them. The icons haven't been drawn yet. The list goes on and on. Why are people wasting their time on hideously complex features that nobody is going to use?
Pop in one of the many live CDs that have been posted on Slashdot over the past week or so and try out GNOME. I think you'll be pleasantly surprised by how much easier it is to use than you think.
Hm. Doesn't sound like a ringing endorsement to me. "You think Gnome, on a scale of one to ten, is a dead-flat zero, but trust me! It's actually a one!"
But come on, 'aim high, settle for a tie' is almost certain to yield better efforts and results than 'aim for a tie'.
That sounds real good on paper, but it never, ever works in practice.
Let's say you're just learning to compose music. Does it make sense to try to be better than Bach? Of course not. That's putting the cart before the horse. In order to be better than Bach, you have to first be as good as Bach, which in and of itself is a task for a lifetime.
If you're trying to build a computer operating system, in order to be better than Apple you first have to be as good as Apple. And given that Apple's got a thousand man-years of collective experience on the subject, and has had more spectacular failures than the hobbyists have had even modest successes, I'd say that merely being as good as Apple is a pretty tall order.
Long story short: The people who make things like "Gnome" (c.f. the related story about the oh-so-embarrassing "Gnome" screen shots) have a lot to learn about basic human interfaces. They are, right now, about 25 years behind the state of the art. Expecting them to somehow leap ahead and make something even better than the state of the art is expecting a pig to fly. You can hope and you can pray, but buddy, it just ain't gonna happen.
That's seven bytes. You said we have a 100 GB fragment of extant data.
Let me teach you about something wonderful. It's called the "ellipsis." It means "and so on, in that fashion." It means I don't have to actually type a hundred billion two-letter combinations to illustrate that I'm talking about a hundred gigabytes.
Under the scheme I've been explaining, which semi-periodically embeds a copy of the decoder's source code, you seek forward until you find a long string of bytes with bit 7 clear, which is the signature of US-ASCII text.
Ooops. Didn't find it. That part of the data was lost. It'd be nice if we were still able to recover something. Unfortunately, because Random Slashdot Dumbass #3 was responsible for the archive, and he chose some dumbass format that nobody remembers, all we have is this random list of coefficients with no clue whatsoever as to the algorithm that was used to encode them.
You do realize that "encode" also means "to obscure," right?
Or do you assume that C and/* English */ will be dead languages by the time you want to recover this data?
Of course we assume that, you dumbass. That's why it's called an archive. It's meant to last, for all practical purposes, forever. Middle English was in widespread use a mere thousand years ago, but today it's a completely dead language. We don't even use the same character set they used. At the rate English is evolving, a thousand years hence this comment I'm writing right now will be about as understood as "Syððan wæs geworden æt he ferde urh a ceastre and æt castel" is to you today. The only people who can understand Middle English are scholars. If you found a shoebox in your attic filled with letters and postcards written in Middle English, translating them to Modern English would be a massive effort.
The whole idea of creating an archive is to store information in a way that's as recoverable as possible. Expecting the people who want to access that information to (1) understand your language, (2) understand your programming language, and (3) understand all your baroque encoding algorithms is just fundamentally wrong. At that point it's not an archive. The data will be useful for maybe a few decades, possibly, if you're lucky. Beyond that, you're just recovering the archive to get at the refined metals in the disks.
The program you're referring to lets you pick the backend that GStreamer outputs audio and video
Dude, I'm a reasonably intelligent guy, and I don't have the first fucking idea what that's supposed to mean. I'm just gonna take a wild-ass guess here and say that this is the control panel you use to say whether you want sound to come out of the speakers or the headphone jack. Why wrap it in technobabble?
It doesn't have a volume control on it because that isn't related to the function of the program.
Volume isn't related to sound controls? I think you'll find you're mistaken.
You contol the volume through the -- gasp! -- volume control applet in the panel.
What's a panel, and what's an applet? And if I go to the Sound control panel, I'd damn well expect to find controls related to sound there. Telling me they're somewhere else isn't the right answer. Are we constrained by room on the dashboard or the cost of materials? Put a fucking slider control on there, stick a label on it, and call it a day.
Except that the label would evidently be "audiophonic amplitude attenuation," abbreviated to AAA, and it would range from -e to +pi.
No, it's right up there next to the "Audio" tab...you know, the one that should read "Sound."
The multimedia systems selector allows you to select which multimedia systems, both audio and video, programs will use. What would you have called it?
Sound and video are two different things. They don't belong together. Break one out and call it -- I'm gonna get wacky here --"Sound," and the other "Video."
Of course, if you have no video card attached to your computer, a "Video" control panel is superfluous. No video output, no need for a "Video" control, see? So if there's no video output (composite, 601, 292M, whatever), there should be no video control panel.
To change the volume, you click on the little volume icon shown at the top right of the screen.
Why is it not included in the "Sound" control panel?
I have seen uglier screen shots...but not recently.
How are you supposed to tell which is the active window? Why are the window controls not vertically centered inside the window title bars? Why is the type incorrectly kerned? Why are random letters in control labels underlined? Is the scroll bar thumb the light gray part or the dark gray part? Why is some of the type antialiased and some not? Why is there a short horizontal line near the bottom of your "faux Finder" window? Why is there a white line on the left edge of your Terminal window? Where's the resize control on the Terminal window? Where's the scroll bar? And so forth and so on.
I thought that personal tastes are just that. Personal.
Most of the time, they are. But ugly is just ugly, you know?
"Assistive Technology" is a silly made-up name for what everybody else on the planet calls "accessibility." It means things like spoken interfaces and screen-readers, magnified displays and shift lock.
"Assistive Technology" is also the most recent in a long, long series of examples of taking a perfectly reasonable idea and making it so bafflingly complicated that even people with lots of computer experience look at it and go, "What the hell?"
That's fine in principle, but in practice it works like reverse Polish notation. It's something you can learn, yes, but it's backwards.
In English, we "do this to that." That is to say, we apply an action to an object. We don't specify an object and then describe an action. We "open door," we don't "door open."
The nut is that trying to teach people to think object-then-action is a chore. It's a process that has to be learned.
A far, far better paradigm is the gestural paradigm. Click, double-click, click-and-drag. For instance, consider drag and drop. Drag and drop is one of the easiest things to learn. We deal with the same basic paradigm every day. In order to put the banana guacamole in the freezer, I pick it up and put it on the shelf. I don't point to the banana guacamole and then point to the freezer and then give a command. In fact, drag-and-drop is so intuitive that people who have a lot of experience with primitive computer systems often have trouble mastering it. It doesn't seem "natural" to them because they've gone out of their way to learn a different syntax.
Select-then-act has to be learned. Drag-and-drop and other gestural interfaces are far more obvious.
That's real nice in theory, but it doesn't match the facts. For the past 20 years, one company has been right there on the leading edge, and everybody else has been struggling to keep up. About 10 years ago, a new thing came along, and now it's struggling to keep up with the folks who are struggling to keep up with the leader.
And yes, when the status quo is "compared to the leader, we suck," I'd say "let's be as good as the leader" is definitely a worthy goal.
Don't get an MPEG-2 encoded. MPEG-2 is all but dead. The only thing it's still being used for are standard-definition DVDs and broadcast television, two technologies that are on their way out. The future is M.264/AVC.
Oh, I'm an idiot. I never even thought of that. I tossed that very extension cable in a draw and never thought of it again. In particular, I never thought of putting it on the mouse. I just always did it the most obvious way: mouse plugs into keyboard, keyboard plugs into monitor, monitor plugs into computer, computer plugs into wall. Easy.
Can you name a major OS that has not been in a legal battle over some sort of IP dispute?
Mac OS X, as far as I know. That's just the first one that springs to mind because it's the one I'm using right now. I'm not aware of any copyright claims made against Apple over the source code to Mac OS X.
(This may be simple ignorance on my part.)
The point is not whether Linux has withstood claims made against it. The point is that there are a number of serious claims right now. For this reason, Linux is a legal hot potato at the moment, and nobody wants to touch it. If these claims are resolved, okay... but there's still the indemnity issue to deal with. So even if the cases disappear tomorrow, Linux is not free and clear from a legal perspective.
You're not understanding me. Let me go through this again.
Here's a bunch of data:
00 A0 3C 0D 18 99 5E...
Let's assume, for sake of argument, that you know this is video data. That's not a valid assumption, but let's grant it anyway. Your task is to split this data into frames and decode them into something that can be displayed.
If the data consists of an array of pixels, one right after another, that's easiest. All you need to do is find the boundaries of each frame and then figure out whether the pixels represent color channels or what. Relatively easy.
If the pixel array is run-length encoded, that's also fairly easy. There will be patterns in the data that make it fairly clear that you're dealing with run-length encoded data.
If, on the other hand, the data is a list of quantized coefficients that need to be plugged into a transform algorithm in order to be turned into pixel data, you're screwed. You can brute-force it to try every known transform (DCT, wavelet, whatever) against every permutation of the data set, but at that point you're just grinding metal. The odds of getting useful information out of the data in a reasonable amount of time are so close to zero as to be hardly worth discussing.
Generally speaking, the more clever you are in encoding your data, the less recoverable the encoded data will be. Normally this isn't important, but it becomes vitally important when you start talking about archiving. When it comes to archiving, recoverability is right up there with durability. Everything else is secondary.
Okay, now that was funny. I loves me some rich, juicy irony. All is forgiven. You can crack lame jokes all you want, as long as you follow 'em up with great ones.
Because there were Classic Mac viruses, and somebody thought it would be a good idea to port Classic Mac anti-virus software to Mac OS X. So now we have Virex and some Norton/Symantec/Whatever product. Nobody uses either one.
Linux is not in the courts right now. Not at all.
What does the sand look like from underneath? I only get to see the top of it from up here.
Because when you're archiving digital data, recoverability is paramount. You have to ask yourself, "What if all I had was a piece of this data, say, a hundred gigabytes from the middle of the disk? Could I turn that data into useful information?"
If you're dealing with a run-length-encoded array of packed pixels, the answer is obviously yes. That's among the simplest forms of encoding known. (If you don't RLE the data it's even simpler, but a trade-off between simplicity and storage requirements is okay as long as you maintain a lot of simplicity.) Even if you don't know how the data was encoded, you've got a good chance of figuring it out just by doing some simple analysis on the bytes. But with a complex encoding scheme, it's much more difficult to figure out what you're dealing with just by looking at it.
When talking about archiving, the objective is to be able to recover as much as possible given as little as possible.
Slashdot Mirror
In the 100 GB extant fragment you mention, there should have been at least a hundred copies.
What, stuck in the middle of a piece of video? No.
You have a shiny platter and a drive motor that hasn't worked for centuries; how would you retrieve even a byte stream from the platter?
Well, there you go. That's why electronic storage is a controversial topic for archivists. Its use is a compromise.
Also, we simply don't know how to store video and audio for the centuries. Text is easy: c.f. the Dead Sea Scrolls. If you want to go back farther than a few thousand years, etch words and simple pictures into stone or, better, metal. But for video and audio, we just don't have a good solution. There's a very real possibility that these vast volumes of information will simply be lost to history.
a small team of scholars can create a perfect automated translator for a programming language
Sure. And a small team of scholars can translate Middle English to Modern English, too. But every aspect of the story that involves the use of the phrase "a small team of scholars" reduces the likelihood that the information will ever be recovered.
And who's to say that automatic computers will even exist in the distant future?
These are, in fact, exactly the kinds of questions archivists have to deal with.
"Farther" and "further" are not interchangeable. "Farther" refers to distance in space, while "further" refers to some other type of extent. It's easy to remember this because "far" means "separated by a great distance."
You'd say "I walked farther," but you'd say "I will look into this further."
Sometimes people may get them wrong, but that's an error, not interchangeable usage.
The actions of picking which subsystems to use for audio/video (hence the 'multi' in multimedia) capture/output belong together.
Trust me, they really don't. "Sound" is one thing, and it has a whole set of controls that belong together. "Video" is a whole 'nother thing, and it has controls that belong together. There are lots of reasons to manipulate sound and video controls that don't involve picking the inputs and outputs. Splitting those controls off and moving them someplace else is just bad human interface design.
Think of the interface as a grocery store. Somebody walks into the store and thinks, "I want paprika." They're not going to go over to some kind of index and look under "P," nor are they going to stop an employee and ask where the paprika is. Instead, they generalize: "Paprika is a spice, and spices are usually on the baking aisle, so I'll walk until I see baking stuff."
When somebody uses your computer and thinks, "I want to adjust the volume," they generalize: "I'm looking for sound controls." When they think, "I want to select the headphones instead of the speakers," they generalize: "I'm looking for sound controls." When they think, "I want to adjust the gain on the microphone," they generalize: "I'm looking for sound controls."
Sending your users all over God's creation to find different controls for related functions is a great way to piss everybody off.
I may wish to select one of the video sinks that records a stream to disk, shunts it accross a network, or calculates MD5sums of the data stream.
Um. Yeah. Stupid examples of nonsense situations that nobody would ever, ever do in the real world do not help your case. You may want to use your computer as a boat anchor, too, but that doesn't mean welding an anchor chain to the top of the case is a wonderful idea.
If you want to know more about it, google some of the terms you don't know about.
...a panel! That's it, a panel. That's a word that nobody relates to human-computer interfaces. It makes the learning curve steeper for absolutely no reason. It's perfect!
Tell me again why this "Linux" thing is gonna take over the world? Is it the "this control is unnecessarily complex" attitude that's gonna be the key to their success, or the "this is not meant for you to understand" attitude that's gonna win the hearts and minds?
It's named that because that's exactly what it is.
No, it's named that because somebody decided to try to make it sound like more than it was. "Sound output?" Oh, God, no. Far too mundane. "Audio controls?" Still to pedestrian. "I know! Multimedia system selector!" Throw a random plural in there and erroneously capitalize that second "M" and you've got a winner!
Panels are the bars at the top and bottom of the screen.
And they're not called "bars" why? Could it be the "not invented here" phenomenon? Apple called it a "menu bar" in 1984; the term is ubiquitous and universally understood. But we have to be cool, so we'll come up with a different name. We'll call it
they hold programs called applets.
Applets are little doohickeys that used to run inside a Web browser back in 1994 before everybody realized that they were basically stupid. Things that appear on the screen and that can be manipulated are called controls. Oh, but wait, we can't use the term everybody else uses. We have to make up our own. This time, rather than choosing a word nobody understands (like "panel"), we'll choose a word everybody understands and use it in a completely foreign way: applet. Perfect.
See the little speaker icon at the top right? That's what any user trying to change the volume would go to
Not necessarily. A user who didn't know to look for controls in the menu bar --oh, crap, sorry, the "panel" --wouldn't, particularly one who's used to Windows. Windows puts on-screen controls in the bottom right corner, you see. A user who's familiar with Windows would look for the volume control -- dammit, "applet" --in the usual place, not find it, and default to looking at the sound control panel.
it's an advanced configuration program not meant for most users to deal with
Then why is it there at all? Given that Gnome is so obviously unfinished, why is effort being put into features that nobody will use when basic features remain incomplete? I mean, the fonts are obviously not finished. They're just bitmapped placeholders. The "close" buttons all have a black placeholder mark on them. The icons haven't been drawn yet. The list goes on and on. Why are people wasting their time on hideously complex features that nobody is going to use?
Pop in one of the many live CDs that have been posted on Slashdot over the past week or so and try out GNOME. I think you'll be pleasantly surprised by how much easier it is to use than you think.
Hm. Doesn't sound like a ringing endorsement to me. "You think Gnome, on a scale of one to ten, is a dead-flat zero, but trust me! It's actually a one!"
Pass.
But come on, 'aim high, settle for a tie' is almost certain to yield better efforts and results than 'aim for a tie'.
That sounds real good on paper, but it never, ever works in practice.
Let's say you're just learning to compose music. Does it make sense to try to be better than Bach? Of course not. That's putting the cart before the horse. In order to be better than Bach, you have to first be as good as Bach, which in and of itself is a task for a lifetime.
If you're trying to build a computer operating system, in order to be better than Apple you first have to be as good as Apple. And given that Apple's got a thousand man-years of collective experience on the subject, and has had more spectacular failures than the hobbyists have had even modest successes, I'd say that merely being as good as Apple is a pretty tall order.
Long story short: The people who make things like "Gnome" (c.f. the related story about the oh-so-embarrassing "Gnome" screen shots) have a lot to learn about basic human interfaces. They are, right now, about 25 years behind the state of the art. Expecting them to somehow leap ahead and make something even better than the state of the art is expecting a pig to fly. You can hope and you can pray, but buddy, it just ain't gonna happen.
That's seven bytes. You said we have a 100 GB fragment of extant data.
/* English */ will be dead languages by the time you want to recover this data?
Let me teach you about something wonderful. It's called the "ellipsis." It means "and so on, in that fashion." It means I don't have to actually type a hundred billion two-letter combinations to illustrate that I'm talking about a hundred gigabytes.
Under the scheme I've been explaining, which semi-periodically embeds a copy of the decoder's source code, you seek forward until you find a long string of bytes with bit 7 clear, which is the signature of US-ASCII text.
Ooops. Didn't find it. That part of the data was lost. It'd be nice if we were still able to recover something. Unfortunately, because Random Slashdot Dumbass #3 was responsible for the archive, and he chose some dumbass format that nobody remembers, all we have is this random list of coefficients with no clue whatsoever as to the algorithm that was used to encode them.
You do realize that "encode" also means "to obscure," right?
Or do you assume that C and
Of course we assume that, you dumbass. That's why it's called an archive. It's meant to last, for all practical purposes, forever. Middle English was in widespread use a mere thousand years ago, but today it's a completely dead language. We don't even use the same character set they used. At the rate English is evolving, a thousand years hence this comment I'm writing right now will be about as understood as "Syððan wæs geworden æt he ferde urh a ceastre and æt castel" is to you today. The only people who can understand Middle English are scholars. If you found a shoebox in your attic filled with letters and postcards written in Middle English, translating them to Modern English would be a massive effort.
The whole idea of creating an archive is to store information in a way that's as recoverable as possible. Expecting the people who want to access that information to (1) understand your language, (2) understand your programming language, and (3) understand all your baroque encoding algorithms is just fundamentally wrong. At that point it's not an archive. The data will be useful for maybe a few decades, possibly, if you're lucky. Beyond that, you're just recovering the archive to get at the refined metals in the disks.
Shift+Alt+M equals upgrade the package the icon came from
Beg pardon? I think maybe you're reaching here. That's a pretty silly example, is it not?
The program you're referring to lets you pick the backend that GStreamer outputs audio and video
Dude, I'm a reasonably intelligent guy, and I don't have the first fucking idea what that's supposed to mean. I'm just gonna take a wild-ass guess here and say that this is the control panel you use to say whether you want sound to come out of the speakers or the headphone jack. Why wrap it in technobabble?
It doesn't have a volume control on it because that isn't related to the function of the program.
Volume isn't related to sound controls? I think you'll find you're mistaken.
You contol the volume through the -- gasp! -- volume control applet in the panel.
What's a panel, and what's an applet? And if I go to the Sound control panel, I'd damn well expect to find controls related to sound there. Telling me they're somewhere else isn't the right answer. Are we constrained by room on the dashboard or the cost of materials? Put a fucking slider control on there, stick a label on it, and call it a day.
Except that the label would evidently be "audiophonic amplitude attenuation," abbreviated to AAA, and it would range from -e to +pi.
Did the 'video' tab escape your notice?
...you know, the one that should read "Sound."
No, it's right up there next to the "Audio" tab
The multimedia systems selector allows you to select which multimedia systems, both audio and video, programs will use. What would you have called it?
Sound and video are two different things. They don't belong together. Break one out and call it -- I'm gonna get wacky here --"Sound," and the other "Video."
Of course, if you have no video card attached to your computer, a "Video" control panel is superfluous. No video output, no need for a "Video" control, see? So if there's no video output (composite, 601, 292M, whatever), there should be no video control panel.
To change the volume, you click on the little volume icon shown at the top right of the screen.
Why is it not included in the "Sound" control panel?
I have seen uglier screen shots ...but not recently.
How are you supposed to tell which is the active window? Why are the window controls not vertically centered inside the window title bars? Why is the type incorrectly kerned? Why are random letters in control labels underlined? Is the scroll bar thumb the light gray part or the dark gray part? Why is some of the type antialiased and some not? Why is there a short horizontal line near the bottom of your "faux Finder" window? Why is there a white line on the left edge of your Terminal window? Where's the resize control on the Terminal window? Where's the scroll bar? And so forth and so on.
I thought that personal tastes are just that. Personal.
Most of the time, they are. But ugly is just ugly, you know?
Gray is a beautiful colour.
Um. It seems like you either misspelled "grey" or you misspelled "color." Pick one and stick with it, huh?
"Assistive Technology" is a silly made-up name for what everybody else on the planet calls "accessibility." It means things like spoken interfaces and screen-readers, magnified displays and shift lock.
"Assistive Technology" is also the most recent in a long, long series of examples of taking a perfectly reasonable idea and making it so bafflingly complicated that even people with lots of computer experience look at it and go, "What the hell?"
Only a computer programmer would take a simple idea like "sound" and call it "multimedia systems selector."
I can't help but notice that the sound control panel -- er, sorry, the "multimedia systems selector audio tab" --doesn't have a volume control on it.
Sigh.
That's fine in principle, but in practice it works like reverse Polish notation. It's something you can learn, yes, but it's backwards.
In English, we "do this to that." That is to say, we apply an action to an object. We don't specify an object and then describe an action. We "open door," we don't "door open."
The nut is that trying to teach people to think object-then-action is a chore. It's a process that has to be learned.
A far, far better paradigm is the gestural paradigm. Click, double-click, click-and-drag. For instance, consider drag and drop. Drag and drop is one of the easiest things to learn. We deal with the same basic paradigm every day. In order to put the banana guacamole in the freezer, I pick it up and put it on the shelf. I don't point to the banana guacamole and then point to the freezer and then give a command. In fact, drag-and-drop is so intuitive that people who have a lot of experience with primitive computer systems often have trouble mastering it. It doesn't seem "natural" to them because they've gone out of their way to learn a different syntax.
Select-then-act has to be learned. Drag-and-drop and other gestural interfaces are far more obvious.
I hope GNOME will take a step ahead and use vector graphics.
IRIX had them long before I used my first SGI machine in 1996. Great in principle, but the downside is that they were ugly as hell. A net loss.
It's a leapfrog thing.
That's real nice in theory, but it doesn't match the facts. For the past 20 years, one company has been right there on the leading edge, and everybody else has been struggling to keep up. About 10 years ago, a new thing came along, and now it's struggling to keep up with the folks who are struggling to keep up with the leader.
And yes, when the status quo is "compared to the leader, we suck," I'd say "let's be as good as the leader" is definitely a worthy goal.
Don't get an MPEG-2 encoded. MPEG-2 is all but dead. The only thing it's still being used for are standard-definition DVDs and broadcast television, two technologies that are on their way out. The future is M.264/AVC.
what part of "none of the graphics in your mac are represented as PDF" ... do you not understand?
The part where I used the word "internally."
LOL. That's a file, you dumbass.
Oh, I'm an idiot. I never even thought of that. I tossed that very extension cable in a draw and never thought of it again. In particular, I never thought of putting it on the mouse. I just always did it the most obvious way: mouse plugs into keyboard, keyboard plugs into monitor, monitor plugs into computer, computer plugs into wall. Easy.
Can you name a major OS that has not been in a legal battle over some sort of IP dispute?
Mac OS X, as far as I know. That's just the first one that springs to mind because it's the one I'm using right now. I'm not aware of any copyright claims made against Apple over the source code to Mac OS X.
(This may be simple ignorance on my part.)
The point is not whether Linux has withstood claims made against it. The point is that there are a number of serious claims right now. For this reason, Linux is a legal hot potato at the moment, and nobody wants to touch it. If these claims are resolved, okay... but there's still the indemnity issue to deal with. So even if the cases disappear tomorrow, Linux is not free and clear from a legal perspective.
Here's a bunch of data:Let's assume, for sake of argument, that you know this is video data. That's not a valid assumption, but let's grant it anyway. Your task is to split this data into frames and decode them into something that can be displayed.
If the data consists of an array of pixels, one right after another, that's easiest. All you need to do is find the boundaries of each frame and then figure out whether the pixels represent color channels or what. Relatively easy.
If the pixel array is run-length encoded, that's also fairly easy. There will be patterns in the data that make it fairly clear that you're dealing with run-length encoded data.
If, on the other hand, the data is a list of quantized coefficients that need to be plugged into a transform algorithm in order to be turned into pixel data, you're screwed. You can brute-force it to try every known transform (DCT, wavelet, whatever) against every permutation of the data set, but at that point you're just grinding metal. The odds of getting useful information out of the data in a reasonable amount of time are so close to zero as to be hardly worth discussing.
Generally speaking, the more clever you are in encoding your data, the less recoverable the encoded data will be. Normally this isn't important, but it becomes vitally important when you start talking about archiving. When it comes to archiving, recoverability is right up there with durability. Everything else is secondary.
Do you understand now?
Okay, now that was funny. I loves me some rich, juicy irony. All is forgiven. You can crack lame jokes all you want, as long as you follow 'em up with great ones.
Why is there OSX antivirus software?
Because there were Classic Mac viruses, and somebody thought it would be a good idea to port Classic Mac anti-virus software to Mac OS X. So now we have Virex and some Norton/Symantec/Whatever product. Nobody uses either one.
Linux is not in the courts right now. Not at all.
What does the sand look like from underneath? I only get to see the top of it from up here.
Because when you're archiving digital data, recoverability is paramount. You have to ask yourself, "What if all I had was a piece of this data, say, a hundred gigabytes from the middle of the disk? Could I turn that data into useful information?"
If you're dealing with a run-length-encoded array of packed pixels, the answer is obviously yes. That's among the simplest forms of encoding known. (If you don't RLE the data it's even simpler, but a trade-off between simplicity and storage requirements is okay as long as you maintain a lot of simplicity.) Even if you don't know how the data was encoded, you've got a good chance of figuring it out just by doing some simple analysis on the bytes. But with a complex encoding scheme, it's much more difficult to figure out what you're dealing with just by looking at it.
When talking about archiving, the objective is to be able to recover as much as possible given as little as possible.