... many IT folks are being pushed to the brink by management that neither trusts nor supports them."
I've seen a lot of evidence that the lack of trust and support is often due to a more basic lack of understanding. Management and IT speak very different languages and have a great deal of difficulty communicating. And usually, they can't admit this in public.
A minor example from a project a few years back: I was working on a bunch of stuff that ran on a server, and spent most of my time in the lab coding and debugging. During one meeting, I made an offhand comment that, since some people were starting to actually use the lab machine because the stuff on it was useful, I really should be running a second copy of the server. I didn't see much reaction, until a few weeks later, a manager came to me with help filling out purchasing forms for another server. I was startled by this, but I quickly figured out the problem.
To the manager(s), the term "server" meant a chunk of hardware. So I quietly explained that I hadn't been talking about hardware. The lab server machine (as I called it) had plenty of power to run several servers processes. I had simply configured a couple more that ran on nonstandard ports, and I was using them for most of my testing. This was better than two machines for my purposes, because being on one machine made regression testing easier. I got across the idea that to us software guys, a "server" was a program, not a machine, and we routinely ran many servers on a single machine.
That incident worked out without problems, because he had come to me in time to stop the acquisition process. It would have been a waste if they'd ordered and delivered a machine that I really didn't need, and I managed to turn it into a minor "learning opportunity". But all too often, language difficulties like this can lead to major misunderstandings and wrong actions on the part of both management and IT.
I'm not sure how to fix this. The obvious solution is to make sure that management includes people who understand IT jargon. But in many (maybe most) companies, this isn't possible. And in any case, it's not something that us IT types can impose on the management types. So the misunderstanding will continue to lead to mistrust and poor support, even when people think they're doing what the other side needs and wants.
Perhaps we should be talking about reviving the original software, in which usenet was propagated between "end nodes", using a flooding algorithm that was an early version of what bittorent uses. If you subscribe to group G, you'd keep the most recent N weeks of G's messages on your system, and periodically your machine would contact several neighbors, exchanging any new messages that anyone didn't have. Your news reader would be a lots faster, since it would be reading from your local disk. And nobody would have to maintain any groups that they didn't personally want.
Lessee; the software has to be around here somewhere...
Usenet is totally obsolete. It was designed around assumptions that haven't applied for a decade, maybe two. Modems are no longer used for server-to-server connections,...
Maybe to those who grew up in the GUI-only world. But to us old-timers, (i.e., anyone with more than 15 or 20 years experience with computers), usenet is still better than the "modern" alternatives. Its main value can be summarized easily: I can read all the discussions with a single "news reader". Which one I use doesn't matter; what matters is that I don't have to master N GUIs to read N discussions.
Yes, there are now zillions of web-based forums. And nearly every one of them requires learning yet another GUI, often requiring javascript. So even if they're all accessible via browser, they all mangle the browser's semantics sufficiently that I have to remember a new set of controls for nearly every forum. I now follow only about half as many as I used to, and I keep detailed notes on how to use each of them, especially the ones that implement any of the pseudo-HTML markup schemes that are floating around.
This was the sort of user-hostile nonsense that usenet and its various "news readers" was designed to fix. Having usenet access cut off is a problem mostly because the "modern" alternatives being pushed are so much more time-consuming to use.
There are a few sites, such as mozilla.org/com, that provide a usenet interface, so we can avoid learning yet another kludgy single-site interface. But the recent moves of the ISPs to shut off usenet will mean a lot of wasted time as people try to adjust to the "herd of cats" nature of web-based forum designs.
And it isn't just Comcast. Hereabouts, we have the choice between them and RCN, and RCN cut off usenet at about the same time. I've seen comments about several other ISPs that have done the same. Maybe there's a move afoot among ISPs to try to kill off this silly usenet thing.
So maybe this is the end of the Endless September...
variable names are so long that you can't fit two of them onto an 80-column punch card
Fixed that for you. Screens indeed.
Heh. Thanks; I forgot that point.
Actually, back in the late 1970s, I did have a job where I wrote Cobol programs that did interactive entry/update of a database via an interactive display. The whole thing was a moral offense to the Cobol programmers in the company. But I was an outside "consultant", so I could get away with it.
What really offended them was that I wrote those programs in one to two pages (on the old IBM printers that were UC only and printed on the white/green striped paper). I used simple variable names in my records, so I could use the CORR(esponding) modifier in my MOVE commands. Can you imagine one-page Cobol programs? The local Cobol guys couldn't, and they weren't impressed. They wanted me out of there. But the date entry people and their managers loved it, so I stayed for several months. (And can you imagine getting a Cobol job done in only a few months?;-)
Then I got a job in a unix shop, and left the Cobol world behind with a huge sigh of relief.
Nah. I am familiar with the java and C# coding cultures, and they do like to use impressively long names, but they typically don't come close to the names that are conventionally used in most Cobol shops.
And, of course, this has little if anything to do with the languages themselves. Cobol, java and C# all allow single-letter variable names. It should be emphasized that it's the cultures that grew up around these languages that determine such things. C, perl and python tend to have rather short names, because they grep up in software (sub)cultures that encourage conciseness. I haven't noticed that this is strongly correlated with readability. The Cobol crowd likes to use sets of long names that differ by only one or two internal characters, and this can sometimes make it rather difficult to read and understand the code.
This is one of the prime examples of why measuring code by "lines" is bogus.
After all, in the typical Cobol program, most of the variable names are so long that you can't fit two of them onto a line on your typical cubicle worker's screen. Of course there are zillions of lines of Cobol code. And all those zillions could probably be expressed in perl or python in maybe 100 lines, or 1000 lines of C. (But you wouldn't be able to read them.)
Is it a book reader? Where are the free books coming from?
It's not hard to find the beginnings of this. Look at wikibooks' WikiJunior for example. There are a number of other online sites with downloadable childrens' books. There seems to be more in Spanish than English, but that may just be a result of where I looked.
One mistake is in thinking that the OLPC project has to supply the books. It's primary design is a network access tool, not as a standalone package. They do supply things like packaged subsets of wikipedia in several languages, with content aimed at younger readers. I recently saw a reference to a 300-MB (compressed) Spanish subset, designed to be loaded into an OLPC central server for use by all the children within range. But again, OLPC doesn't build these; it just works with the local educators to select and package the subsets (and the wikipedia crowd builds all the content).
The OLPC also comes with a browser that brings up the main google page in the local language by default. This is part of the design. The OLPC was designed to primarily provide network access, and the important tools are the ones that help the children find information on the network. Building the content in various languages is Someone Else's Job. Presumably this is mostly the educators, but with network access, anyone (who knows the language) can provide material for the kids.
(And right now they're looking for people who can translate to languages like Quechua and Aymara. So if that's you, get in touch with them.;-)
One thing I'd worry about would be whether Microsoft will follow such precedents, or whether their UI will try hard to steer the kids in the direction of commercial sites. It wouldn't be very difficult to build in knowledge of the freely-accessible sites, and intercede with suggestions that the kids might want to look at other sites first. Remember that Microsoft is a for-profit corporation, and their software will be much like children's TV shows, primarily a marketing tool and only incidentally educational.
It'll also be interesting to see how Microsoft's DRM software works on the OLPC. That could be a good tool for preventing access to public-domain or other free reading material.
We might also observe that there's a good reason that most non-technical dictionaries are of the "descriptive" type. They have generally been created and used to solve a specific problem: Suppose I'm not as fluent in a language (e.g., English or Mandarin) as I might be. I've been reading something in English (or Mandarin), and I've run across a word that I don't know. Or perhaps the meaning(s) that I know for it don't make sense in context. What could the speaker or writer have meant by the word?
If I consult a prescriptive dictionary, it likely won't answer my question. It contains only "proper" definitions of words, as determined by some editor. It doesn't contain all the "erroneous" uses of words. The text I've just run across may have been using the word in question "properly", but there's a good chance this isn't true. If I am to correctly understand the meaning of the text, I should look for a list of all the uses of the word in question. I really should consult a dictionary that lists all the uses of the word, not just the uses that some editor considers "proper". So what I want is a "descriptive" dictionary.
It should be no surprise that descriptive dictionaries are the top sellers. Of course, if I'm reading a technical text, I probably would prefer a prescriptive dictionary that was designed for the text's technical field. But the market for such dictionaries is obviously going to be much smaller than the market for the generalized, descriptive dictionaries.
Well, I have some pretty lucid (;-) memories of channel surfing and watching the news coverage as it happened. Quite early on, before the first tower fell, I found myself thinking out loud that it was funny how often they mentioned Osama bin Laden and al Qaeda, when they hadn't even recovered the planes' wreckage, and they obviously had no idea who had done it. Then it became obvious that they wouldn't recover much from the planes, and by then it was also obvious who was going to get the blame.
Now, perhaps I was just lucky, and I happened to repeatedly change channels just as the new channel was mentioning Osama or al Qaeda. But somehow I don't think my intuition was good enough to pull that off. It seems a lot more likely that they were being mentioned far more than you'd predict from random guesses, and it was happening on most of the channels that were covering the story.
I do sorta wonder if it would be possible to get together most of the original footage (which is no longer measured in feet but in megabytes, of course) of the coverage that morning. Likely not, though. They've probably done a lot of cleaning up, as they edited it down for their restrospectives. I'd guess that much of the original coverage has been scrapped as too redundant. So statistical studies of the coverage probably isn't possible any more.
It might be interesting to investigate, and see just what fraction of the original coverage still exists somewhere. Maybe I could tell whether my channel-changing intuition actually was that good.;-)
1. Stop the moves... to lock-down the Internet and install filters at every ISP,... 2. Bring the Internet to Africa.... 3. Invest in new platforms for free and open digital standards. These are the basis of the Internet and they are being strangled by firms like Microsoft which want to see their own technologies dominate.
All true, but note that this is nothing new. Much of the early history of the Internet was based on exactly these problems. The original US DoD funding for ARPAnet was openly aimed at fighting a growing problem in the military: They were using more and more electronic comm devices, but hardly any two pieces of equipment from different manufacturers could communicate sensibly. The corporate world everywhere wanted customers to buy only from them, and official standards didn't help much. Manufacturers found ways to "enhance" the standards in ways that were incompatible with competitors' equipment.
The solution was to build a new sort of "network" layer that ran on top of all the vendors' incompatible equipment. The new network would encode the data into a binary form that wasn't supposed to be understood by the lower-level equipment. The lower-level stuff was used simply to transport the bits, which at every interface would be translated into whatever form the next equipment could transfer correctly. At the final destination, whatever form the bits arrived in would be translated back into whatever form the last chunk of hardware wanted.
Initially this was expensive. It involved a lot of separate computers (the IMPs) that interceded all over the place. With time, as people understood how to do the job right, and solid-state circuitry became smaller, the job could be moved into circuit cards and then chips that did the same job. Now the Internet part of a gadget is small and cheap.
But the entire point was to admit that the companies that supply the hardware and connectivity would always be trying to sabotage any standards, and force customers to buy only their own equipment by blocking communication with competitors' equipment. The fact that ISPs and telcos are doing the same today should come as no surprise. They always have done this, and they always will. The questions isn't whether we can prevent this; we can't. The question is whether we can get our bits delivered through a network built of unreliable components. The fact that some components are actively trying to block traffic, for whatever reasons, is simply a fact of life. For the network to work, it has to work despite failures (accidental or intentional) on the part of the low-level comm equipment.
One obvious approach is to consider IPv4 as just a vendor-supplied network, and solve the ISPs' sabotage the same way we have for decades: Build another network layer above it that takes into account its failures.
Of course, we're well on our way to doing this. One part is known as "https". Another part is known by the name "mesh". Bittorrent implements another part. And others are under development. With time, we can make the corporate world's sabotage as irrelevant with the same approach we have been using since the 1960s, when the ARPAnet started up. We encode the data into forms that they can't decode, and when they drop or damage too many packets, we route around them.
Such test are eminently reasonable. They're not interested in your results; they're interested in your attitude toward the test. If you don't enjoy a puzzle, and immediately dig into it, you just disqualified yourself as a tech geek. If you're after a management position, they might like your objections. But if you object to being handed a puzzle to solve, and they're trying to hire a technician, you just told them that you lack the primary qualification for the job.
Framing Osama bin Laden for 9/11 does not make any sense, it's just plain paranoid.
Actually, there's a fairly straightforward "theory" that makes sense of it. To see the basis of the theory, look up the media coverage of the WTC attack on 2008-9-11. It's fairly clear from the start that: 1) The authorities and media were totally taken by surprise and unprepared for what was happening; but 2) It was immediately clear who they were blaming. Within the first half hour of news coverage, the media was producing a steady drumbeat of "Osama bin Laden... al Qaeda... Osama bin Laden... al Qaeda... ". They didn't know who did it, but they knew who they were going to blame.
US government agencies weren't much heard from during the first day, probably because they were too busy. By the time they got around to talking to the public, they understood that the job of picking a scapegoat had already been done for them by the media. So they just went with it.
They didn't much want to actually capture bin Laden and his cohort, of course, because they knew that they had little evidence against him that would stand up in any court. He'd probably walk free, with a big propaganda win. From the viewpoint of the Bush crowd, his value wasn't as a jailed or executed criminal; his value was and is as a Foreign Devil. They were interested in finding and punishing the actual perpetrators, yes, but there was little point in going after Osama & Co when they were doing such a commendable job as Foreign Devils.
Of course, this is yet another theory based on sketchy initial facts and little actual inside information. But it does make a bit of sense. It acknowledges the usual government bungling and total failure to pick up on the WTC attack before the fact. It also acknowledges the media's penchant for fomenting mass hysteria and scapegoating of Foreign Devils. And it handles the puzzling question of why US authorities (government and media) show so little interest in hunting down the minor clerical figure who supposedly was the mastermind of it all.
Why not pick a scapegoat who is either easier to blame (like Saddam), or completely fictional (1984 style).
The public image of bin Laden and al Qaeda is mostly fictional. It's true that there are a handful of real people behind the names. But what people "know" about them is pretty much a media creation, with little basis in their actual beliefs or actions. The public Osama is a creation of Hollywood and media newsrooms, with little attention to the person behind the name.
In the future, if anyone else does this they won't let you know, because that means jail time.
This is the main thing that people seem to miss, and is the basis of the old warnings against "shooting the messenger".
A personal example: Back in the early 1980s, I worked with a bunch of "consultants" at a major aerospace firm which shall remain unnamed. We worked on a bunch of database apps on their big IBM mainframe. We faced a growing frustration with the usual territoriality of the various department managers. One evening, a bunch of us decided to stay late and tackle the system's file security. In the morning, we demoed to the company's top management that we could read every file on their system.
Top management's response was to be overjoyed. No longer could their departments hide info about the company's workings. We could give them detailed reports on everything that their computer system knew about.
We also discussed among ourselves an important question: Should we tell IBM about how we had penetrated their file security? After the usual discussion, we all agreed: Nah. IBM has a reputation. IBM would just sic their lawyers on us, and we'd be punished for telling them the bad news.
And, more importantly, other clients would pay us to do the same things on their internal system. If we told IBM, they'd not just try to punish us; they'd fix the holes. Then our exploits wouldn't work, and we couldn't continue to help other companies' management get access to their own data.
Shortly thereafter, I got involved with unix systems, and left the IBM world behind (with a huge sigh of relief;-). I wouldn't be surprised if some of my former colleagues used their knowledge of IBM mainframe security to get jobs somewhat less savory than helping managers get at their own data. But I don't know this for a fact.
I don't think I even want to know. It would be too dangerous to my own safety. I did get involved with some military consultants over the next few years. What I learned there taught me that I never wanted a job involving computer security again. It's just to risky, and the more you know, the more risky it is.
The meta-view, of course, is that it's obvious why our computer security is so poor. When you treat the people who find problems the way they usually get treated, the only possible outcome is that the smart people won't ever want to discuss the topic with you again. This doesn't mean they aren't watching and learning. They're just not talking to strangers about what they may know.
I don't know any solution to this problem. It's human nature to want to punish bearers of bad news. So there may not be a solution.
If what Israel is doing to the Palestinians is "self-defense" then what Apartheid South Africa did to black people was also "self-defense".
If you listen to them, you'll find that the Israelis believe that what they're doing is "self-defense" against radical Palestinians. And the Palistinians believe that what they're doing is "self-defense" against oppressive Israelis. And the while South Africans believed that what they did to black people was "self-defense". And George Bush's supporters believe that his slaughter of large numbers of Iraqis is "self-defense" against terrorists who hate America. And on and on.
That approach won't solve the problems or stop the killing. It never has.
(I'm not sure how to tie in the anti-abortion killings to this. The killers have already been born, so "self-defense" doesn't seem like a possible explanation. But I wouldn't be surprised if they used it, somehow. Or maybe they just use the other popular justification for killing people: "It's God's will.")
I guess I've never searched for "how to make a suicide vest" on YouTube, so I have no basis for how much/little of this stuff was on their site.
You should actually try it. Right now, it gets 24 hits (without the quotes, which is how most people would type it). Go watch them all, and get back to us with how terrified you are.
1) tabs running in separate threads shouldn't bring down the entire browser, if the application was properly designed in the first place;...
Heh; I think you just pinned down the exact cause of all the problems with threaded apps, though perhaps inadvertently. In most of our computer industry, a "properly designed" application is an interesting hypothetical concept, but in the real world such a thing doesn't exist.
OK, perhaps some apps start off properly designed, and stay that way for even a few weeks. But then management gets wind of it, and imposes top-priority requirements that the sofware developer (note the singular noun) had never heard of. Then management notices that said developer is overloaded and can't possibly get all the new requirements running by last week, so more developers are assigned to the task. There isn't time to teach them all about the app's design; there usually isn't time to teach them anything about the design. So you now have a team of people doing a rush job without any common understanding of the app's design.
This is what usually kills threads-based projects. Every one of the programmers might well have a very good, totally consistent design in their mind. But no two of them are thinking of the same design, and they're all implementing according to their own understanding of the design. It doesn't help that we software guys have dozens of different kinds of terminology for such things, often using the same or similar words with different meanings. And we're always under pressure to produce a deliverable by yesterday.
So no matter how good that one developer's initial design might have been, by the time the software is delivered, there isn't the slightest chance that the delivered product was "properly designed in the first place". It wasn't designed at all "in the first place"; that was a different app that has long since been overridden and radically redesigned by management's change orders.
All our popular browsers were "designed" (and redesigned) by teams of a hundred or more people. Anyone who has ever worked on any significant software project knows what that means. And anyone who has ever worked with threaded code knows what it means for the chances of correct interaction between the threads.
I get the impression that Opera might be the most internally consistent of the current flock of browsers. Anyone know how many hands have been in that source code? And how fast is the number growing? Of course, it's proprietary, so we probably can't know the actual numbers.
Firefox is just fine with threads, I see no reason for them to undertake a massive change due to misplaced hype.
What? I'm running FF 3.0.1 here, and it still has the glaring problem that when one thread goes "busy", all tabs in all FF windows go zombie for the duration. I was expecting better from the hype around FF 3, but it hasn't appeared yet, not on this Mac or on my linux boxes. So I handle it by running multiple different browsers. That way, when all of FF's windows/tabs block, I can switch to SeaMonkey, and when SM's windows/tabs all block, I can switch to Opera, and when...
I just upgraded FF on my wife's NT and Vista machines, and it has the same problem there. You get the "busy" pointer, try to switch to another FF window - and nothing happens. So much for the vaunted speed of Windows' threads. And it's not just FF; IE is every bit as bad. If all the tabs in all the app's windows block at once, where's the speed?
This problem was one of the main reasons for going with multiple processes connected by pipes on the original unix systems, more than 30 years ago. And the problem is still with us. If you don't want your entire app blocking when one task gets busy, multiprocessing still works, while multithreading works only occasionally, and all too often everything blocks.
I've long wanted the advantages of shared data spaces that threads give you. But if all the threads block, and the experts (or TFM) can't explain how to prevent this, then I go with multiple processes. It doesn't matter how fast threads can run if they are all getting no cpu time.
Running each instance in a seperate process is NOT new technology
Well of course. It isn't even new in the browser world. In fact it's where we started.
And, as us old-timers know, this architecture was the basis of the original Bell Labs unix system, back in the 1970s. Lots of little, single-task processes communicating via that newfangled sort of file called a "pipe". That was before the advent of our fancy graphical displays, of course.
Somewhat later, in the mid-1980s when we had graphical displays, the tcl language's tk graphics package encouraged the same design by adding to the usual unix-style pipes and forked processes. The language had a simple, elegant "send" command that would let a sub-process run arbitrary commands (typically function calls) inside the parent process using the sub-process's data. The idea was that you have a main process that is responsible for maintaining the on-screen window(s), but the work is done by the sub-processes. This design prevented blocking in the GUI, because the actions that would block were done in the other processes. The result was a language in which GUI tools could be developed very quickly, and would take maximal advantage of any parallelism supplied by the OS.
But that was all decades ago, before most of our current programmers had ever touched a computer. Imagine if we only knew how to design things that way today. Is it possible that current software developers are rediscovering this decades-old sort of design?
Statistics show that tickets with a woman as VP never win.
Well, you're right there! Of course, the confidence interval is rather large.
My favorite statistic is that the average American adult has one breast and one testicle.
(When I've mentioned this in the past, it has often resulted in fun threads from people pointing out that neither number is exactly 1. The mean number of breasts is somewhat over 1, and the mean number of testicles is slightly less than 1. But they're pretty close, closer than most election-year statistics usually are.)
Obama looks taller and he has good hair, he'd get my vote!
Actually, though you meant it as a joke, there's copious evidence that voters generally have a strong preference for the tallest candidate. If you look at election records in the US (and likely other countries as well), and you can get info on the candidates' heights, you'd be surprised at how often the tallest candidate wins. If you're going to bet on election outcomes, this is the simplest way to decide how to bet.
This is generally well known among politicians. It's why, for example, at the "debates", they are often standing on platforms that will make them look the same height to the cameras.
It's just one more illustration of the irrationality of the great majority of the citizenry.
This also turns out to be a good explanation of why women so rarely win elections. Several multivariate analyses of elections have turned up the result that, if you know the candidates' heights, the coefficient for sex drops to zero, and knowing candidates' sex adds nothing useful for predicting the outcome.
So far, I haven't read of any statistical analyses of the effects of hair style. I wonder if there are some actual significant studies on hair and election outcomes. Politicians do act like this is something known, but it could just be their vanity speaking. Anyone know of real data on the topic?
Off-topic, but I have karma to burn and this is a common mistake worth correcting: there is no such word as "nevermind". It's "never mind".
Yeah; you're probably right, at least for now. But you're wasting words on an unwinnable battle. We have fairly good documentation for the evolution of the English language, at least for the past 1000 years or so. It's full of this sort of joining of words into first a cliche phrase and then a single 'word". I've already used a few of them in this paragraph, and you used a few yourself. Look up the etymology of "mistake", for example, which still resembles the original miss+take (i.e., take wrongly), though nowadays (;-) nobody would complain about writing "mistake" as a single word.
Another fun example: A few centuries back, "upstairs" was written "up stairs", and was literal, since you could only get to a higher floor by walking up stairs. Then, in the early 1800s, people developed elevators. At about the same time, people started writing "upstairs" as one word, and it was clearly a collapsed idiom. After all, if I told you I'm going upstairs, and headed for the elveator, you wouldn't call me a liar, because "upstairs" is now a single word that no longer implies the use of stairs.
With "nevermind", you're just seeing the initial stage of another such phrase->idiom->word collapse. You can fight it if you like, but you can't stop it. It's how English works. It's how all human languages work.
[F]or the last fifty years or so we've known how to extract strings from the data segment and thought we understood "the" genetic code. Now it's turning out that all that "junk DNA" in the code segment actually has a significant regulatory role in deciding which strings get printed, and when. Who would have guessed?
Anyone with a background in computer software, for starters.
Consider the page you're reading now, which is in HTML. It's full of all this junk called "tags", which don't appear in the final product on your screen. Some of the tags (such as <HEAD>) totally prevent any text content from appearing in the window (though a <TITLE> tag's content may appear outside the window in its title bar). There may be CSS and/or JavaScript text that doesn't appear on your screen. All this is "junk", pure space-wasting filler, if what you're after is the text content. We can even explicitly include out-of-band "junk" in the form of <!-- HTML comments -->.
If you want to see an even better analogy to DNA, rename a handy.doc file as.txt, and look into it with a plain-text editor. Unlike HTML, where the "junk" stuff is readable, the "junk" parts of a Word doc are binary gibberish that doesn't resemble text in any human language, under any encoding. And if the.doc file has been edited, you're also likely to see fragments of the deleted text, marked as deleted by the "junk" control fields, but still preserved in the file.
DNA has been understood for half a century as a kind of biological "memory". It's parallels to computer memory are obvious. In those few decades, we have devised uncountable ways of encoding data, most of them involving direct parallels to "junk DNA" in the form of fields that tell the software how to parse and interpret the "non-junk" data fields.
Meanwhile, it has become clear that Ma Nature has used vaguely similar encoding schemes for several billion years. And Her encodings are every bit as messy, confused, and full of relics as any of our simple-minded data encodings.
And, like Microsoft, Mother Nature didn't provide documentation for the internals. I wonder if She considers the encoding scheme proprietary?
Slashdot Mirror
... many IT folks are being pushed to the brink by management that neither trusts nor supports them."
I've seen a lot of evidence that the lack of trust and support is often due to a more basic lack of understanding. Management and IT speak very different languages and have a great deal of difficulty communicating. And usually, they can't admit this in public.
A minor example from a project a few years back: I was working on a bunch of stuff that ran on a server, and spent most of my time in the lab coding and debugging. During one meeting, I made an offhand comment that, since some people were starting to actually use the lab machine because the stuff on it was useful, I really should be running a second copy of the server. I didn't see much reaction, until a few weeks later, a manager came to me with help filling out purchasing forms for another server. I was startled by this, but I quickly figured out the problem.
To the manager(s), the term "server" meant a chunk of hardware. So I quietly explained that I hadn't been talking about hardware. The lab server machine (as I called it) had plenty of power to run several servers processes. I had simply configured a couple more that ran on nonstandard ports, and I was using them for most of my testing. This was better than two machines for my purposes, because being on one machine made regression testing easier. I got across the idea that to us software guys, a "server" was a program, not a machine, and we routinely ran many servers on a single machine.
That incident worked out without problems, because he had come to me in time to stop the acquisition process. It would have been a waste if they'd ordered and delivered a machine that I really didn't need, and I managed to turn it into a minor "learning opportunity". But all too often, language difficulties like this can lead to major misunderstandings and wrong actions on the part of both management and IT.
I'm not sure how to fix this. The obvious solution is to make sure that management includes people who understand IT jargon. But in many (maybe most) companies, this isn't possible. And in any case, it's not something that us IT types can impose on the management types. So the misunderstanding will continue to lead to mistrust and poor support, even when people think they're doing what the other side needs and wants.
Perhaps we should be talking about reviving the original software, in which usenet was propagated between "end nodes", using a flooding algorithm that was an early version of what bittorent uses. If you subscribe to group G, you'd keep the most recent N weeks of G's messages on your system, and periodically your machine would contact several neighbors, exchanging any new messages that anyone didn't have. Your news reader would be a lots faster, since it would be reading from your local disk. And nobody would have to maintain any groups that they didn't personally want.
Lessee; the software has to be around here somewhere ...
Usenet is totally obsolete. It was designed around assumptions that haven't applied for a decade, maybe two. Modems are no longer used for server-to-server connections, ...
Maybe to those who grew up in the GUI-only world. But to us old-timers, (i.e., anyone with more than 15 or 20 years experience with computers), usenet is still better than the "modern" alternatives. Its main value can be summarized easily: I can read all the discussions with a single "news reader". Which one I use doesn't matter; what matters is that I don't have to master N GUIs to read N discussions.
Yes, there are now zillions of web-based forums. And nearly every one of them requires learning yet another GUI, often requiring javascript. So even if they're all accessible via browser, they all mangle the browser's semantics sufficiently that I have to remember a new set of controls for nearly every forum. I now follow only about half as many as I used to, and I keep detailed notes on how to use each of them, especially the ones that implement any of the pseudo-HTML markup schemes that are floating around.
This was the sort of user-hostile nonsense that usenet and its various "news readers" was designed to fix. Having usenet access cut off is a problem mostly because the "modern" alternatives being pushed are so much more time-consuming to use.
There are a few sites, such as mozilla.org/com, that provide a usenet interface, so we can avoid learning yet another kludgy single-site interface. But the recent moves of the ISPs to shut off usenet will mean a lot of wasted time as people try to adjust to the "herd of cats" nature of web-based forum designs.
And it isn't just Comcast. Hereabouts, we have the choice between them and RCN, and RCN cut off usenet at about the same time. I've seen comments about several other ISPs that have done the same. Maybe there's a move afoot among ISPs to try to kill off this silly usenet thing.
So maybe this is the end of the Endless September ...
variable names are so long that you can't fit two of them onto an 80-column punch card
Fixed that for you. Screens indeed.
Heh. Thanks; I forgot that point.
Actually, back in the late 1970s, I did have a job where I wrote Cobol programs that did
interactive entry/update of a database via an interactive display. The whole thing was
a moral offense to the Cobol programmers in the company. But I was an outside "consultant",
so I could get away with it.
What really offended them was that I wrote those programs in one to two pages (on the ;-)
old IBM printers that were UC only and printed on the white/green striped paper). I
used simple variable names in my records, so I could use the CORR(esponding) modifier
in my MOVE commands. Can you imagine one-page Cobol programs? The local Cobol guys
couldn't, and they weren't impressed. They wanted me out of there. But the date entry
people and their managers loved it, so I stayed for several months. (And can you imagine
getting a Cobol job done in only a few months?
Then I got a job in a unix shop, and left the Cobol world behind with a huge sigh
of relief.
Nah. I am familiar with the java and C# coding cultures, and they do like to use impressively long names, but they typically don't come close to the names that are conventionally used in most Cobol shops.
And, of course, this has little if anything to do with the languages themselves. Cobol, java and C# all allow single-letter variable names. It should be emphasized that it's the cultures that grew up around these languages that determine such things. C, perl and python tend to have rather short names, because they grep up in software (sub)cultures that encourage conciseness. I haven't noticed that this is strongly correlated with readability. The Cobol crowd likes to use sets of long names that differ by only one or two internal characters, and this can sometimes make it rather difficult to read and understand the code.
This is one of the prime examples of why measuring code by "lines" is bogus.
After all, in the typical Cobol program, most of the variable names are so long that you can't fit two of them onto a line on your typical cubicle worker's screen. Of course there are zillions of lines of Cobol code. And all those zillions could probably be expressed in perl or python in maybe 100 lines, or 1000 lines of C. (But you wouldn't be able to read them.)
Now if /. only had a HHOS moderation ...
OK, how many others here were startled by this report?
Yeah; I was hoping someone would mention them. There are a few others around, too.
Is it a book reader? Where are the free books coming from?
It's not hard to find the beginnings of this. Look at wikibooks' WikiJunior for example. There are a number of other online sites with downloadable childrens' books. There seems to be more in Spanish than English, but that may just be a result of where I looked.
One mistake is in thinking that the OLPC project has to supply the books. It's primary design is a network access tool, not as a standalone package. They do supply things like packaged subsets of wikipedia in several languages, with content aimed at younger readers. I recently saw a reference to a 300-MB (compressed) Spanish subset, designed to be loaded into an OLPC central server for use by all the children within range. But again, OLPC doesn't build these; it just works with the local educators to select and package the subsets (and the wikipedia crowd builds all the content).
The OLPC also comes with a browser that brings up the main google page in the local language by default. This is part of the design. The OLPC was designed to primarily provide network access, and the important tools are the ones that help the children find information on the network. Building the content in various languages is Someone Else's Job. Presumably this is mostly the educators, but with network access, anyone (who knows the language) can provide material for the kids.
(And right now they're looking for people who can translate to languages like Quechua and Aymara. So if that's you, get in touch with them. ;-)
One thing I'd worry about would be whether Microsoft will follow such precedents, or whether their UI will try hard to steer the kids in the direction of commercial sites. It wouldn't be very difficult to build in knowledge of the freely-accessible sites, and intercede with suggestions that the kids might want to look at other sites first. Remember that Microsoft is a for-profit corporation, and their software will be much like children's TV shows, primarily a marketing tool and only incidentally educational.
It'll also be interesting to see how Microsoft's DRM software works on the OLPC. That could be a good tool for preventing access to public-domain or other free reading material.
We might also observe that there's a good reason that most non-technical dictionaries are of the "descriptive" type. They have generally been created and used to solve a specific problem: Suppose I'm not as fluent in a language (e.g., English or Mandarin) as I might be. I've been reading something in English (or Mandarin), and I've run across a word that I don't know. Or perhaps the meaning(s) that I know for it don't make sense in context. What could the speaker or writer have meant by the word?
If I consult a prescriptive dictionary, it likely won't answer my question. It contains only "proper" definitions of words, as determined by some editor. It doesn't contain all the "erroneous" uses of words. The text I've just run across may have been using the word in question "properly", but there's a good chance this isn't true. If I am to correctly understand the meaning of the text, I should look for a list of all the uses of the word in question. I really should consult a dictionary that lists all the uses of the word, not just the uses that some editor considers "proper". So what I want is a "descriptive" dictionary.
It should be no surprise that descriptive dictionaries are the top sellers. Of course, if I'm reading a technical text, I probably would prefer a prescriptive dictionary that was designed for the text's technical field. But the market for such dictionaries is obviously going to be much smaller than the market for the generalized, descriptive dictionaries.
Well, I have some pretty lucid (;-) memories of channel surfing and watching the news coverage as it happened. Quite early on, before the first tower fell, I found myself thinking out loud that it was funny how often they mentioned Osama bin Laden and al Qaeda, when they hadn't even recovered the planes' wreckage, and they obviously had no idea who had done it. Then it became obvious that they wouldn't recover much from the planes, and by then it was also obvious who was going to get the blame.
Now, perhaps I was just lucky, and I happened to repeatedly change channels just as the new channel was mentioning Osama or al Qaeda. But somehow I don't think my intuition was good enough to pull that off. It seems a lot more likely that they were being mentioned far more than you'd predict from random guesses, and it was happening on most of the channels that were covering the story.
I do sorta wonder if it would be possible to get together most of the original footage (which is no longer measured in feet but in megabytes, of course) of the coverage that morning. Likely not, though. They've probably done a lot of cleaning up, as they edited it down for their restrospectives. I'd guess that much of the original coverage has been scrapped as too redundant. So statistical studies of the coverage probably isn't possible any more.
It might be interesting to investigate, and see just what fraction of the original coverage still exists somewhere. Maybe I could tell whether my channel-changing intuition actually was that good. ;-)
1. Stop the moves ... to lock-down the Internet and install filters at every ISP, ... ...
2. Bring the Internet to Africa.
3. Invest in new platforms for free and open digital standards. These are the basis of the Internet and they are being strangled by firms like Microsoft which want to see their own technologies dominate.
All true, but note that this is nothing new. Much of the early history of the Internet was based on exactly these problems. The original US DoD funding for ARPAnet was openly aimed at fighting a growing problem in the military: They were using more and more electronic comm devices, but hardly any two pieces of equipment from different manufacturers could communicate sensibly. The corporate world everywhere wanted customers to buy only from them, and official standards didn't help much. Manufacturers found ways to "enhance" the standards in ways that were incompatible with competitors' equipment.
The solution was to build a new sort of "network" layer that ran on top of all the vendors' incompatible equipment. The new network would encode the data into a binary form that wasn't supposed to be understood by the lower-level equipment. The lower-level stuff was used simply to transport the bits, which at every interface would be translated into whatever form the next equipment could transfer correctly. At the final destination, whatever form the bits arrived in would be translated back into whatever form the last chunk of hardware wanted.
Initially this was expensive. It involved a lot of separate computers (the IMPs) that interceded all over the place. With time, as people understood how to do the job right, and solid-state circuitry became smaller, the job could be moved into circuit cards and then chips that did the same job. Now the Internet part of a gadget is small and cheap.
But the entire point was to admit that the companies that supply the hardware and connectivity would always be trying to sabotage any standards, and force customers to buy only their own equipment by blocking communication with competitors' equipment. The fact that ISPs and telcos are doing the same today should come as no surprise. They always have done this, and they always will. The questions isn't whether we can prevent this; we can't. The question is whether we can get our bits delivered through a network built of unreliable components. The fact that some components are actively trying to block traffic, for whatever reasons, is simply a fact of life. For the network to work, it has to work despite failures (accidental or intentional) on the part of the low-level comm equipment.
One obvious approach is to consider IPv4 as just a vendor-supplied network, and solve the ISPs' sabotage the same way we have for decades: Build another network layer above it that takes into account its failures.
Of course, we're well on our way to doing this. One part is known as "https". Another part is known by the name "mesh". Bittorrent implements another part. And others are under development. With time, we can make the corporate world's sabotage as irrelevant with the same approach we have been using since the 1960s, when the ARPAnet started up. We encode the data into forms that they can't decode, and when they drop or damage too many packets, we route around them.
Such test are eminently reasonable. They're not interested in your results; they're interested in your attitude toward the test. If you don't enjoy a puzzle, and immediately dig into it, you just disqualified yourself as a tech geek. If you're after a management position, they might like your objections. But if you object to being handed a puzzle to solve, and they're trying to hire a technician, you just told them that you lack the primary qualification for the job.
Now to finish today's sudoku ...
Framing Osama bin Laden for 9/11 does not make any sense, it's just plain paranoid.
Actually, there's a fairly straightforward "theory" that makes sense of it. To see the basis of the theory, look up the media coverage of the WTC attack on 2008-9-11. It's fairly clear from the start that: 1) The authorities and media were totally taken by surprise and unprepared for what was happening; but 2) It was immediately clear who they were blaming. Within the first half hour of news coverage, the media was producing a steady drumbeat of "Osama bin Laden ... al Qaeda ... Osama bin Laden ... al Qaeda ... ". They didn't know who did it, but they knew who they were going to blame.
US government agencies weren't much heard from during the first day, probably because they were too busy. By the time they got around to talking to the public, they understood that the job of picking a scapegoat had already been done for them by the media. So they just went with it.
They didn't much want to actually capture bin Laden and his cohort, of course, because they knew that they had little evidence against him that would stand up in any court. He'd probably walk free, with a big propaganda win. From the viewpoint of the Bush crowd, his value wasn't as a jailed or executed criminal; his value was and is as a Foreign Devil. They were interested in finding and punishing the actual perpetrators, yes, but there was little point in going after Osama & Co when they were doing such a commendable job as Foreign Devils.
Of course, this is yet another theory based on sketchy initial facts and little actual inside information. But it does make a bit of sense. It acknowledges the usual government bungling and total failure to pick up on the WTC attack before the fact. It also acknowledges the media's penchant for fomenting mass hysteria and scapegoating of Foreign Devils. And it handles the puzzling question of why US authorities (government and media) show so little interest in hunting down the minor clerical figure who supposedly was the mastermind of it all.
Why not pick a scapegoat who is either easier to blame (like Saddam), or completely fictional (1984 style).
The public image of bin Laden and al Qaeda is mostly fictional. It's true that there are a handful of real people behind the names. But what people "know" about them is pretty much a media creation, with little basis in their actual beliefs or actions. The public Osama is a creation of Hollywood and media newsrooms, with little attention to the person behind the name.
In the future, if anyone else does this they won't let you know, because that means jail time.
This is the main thing that people seem to miss, and is the basis of the old warnings against "shooting the messenger".
A personal example: Back in the early 1980s, I worked with a bunch of "consultants" at a major aerospace firm which shall remain unnamed. We worked on a bunch of database apps on their big IBM mainframe. We faced a growing frustration with the usual territoriality of the various department managers. One evening, a bunch of us decided to stay late and tackle the system's file security. In the morning, we demoed to the company's top management that we could read every file on their system.
Top management's response was to be overjoyed. No longer could their departments hide info about the company's workings. We could give them detailed reports on everything that their computer system knew about.
We also discussed among ourselves an important question: Should we tell IBM about how we had penetrated their file security? After the usual discussion, we all agreed: Nah. IBM has a reputation. IBM would just sic their lawyers on us, and we'd be punished for telling them the bad news.
And, more importantly, other clients would pay us to do the same things on their internal system. If we told IBM, they'd not just try to punish us; they'd fix the holes. Then our exploits wouldn't work, and we couldn't continue to help other companies' management get access to their own data.
Shortly thereafter, I got involved with unix systems, and left the IBM world behind (with a huge sigh of relief ;-). I wouldn't be surprised if some of my former colleagues used their knowledge of IBM mainframe security to get jobs somewhat less savory than helping managers get at their own data. But I don't know this for a fact.
I don't think I even want to know. It would be too dangerous to my own safety. I did get involved with some military consultants over the next few years. What I learned there taught me that I never wanted a job involving computer security again. It's just to risky, and the more you know, the more risky it is.
The meta-view, of course, is that it's obvious why our computer security is so poor. When you treat the people who find problems the way they usually get treated, the only possible outcome is that the smart people won't ever want to discuss the topic with you again. This doesn't mean they aren't watching and learning. They're just not talking to strangers about what they may know.
I don't know any solution to this problem. It's human nature to want to punish bearers of bad news. So there may not be a solution.
If what Israel is doing to the Palestinians is "self-defense" then what Apartheid South Africa did to black people was also "self-defense".
If you listen to them, you'll find that the Israelis believe that what they're doing is "self-defense" against radical Palestinians. And the Palistinians believe that what they're doing is "self-defense" against oppressive Israelis. And the while South Africans believed that what they did to black people was "self-defense". And George Bush's supporters believe that his slaughter of large numbers of Iraqis is "self-defense" against terrorists who hate America. And on and on.
That approach won't solve the problems or stop the killing. It never has.
(I'm not sure how to tie in the anti-abortion killings to this. The killers have already been born, so "self-defense" doesn't seem like a possible explanation. But I wouldn't be surprised if they used it, somehow. Or maybe they just use the other popular justification for killing people: "It's God's will.")
I guess I've never searched for "how to make a suicide vest" on YouTube, so I have no basis for how much/little of this stuff was on their site.
You should actually try it. Right now, it gets 24 hits (without the quotes, which is how most people would type it). Go watch them all, and get back to us with how terrified you are.
... what's next? Video games and TV/movie violence- because we don't trust our children to know the difference between fantasy and reality?
How about we ban campaign ads, because we don't trust our politicians to know the difference between fantasy and reality?
1) tabs running in separate threads shouldn't bring down the entire browser, if the application was properly designed in the first place; ...
Heh; I think you just pinned down the exact cause of all the problems with threaded apps, though perhaps inadvertently. In most of our computer industry, a "properly designed" application is an interesting hypothetical concept, but in the real world such a thing doesn't exist.
OK, perhaps some apps start off properly designed, and stay that way for even a few weeks. But then management gets wind of it, and imposes top-priority requirements that the sofware developer (note the singular noun) had never heard of. Then management notices that said developer is overloaded and can't possibly get all the new requirements running by last week, so more developers are assigned to the task. There isn't time to teach them all about the app's design; there usually isn't time to teach them anything about the design. So you now have a team of people doing a rush job without any common understanding of the app's design.
This is what usually kills threads-based projects. Every one of the programmers might well have a very good, totally consistent design in their mind. But no two of them are thinking of the same design, and they're all implementing according to their own understanding of the design. It doesn't help that we software guys have dozens of different kinds of terminology for such things, often using the same or similar words with different meanings. And we're always under pressure to produce a deliverable by yesterday.
So no matter how good that one developer's initial design might have been, by the time the software is delivered, there isn't the slightest chance that the delivered product was "properly designed in the first place". It wasn't designed at all "in the first place"; that was a different app that has long since been overridden and radically redesigned by management's change orders.
All our popular browsers were "designed" (and redesigned) by teams of a hundred or more people. Anyone who has ever worked on any significant software project knows what that means. And anyone who has ever worked with threaded code knows what it means for the chances of correct interaction between the threads.
I get the impression that Opera might be the most internally consistent of the current flock of browsers. Anyone know how many hands have been in that source code? And how fast is the number growing? Of course, it's proprietary, so we probably can't know the actual numbers.
Firefox is just fine with threads, I see no reason for them to undertake a massive change due to misplaced hype.
What? I'm running FF 3.0.1 here, and it still has the glaring problem that when one thread goes "busy", all tabs in all FF windows go zombie for the duration. I was expecting better from the hype around FF 3, but it hasn't appeared yet, not on this Mac or on my linux boxes. So I handle it by running multiple different browsers. That way, when all of FF's windows/tabs block, I can switch to SeaMonkey, and when SM's windows/tabs all block, I can switch to Opera, and when ...
I just upgraded FF on my wife's NT and Vista machines, and it has the same problem there. You get the "busy" pointer, try to switch to another FF window - and nothing happens. So much for the vaunted speed of Windows' threads. And it's not just FF; IE is every bit as bad. If all the tabs in all the app's windows block at once, where's the speed?
This problem was one of the main reasons for going with multiple processes connected by pipes on the original unix systems, more than 30 years ago. And the problem is still with us. If you don't want your entire app blocking when one task gets busy, multiprocessing still works, while multithreading works only occasionally, and all too often everything blocks.
I've long wanted the advantages of shared data spaces that threads give you. But if all the threads block, and the experts (or TFM) can't explain how to prevent this, then I go with multiple processes. It doesn't matter how fast threads can run if they are all getting no cpu time.
And, as us old-timers know, this architecture was the basis of the original Bell Labs unix system, back in the 1970s. Lots of little, single-task processes communicating via that newfangled sort of file called a "pipe". That was before the advent of our fancy graphical displays, of course.
Somewhat later, in the mid-1980s when we had graphical displays, the tcl language's tk graphics package encouraged the same design by adding to the usual unix-style pipes and forked processes. The language had a simple, elegant "send" command that would let a sub-process run arbitrary commands (typically function calls) inside the parent process using the sub-process's data. The idea was that you have a main process that is responsible for maintaining the on-screen window(s), but the work is done by the sub-processes. This design prevented blocking in the GUI, because the actions that would block were done in the other processes. The result was a language in which GUI tools could be developed very quickly, and would take maximal advantage of any parallelism supplied by the OS.
But that was all decades ago, before most of our current programmers had ever touched a computer. Imagine if we only knew how to design things that way today. Is it possible that current software developers are rediscovering this decades-old sort of design?
Statistics show that tickets with a woman as VP never win.
Well, you're right there! Of course, the confidence interval is rather large.
My favorite statistic is that the average American adult has one breast and one testicle.
(When I've mentioned this in the past, it has often resulted in fun threads from people pointing out that neither number is exactly 1. The mean number of breasts is somewhat over 1, and the mean number of testicles is slightly less than 1. But they're pretty close, closer than most election-year statistics usually are.)
Obama looks taller and he has good hair, he'd get my vote!
Actually, though you meant it as a joke, there's copious evidence that voters generally have a strong preference for the tallest candidate. If you look at election records in the US (and likely other countries as well), and you can get info on the candidates' heights, you'd be surprised at how often the tallest candidate wins. If you're going to bet on election outcomes, this is the simplest way to decide how to bet.
This is generally well known among politicians. It's why, for example, at the "debates", they are often standing on platforms that will make them look the same height to the cameras.
It's just one more illustration of the irrationality of the great majority of the citizenry.
This also turns out to be a good explanation of why women so rarely win elections. Several multivariate analyses of elections have turned up the result that, if you know the candidates' heights, the coefficient for sex drops to zero, and knowing candidates' sex adds nothing useful for predicting the outcome.
So far, I haven't read of any statistical analyses of the effects of hair style. I wonder if there are some actual significant studies on hair and election outcomes. Politicians do act like this is something known, but it could just be their vanity speaking. Anyone know of real data on the topic?
Off-topic, but I have karma to burn and this is a common mistake worth correcting: there is no such word as "nevermind". It's "never mind".
Yeah; you're probably right, at least for now. But you're wasting words on an unwinnable battle. We have fairly good documentation for the evolution of the English language, at least for the past 1000 years or so. It's full of this sort of joining of words into first a cliche phrase and then a single 'word". I've already used a few of them in this paragraph, and you used a few yourself. Look up the etymology of "mistake", for example, which still resembles the original miss+take (i.e., take wrongly), though nowadays (;-) nobody would complain about writing "mistake" as a single word.
Another fun example: A few centuries back, "upstairs" was written "up stairs", and was literal, since you could only get to a higher floor by walking up stairs. Then, in the early 1800s, people developed elevators. At about the same time, people started writing "upstairs" as one word, and it was clearly a collapsed idiom. After all, if I told you I'm going upstairs, and headed for the elveator, you wouldn't call me a liar, because "upstairs" is now a single word that no longer implies the use of stairs.
With "nevermind", you're just seeing the initial stage of another such phrase->idiom->word collapse. You can fight it if you like, but you can't stop it. It's how English works. It's how all human languages work.
Now back to our regularly scheduled discussion ...
[F]or the last fifty years or so we've known how to extract strings from the data segment and thought we understood "the" genetic code. Now it's turning out that all that "junk DNA" in the code segment actually has a significant regulatory role in deciding which strings get printed, and when. Who would have guessed?
Anyone with a background in computer software, for starters.
Consider the page you're reading now, which is in HTML. It's full of all this junk called "tags", which don't appear in the final product on your screen. Some of the tags (such as <HEAD>) totally prevent any text content from appearing in the window (though a <TITLE> tag's content may appear outside the window in its title bar). There may be CSS and/or JavaScript text that doesn't appear on your screen. All this is "junk", pure space-wasting filler, if what you're after is the text content. We can even explicitly include out-of-band "junk" in the form of <!-- HTML comments -->.
If you want to see an even better analogy to DNA, rename a handy .doc file as .txt, and look into it with a plain-text editor. Unlike HTML, where the "junk" stuff is readable, the "junk" parts of a Word doc are binary gibberish that doesn't resemble text in any human language, under any encoding. And if the .doc file has been edited, you're also likely to see fragments of the deleted text, marked as deleted by the "junk" control fields, but still preserved in the file.
DNA has been understood for half a century as a kind of biological "memory". It's parallels to computer memory are obvious. In those few decades, we have devised uncountable ways of encoding data, most of them involving direct parallels to "junk DNA" in the form of fields that tell the software how to parse and interpret the "non-junk" data fields.
Meanwhile, it has become clear that Ma Nature has used vaguely similar encoding schemes for several billion years. And Her encodings are every bit as messy, confused, and full of relics as any of our simple-minded data encodings.
And, like Microsoft, Mother Nature didn't provide documentation for the internals. I wonder if She considers the encoding scheme proprietary?