When I made my first open-source release in the early 1980s..., there were probably less than five open-source projects in the world.
You've missed a lot of computing history. Maybe the capitalized phrase "Open Source" was new, but the practice wasn't. For instance, before the mini/micro-computer "revolution", I worked on a number of IBM mainframes, all of which used VM as their main OS. VM originated in academia, and its source was always available to anyone interested. Of course, not too many people wanted it unless they had an IBM mainframe. Most such installations had a VM guru on the staff, and the VM gurus I knew were quite open with their source.
Around the same time, on one such machines, the engineering staff brought in Amdahl's unix system, which ran on VM of course. When we asked about source, the reply was "That's not an option; you get it whether you want it or not." "Open Source" may not have been a catch phrase yet, but Amdahl was happy to have customers with employees who could read the source, since that made their support job a lot easier. In fact, I sent them a kernel bug fix about a month after we got the system installed; I got back a nice "Thanks!" letter and was added to their published list of code contributors.
A more accurate history would be that open source was quite common before the mid-1980s, but it didn't need a name. Software vendors routinely gave source to customers who wanted it, with the expectation that customers would find and fix bugs and maybe add new features. One of Microsoft's innovations was to hold their source as proprietary, so as not to allow customers to improve the software. A lot of people were amazed that customers actually accepted this. You heard a lot of questions like "Would they buy a truck or car that couldn't be worked on by any mechanics except the manufacturer's?" But then, when it became clear that Microsoft had gotten away with such a dodgy scheme, it was quickly adopted by others, so that customers would have to pay them for patching up the bugs.
It still sorta amazes me that customers can be so dense as to pay money for products that can't be repaired by anyone but the manufacturer (and usually now not even by them). So much for the economists' idea of a rational marketplace.
[I]f the entire bible is to be taken word for word literally, I'm dissapointed that the museum of natural history has no displays for the unicorns and dragons mentioned in it.
Well, when I was at the U of Wisconsin a couple of decades ago, one of the displays in the zoology dept's building contained two unicorn skulls. The accompanying text explained that they were real skulls from (formerly) living animals, and hadn't been "doctored" in any way. It also said that farmers have been producing them for centuries, and explained how.
The skulls were actually from goats with a single horn in the middle of the forehead. Such horns start as "horn buds" that are a thick patch of skin that at first isn't attached to the skull. A horn is actually a modified hair (or fish scale, if you prefer) that forms in a follicle, and grows a root into the bone as an anchor. You take a baby goat (kid) and a sharp knife. You slice off one horn bud. You make a Z-shaped incision around the other, giving you two triangular flaps of skin. The outer flap contains the remaining horn bud at its tip. Each triangle has a blood supply through its one uncut edge. You lift the flaps and interchange them, so the horn bud is positioned at the center of the forehead. A bit of suturing and a bandage, and the skin reattaches and heals. Any experienced veterinary surgeon should be able to do this easily. The horn grows normally in the middle of the forehead, and the animal learns to use it like any normal goat would use its two horns.
This doesn't work with horses, of course, since foals don't have horn buds. So the mythical horse-derived unicorn can't be created this way. But it works with goats, sheep and cattle, and probably with other horned animals.
I wonder why the Creation Museum wouldn't have a unicorn skull? Maybe because people would challenge them as fakes (like the horned rabbit skulls you see in tourist shops). If they were to explain the skull's origin, they'd have to get into actual biology, and that wouldn't be too comfortable for "creation scientists". It's probably safer to just ignore the issue.
Of course, dragons are too obvious. We do have a great many fossils of creatures very much like dragons, as well as a few rather large living reptiles. There are no modern flying reptiles, but we have fossils of them. None of them looked very much like our cartoon dragons, but then, Mickey Mouse and Bugs Bunny don't look very much like a real mouse or rabbit. I wonder if the creation-science people have written about dragons. For that matter, why didn't the biologists who first identified those funny "dinosaur" fossils call them dragons? Or maybe some of them did, but they were voted down?
Why is the creationism debate on Slashdot always posed as "Idiots who think God magiced the Earth into existence last tuesday*" vs "Reasonable people"?
Heresy!
It was last Thursday. Everyone knows that. Everyone who went to Thursday School as a child, that is. The rest are godless heathens, of course.
With all of that said, I have to say that the evolution crowd is often guilty of over-reaching by concocting hypothetical ways life may have originated. See Richard Dawkin's "The Blind Watchmaker" for a really good chuckle about how life began as clay.
Well, I wouldn't call that over-reaching. Granted, the origin of life is a different topic than the subsequent evolution of millions of species. But there's an obvious relation between the two. I'd sorta expect evolutionary biologists (and other interested scientists) to at least consider the question of how it all started.
As for those clays, I'd just list that as an interesting hypothesis. It's difficult to test, but so are all the other hypotheses about life's origin. So what we'd expect scientists to do is come up with as many such scenarios as they can think of. If we get them all out on the table, maybe others will come up with some useful tests.
The "panspermia" hypothesis isn't really a true origin hypothesis, of course. It merely removes the question from the Earth by suggesting that the origin may have been elsewhere. Astronomers explained several decades ago how micro-organisms can be expected to travel about the galaxy. Astronomers have also pointed out that the Earth's "dust tail" (much like a comet's tail, but thinner) contains lots of dust particles the size of bacterial spores, and the Earth has almost certainly been spraying this dust out into the galaxy for a few billion years. Presumably this happens with any other planet that has bacterial life. We don't really know much about the long-term viability of such spores over the many millions of years it would take to colonize another planet, but the scenario is reasonable according to our current data. It's likely that all those dust clouds out in the galaxy contain a tiny percentage of dormant bacterial spores, and some of them came from our Earth.
There's also the recent discovery of bacteria many kilometers down by the various deep-drilling projects. This has led to a "hot rock" scenario for the origins of life. This is also difficult to test, but it's another interesting hypothesis.
You can't stop scientists from making up hypotheses about such things, any more than you can stop the religious folks from claiming that their god did it. The main difference is that the scientists don't take them seriously until someone can turn up some good evidence.
Common sense, after all, tells us the Earth is flat.
Maybe if you live in Kansas. I grew up in the Seattle area, where most of the horizon (when it's clear enough to see that far;-) is taken up by a lot of very bumpy mountains. Now I live near Boston, which is generally a bit flatter, but I live on an obvious hill and the view out my windows shows several other very obvious hills.
I've also spent time along the edge of oceans or large lakes, where the way that boats disappear over the horizon from the bottom up is very obvious. Or, if you're on the boat, buildings on shore also disappear from their bottom up. So the surface of the water is quite obviously not a plane. To a sailor, the world looks and acts like a curved surface of some sort, and this has been understood for millennia.
OTOH, I did sorta like the study[1] published a few years ago showing that Kansas is quite literally flatter than a pancake, by several orders of magnitude. So some parts of the Earth really are flat.
[1] Annals of Improbable Research, Volume 9, Number 3, May 2003 , pp. 16-18(3).
In any case, scientists rarely try to convince creationists. It's not worth the effort. Rather, the main goal of scientists is to find evidence about what really happened, and discuss theories to explain the data. Discussing such things with religious people is a pointless waste of time. It's a lot more interesting to discuss it with people who are open to reasoning about new ideas and new data.
Of course, you can't stop the religious folks from noticing and intruding, and you can't really reason with people who ignore or willfully misinterpret evidence. But you can usually simply ignore them, continue your field research, and discuss the results.
There is a lot of experience in the online world saying that serious biological discussions need to be in a semi-restricted, moderated setting. You can see the reasons fairly clearly here on/., with the constant attempts to deflect any biological topic to a discussion of religious pseudo-theories. This makes truly open discussions difficult, as you must try to teach the participants about logic, and that tends to take so much space that it buries the original topic. So public fora like/. are mostly useful for posting links to other sites where the topic may be discussed in some depth.
Moreover, given the advantage Gate's OS has maintained for decades and its nearly endemic nature of viral infection...pretty much anybody logging onto a bank's servers has a virus on it and all a bank need do is task the police to recover a computer, find a virus and claim the bank is not at fault.
Well, now; it seems this situation is ripe for a nice setup. Get an account at a bank such as the Egg mentioned in other messages here, which strongly encourages use of IE and includes Active-X code in its pages. Arrange for your account data to be stolen by malware from a site that uses Active X as an infection vector. When the bank's investigators find the malware on your machine and disclaims responsibility, file suit against the bank, claiming fraud and entrapment (or whatever those are called in UK law). Show in court that they strongly encourage use of IE and Active X, which are well known to be major security risks.
I'd think some UK solicitors with a bit of tech knowledge might have a bit of fun taking on such a case.
Of course, you'd want to do this with a new account, and don't put a whole lot of your money into it.
It's only a matter of time before such a case happens. It might be best if it happens to people with the technical knowledge to show in court what's really going on. Maybe you can force the banks to not require customer use of the least secure software available.
If OOXML is to be an ISO standard, we'll be stuck with it
How so? OSI was (and still is) an ISO standard, which was supposed to supplant IP. How many of your computers are part of an OSI network? Do you know of any computers anywhere that are?
I was involved in a few ISO committees that worked on parts of the OSI standard. I was there as a rep from a smaller company that was developing the standards. We were repeatedly hit with things that sounded very much like this OOXML snafu. We'd suddenly find ourselves reading proposed standards docs that baffled all us tech guys. "How the hell can anyone implement this?" Invariably, it turned out that the new text came from consultants paid by a few of the big network companies, and what they were trying to do was get their own proprietary stuff rubber-stamped as part of the standard. And, as in this case, it always turned out that the proposed specs weren't detailed and unambiguous enough that we saw a way to implement them.
This sort of thing didn't derail ISO back in the 1980s, and it didn't in the 1990s. Why would it today?
Among my questions about Internet service is whether I'm permitted to run my own servers. I have a site (with several domain names) on which I provide net space for a small collection of friends and relatives. Nothing terribly commercial, except marginally for a couple of local bands. But keeping such things on a personal machine can be a good idea. That way you don't run afoul of the ISPs' penchant for claiming ownership of any files that you put on the "hosted" web site that they so conveniently provide for you. This is especially important for the bands, who would be rather upset if they found out that their ISP had claimed their MP3s and was selling them or using them in ads.
Right now, I have a DSL account through speakeasy, whose TOS promise that I can do all of this, and they won't take it away from me. The other ISPs hereabouts either flatly forbid home servers or "reserve the right" to change their permissions without notice. And they won't sell commercial service to a "home" customer. So FIOS et al would eliminate such family-and-friends services, as well as risking my friends' bands' control of their own recordings.
Anyone know of general solutions to this sort of problem? Not just for me, but for all the other geeks either doing or thinking of something similar? Is there a way we can put our own stuff online, and guarantee that the ISP can't take it away from us and use it for their own commercial purposes?
Does it annoy anybody else that a cup of coffee is a standard in and of itself?
Nah; anyone interested in actual standard measurements would be using (milli)liters. If you use the English Imperial system (or even worse, the American variant), you're stating right up front that you don't really care about standards. If you did, why would you intentionally use a "standard" that's designed to be confusing and illogical?
With coffee, a "cup" is the amount that nearly fills whatever size cup you happen to have grabbed off the shelf. And it means about the same thing in any retail establishment, except that you didn't choose the cup yourself.
It's especially meaningless when you consider how easy it is to vary the strength of the coffee. The amount of caffeine (and flavor chemicals) in a "cup" of coffee varies by a factor of 4 or 5, depending on all the obvious factors.
I thought the whole constitution had no application to the whole government?
After all, isn't it just a scrap of paper?
No, actually Bush was wrong about that, too. The US Constitution was written on parchment, not paper.
The Bush crowd just can't get anything right.;-)
(To further confuse matters, replicas of the Constitution are commonly printed on "parchment paper", which is a kind of paper treated to superficially resemble parchment. But the original was on true parchment, made from stretched animal skin. A quick google search didn't turn up info on what sort of animal it was made from, though presumably that's known.)
I can't believe that posters here are taking the original poster seriously as he is basically asking for advice on how to create submarine patents for the open source community.
I'm not sure I follow this. The "open source community", as far as I can tell, isn't a "person" in any legal sense, and can't sue or be sued. However, I am a "person", and I can be sued. What the OP was talking about was publishing his own ideas in such a way that a corporation can't later claim to own those ideas and sue him for using them.
Hey folks, when did the ends start justifying the means?
I also don't see how this applies. The "end" is a situation where I can use my own ideas without fear that a corporation can take my ideas and sue me for using them. The traditional "means" of doing this is prior publication, which if done correctly can invalidate a later patent claim. This seems to me to be quite justified, considering the history of corporations taking others' ideas, patenting them, and suing the originators for infringement.
In any case, the OP was asking how to correctly do prior publication in our current legal situation (which is essentially incomprehensible to the anyone but a trained IP lawyer). I'd think this is a topic that's well worth explaining to us laypersons.
Part of the current legal situation is that I, as a software developer, can easily be sued for violating patents that I don't have a chance of understanding. I and many others would like to know if we're just "screwed", or whether there might be some defense again this that we can understand and use effectively.
One major problem is: How would I know that I'd been charged fairly?
In my experience, when I get details of my net usage, there's a lot of stuff there that I can neither control nor account for. Thus, most browsers honor a page's request to refresh it every N minutes, and don't give me a way to turn it off. Any browser that's running can be using bandwidth without most users being aware of the fact. This is especially true for pages that include advertising.
For a while, I had a smartphone with wireless net access. Even when I didn't use it, it ran up packet charges. When I asked, I was simply told that the networking software sends packets on its own. "That's how it works." It's not obvious how a customer can challenge something like this, except via extremely expensive lawsuits.
And what about that advertising? I didn't want it, but it comes "free" with the content that I wanted. Would I be charged for downloading the ads? Of course, I would; what a silly question. Even (or especially) the flash ads. Yeah, I have flashblock installed, but not all browsers honor it, and not all users are aware that it's possible, so this is a potential source of large charges by the ISP.
But the fundamental question is: When my ISP tells me I used X gigabytes last month, how do I know they're not just making up a number? What tools are available that will tell a customer exactly how many bytes of bandwidth they actually used? And if this number differs from the ISP's number, would the accounting tools' data stand up in court?
Unless you can answer this, a pay-per-byte scheme is merely an way for an ISP to charge customers whatever they like, and the customers have no recourse other than to terminate the service entirely.
If people disapprove of Microsoft's standards, then they should NOT USE THEM! PERIOD!!
Well, that's easy enough to say, but it can be pretty difficult if the "use" is reuired by a government agency with the power to send you to jail if you don't reply properly.
And the whole point of a "standard" like this is to make it legal for government agencies to send you docs in a Microsoft format that you are legally required to read and reply to. Either that, or you hire someone who can read it for you.
I have a few friends that are very busy right about now, because here in the US it's tax season, and their job is helping people do their taxes. They all explain how they hate Microsoft, but they have to use it, because a lot of the government's tax docs and forms are only available now in computer form, and most of them are only in MS formats.
The pretense of most standards agencies is that a standard is open to everyone, and anyone can implement software or other equipment according to the standard. But it's fairly common for standards agencies to rubber-stamp standards that are poorly defined. This is usually done by approving a standard written by "consultant" paid by a corporation, and the actual standard describes something that the corporation sells. This makes it nearly impossible for independents to develop to the standard, because you can't know the obscure details hidden in the big corporation's product. What you have to do is try to reverse-engineer the spec, and you always miss something. Customers inevitably come across cases that your product doesn't handle "correctly" (i.e., exactly the same as the big corporation's products). At that point, you lose all future sales to that customer, because their management decrees buying only the big corporation's products "to prevent similar future compatibility problems".
It's an old story. And the ISO has produced such standards many times. I worked for a few years back in the 1980s on some projects that involved developing ISO networking standards. We were repeatedly hit with proposed revisions to a new standard that made absolutely no sense to any of us. It always turned out that the text was written by people paid by IBM or Microsoft or Cisco or a few other major networking firms. It was clear that unless we could present a logical technical argument against the text, it would be accepted in the standard. And "We don't understand any way to implement it" wasn't a logical argument. (It was merely an admission of our ignorance.;-)
Of course, the resulting confused mess was a lot of why OSI lost out to IP. And most of the corporate "contributions" to OSI were clearly intended as sabotage, since the corporations all wanted their own network rubber-stamped as the standard. They were sorta blindsided by the Internet, which they also didn't own (though they're working on that). But they did succeed in making OSI a standard that nobody much wanted to implement.
The only real news here is the extreme in-your-face arrogance of Microsoft this time around. Usually such problems are kept quiet until it's too late to do anything. But MS seems to feel that they can easily win this one. They may be right. Online discussions in the tech community don't seem to have affected the process very much, and chances are we can't really do anything about it. So we can look forward to a future of working with a poorly-specified standard that we'll never be able to implement correctly. In this case, there will be a big corporation selling software that complies with the standard, though of course "compliance" will be practically defined as working exactly as Microsoft's software does.
When I was in graduate school in the mid '90's I thought Parallelism would be the next big thing.
When I was in grad school back in the 1970s, people thought parallelism would be the next big thing, and it had some interesting technical challenges, so I got into it as much as was possible back then. Then I got out into the Real World [TM], where such ideas just got blank looks and "Let's move on" replies.
Some what later, in the 1980s, I worked on projects at several companies who thought that parallelism was the next big thing. That time around, I got my hands on a number of machines with hundreds of processors and gigabytes (Wow!) of memory, so I could actually try out some of the ideas from the previous decade. The main things that I learned was that 1) many of the concepts were viable, and 2) debugging in an environment where nothing is reproducible is hard. And I moved on, mostly to networking projects where you could actually do loosely-coupled multiprocessing (though management still gave you blank looks if you started talking in such terms).
Now we're getting personal computers with more than one processor. It's been a bit of a wait, but we even have management saying it's the "new^N thing". And debugging parallel code is still hard.
I'll predict that 1) We'll see a lot of commercial parallelized apps now, and 2) those apps will never be debugged, giving us flakiness that outshines the worst of what Microsoft sold back in the 1980s and 1990s. We'll still have the rush to market; developers will still be held to nonsensical schedules; debugging will still be treated as an "after-market" service; and we developers will still be looking for debugging tools that work for more than toy examples (and work with a customer's app that has been running for months when a show-stopper bug pops up).
There's a reason that, despite the existence of multi-process machines for several decades, we still have very little truly parallel code that works. Debugging the stuff is hard, mostly because bugs can rarely be reproduced.
(Of course, this won't prevent the flood of magical snake-oil tools that promise to solve the problem. There's a lot of money to be made there.;-)
... your entire post was contained in the GP's comment about distcc?
Well, maybe, but it's also clear from the parent comment and several others in the general discussion that there's a belief that compilation is an example of a process that's not parallelizable. So I though maybe, for the benefit of those who haven't read everything here, it might be useful to point out that parallized versions of make have been around for a couple of decades, and compilation is actually a process that can easily benefit from the obvious use of multiple cpus to do cc commands in parallel.
It is funny how people get that such things are difficult. Of course, in this case there's little need for threads, since the chunks can run in parallel without any communication other than what's provided by every file system. But then, there seems to be a lot of conflation of different kinds of parallelism, some of which are easy (and we've done for decades), while others are very hard.
The discussion here seems to be among people that mostly consider parallelism to be a single problem. In reality, it's a collection of independent problems that have the misfortune of being covered by a single English-language term. Sorta like the medical field's problems with talking about "diseases" like the cold, flu, and cancer, each of which is a cover term for hundreds or thousands of different diseases that happen to share some major symptoms. They all illustrate the old problem of people thinking that they understand a problem when they've given it a name.
Nobody has THAT much experience with Ajax, or.NET, or whatever.
You can try and learn all the decades worth of back material in order to catch up, but if you try and apply for one of those jobs that requires those skills, the HR department will still want someone with decades of experience. So attempting to enter those fields is rather futile.
Well, I already decided that getting Ajax or.NET jobs was futile, when I started reading jobs ads that required 3 or 5 years experience with them in the first couple years they were available.
But that's an old story. I recall back in the 1980s, when a certain unnamed DBS had been out for about a year, and all the job ads asked for 3-5 years experience with it. That did a lot to dissuade me from becoming a DBS expert. Just as well, I suppose, because I know a bunch of people who are, and I mostly feel sympathy for them when they talk about their jobs.
The really interesting work is being done in how to do multithreading without mutexes, semaphores, and all the other lock-based concurrency systems, which I'm surprised to see few people talking about in my skimming so far. Possibly because the old bucks aren't aware of these things, think they aren't fundamentally different, or possibly think they've been tried already.
Well, yes, a lot of them have been tried already. I published a paper (in one of them there geeky computer journals;-) about one such scheme about 25 years ago, and I've had a number of discussions with others that have done similar things. What a lot of us old bucks have seen is something different: We keep finding that the groups' managers simply don't believe that our weird scheme can work, and order us to use mutexes and semaphores.
In a few cases, I've managed to sorta sneak more efficient sync schemes into the code when nobody was looking. And in a few cases, when this was discovered, someone else rewrote the code with the usual locks, "so that it'll work". They never actually had evidence that it didn't work; they just "knew" that it couldn't work, and wanted to make sure that the software didn't depend on untested methods. The result inevitably was a significant loss of speed, of course, but that didn't matter.
Maybe I should start looking into such things again. Sometimes it can take a few decades (or centuries) for people to adopt something that has been rediscovered by many people in the past. Sometimes we have to wait until an idea gets into the textbooks, so that the younger bucks have heard about it and will consider using it. Meanwhile, those of us who know a bit of history are condemned to watch history repeat itself unnecessarily.
Who was it that said that most discoveries are named after the last person who discovered them? (Because once a discovery has a proper name attached, it can no longer be claimed as a new discovery.;-)
Compilation is expressly NOT a parallelizable problem.
Well, yes and no. Maybe the single sub-task of converting a.c file to a.o file isn't parallelizable, but the overall task of converting a flock of.c files (and.a or.so files) to an executable is very parallelizable.
A few years back, I was involved in some unix kernel development on a system with 200+ processors and a terabyte or so of memory. The make(1) command had been extended to accept an environment variable or command-line option telling it how many parallel subprocesses it was allowed to run. The kernel consists of thousands of mostly small.c files, of course. The limit on a build was actually the speed at which make's storm of cc commands could be rendered on the terminal. Occasionally I had to clean out all the.o files and do a total build. There was a blur of cc commands shown on the screen, and in under a minute, the build was done. Most of the "cc -o foo.c" commands could be run in parallel with all the rest; the only exceptions were a few that had to wait for an #included file to be created.
Of course, this isn't "parallelism" in the multi-threaded sense that most people here are talking about. But parallelism at the coarser level of individual cc commands is parallelism. In this case, it did produce a speedup of nearly 200x. I verified this once by setting the allowed parallelism to 1, and verifying that it took about 200 times longer than usual. (I went out to lunch while it ran.;-)
There are a few known tasks that can benefit significantly from parallelism. Some of them have tiny chunk sizes, others (like compilation) have fairly large chunks. The latter are usually easily handled by independent processes, and that's something that we understand fairly well today. It's really the ones with smaller chunk sizes and need to share large amounts of data that cause problems. We don't much know how to debug those, and our "system" software isn't of much help yet.
you can have multiple child instances in the same nine months by throwing more women at the problem.
True, and this corresponds directly to the approach to parallelism that the more experienced programmers have found works best: Divide the task among independently-running processes (mothers). Each one can devote its time and resources to its piece of the task, and it scales up to millions of processors (mothers) simultaneously.
Even in the case of colonial species like ants and bees, with a single mother per hive and thousands of young developing as any time, the work still isn't done inside the one mother. Rather, she produces only small fertilized eggs, and hands them over to workers for care and development. This similarly provides for many independently-running development processes, with the "processors" (workers) able to switch rapidly between larvae as needed.
Those of us who have worked on single-process ("threaded") parallelism have learned the hard way why Ma Nature has repeatedly done it this way. With a single process, the coordination and synchronization rapidly becomes so expensive and complex that the task typically runs slower than the version with many separate processes. It may be true that a few special tasks have been found (e.g., array arithmetic) that work well in parallel within a single process. But very few such tasks are known, and attempting single-process parallelism with most things we've done just turns out to be a loser.
Debugging is especially difficult, since multi-threaded tasks are generally not reproducible. This eliminates most of our debugging tools. Nature had billions of years to experiment; she could throw resources at the task and ruthlessly prune the huge majority of failures. We haven't had billions of years (or even hundreds) to develop software, though, so it's not surprising that we've done poorly at something that nature has generally given up on because it doesn't work well.
And employers generally don't look kindly on an approach of "Write thousands of programs, trying to find one that works, and throw the rest away".
(Actually, people have tried to use ants and bees as software models. There are some interesting lessons, especially for network operations. But the metaphor sorta falls apart if you look at it too closely. An ant isn't very much like a process at the atomic/bit level.;-)
Other examples exist, where such a move actually worked. You can see a lot of Linux distributions that live off the idea that yes, you can technically get it for free, but enough people will want the support and pay us for it. I know it's not very popular here to bash linux distris (the first one to make a csh or ash joke gets kill -9'ed), but do you think they wouldn't start trying a similar stunt if it didn't work, and people just downloaded their distris, then get support from other parties?
Heh. Except that in this case, those "other parties" are the primary companies. Red Hat, Debian, Suse, etc. advertise quite openly that this is exactly what they're doing. Most of the FOSS community supports them, because they're honest about what they're doing (and they contribute valuable stuff back to the code base). After all, business people keep saying that they use IBM/Microsoft because of the customer support. Since linux itself (and the GNU stuff) don't come from the factory with any support, it makes sense that support companies would spring up to offer support to people and companies that don't want or can't afford their own crew of computer geeks.
What's annoying with this story is that Microsoft has produced the same sort of external-support ecosystem. In this case, MS claims to supply customer support, but it's so crappy that companies will pay other people for the support that MS doesn't actually supply. I have a number of friends who are making a living this way. And note that the support companies generally don't have full access to the source code, which limits what they can do for customers.
Actually, there's a much better auto analogy than what either of us used. Some histories have been written recently about the story of leaded gasoline. Google for "gasoline history tetraethyl lead" for lots of info. It seems that back in the 1920s, the auto industry knew quite well that ethanol did about as good a job as an anti-knock additive as gasoline history tetraethyl lead. But ethanol was cheap and public domain, while tetraethyl lead was patented and thus only available at a monopoly price from the patent owner (Du Pont). Via the well-known technique of interlocking directorates, the auto and petroleum industries decided to ignore cheap things like ethanol, and sell engines that used leaded gasoline. This had a disastrous effect on public health, but it enriched the bank accounts of those industry's leaders. It was completely open and legal in the US and most of the rest of the world.
At least in the current story, Meraki didn't change their product so that it poisoned their customers. Though if they did, and they used a patented poison, history says that US courts would probably support them. (At least we'd expect that people here on/. would vociferously support their right to damage their customers' health.;-)
Slashdot Mirror
When I made my first open-source release in the early 1980s ..., there were probably less than five open-source projects in the world.
You've missed a lot of computing history. Maybe the capitalized phrase "Open Source" was new, but the practice wasn't. For instance, before the mini/micro-computer "revolution", I worked on a number of IBM mainframes, all of which used VM as their main OS. VM originated in academia, and its source was always available to anyone interested. Of course, not too many people wanted it unless they had an IBM mainframe. Most such installations had a VM guru on the staff, and the VM gurus I knew were quite open with their source.
Around the same time, on one such machines, the engineering staff brought in Amdahl's unix system, which ran on VM of course. When we asked about source, the reply was "That's not an option; you get it whether you want it or not." "Open Source" may not have been a catch phrase yet, but Amdahl was happy to have customers with employees who could read the source, since that made their support job a lot easier. In fact, I sent them a kernel bug fix about a month after we got the system installed; I got back a nice "Thanks!" letter and was added to their published list of code contributors.
A more accurate history would be that open source was quite common before the mid-1980s, but it didn't need a name. Software vendors routinely gave source to customers who wanted it, with the expectation that customers would find and fix bugs and maybe add new features. One of Microsoft's innovations was to hold their source as proprietary, so as not to allow customers to improve the software. A lot of people were amazed that customers actually accepted this. You heard a lot of questions like "Would they buy a truck or car that couldn't be worked on by any mechanics except the manufacturer's?" But then, when it became clear that Microsoft had gotten away with such a dodgy scheme, it was quickly adopted by others, so that customers would have to pay them for patching up the bugs.
It still sorta amazes me that customers can be so dense as to pay money for products that can't be repaired by anyone but the manufacturer (and usually now not even by them). So much for the economists' idea of a rational marketplace.
[I]f the entire bible is to be taken word for word literally, I'm dissapointed that the museum of natural history has no displays for the unicorns and dragons mentioned in it.
Well, when I was at the U of Wisconsin a couple of decades ago, one of the displays in the zoology dept's building contained two unicorn skulls. The accompanying text explained that they were real skulls from (formerly) living animals, and hadn't been "doctored" in any way. It also said that farmers have been producing them for centuries, and explained how.
The skulls were actually from goats with a single horn in the middle of the forehead. Such horns start as "horn buds" that are a thick patch of skin that at first isn't attached to the skull. A horn is actually a modified hair (or fish scale, if you prefer) that forms in a follicle, and grows a root into the bone as an anchor. You take a baby goat (kid) and a sharp knife. You slice off one horn bud. You make a Z-shaped incision around the other, giving you two triangular flaps of skin. The outer flap contains the remaining horn bud at its tip. Each triangle has a blood supply through its one uncut edge. You lift the flaps and interchange them, so the horn bud is positioned at the center of the forehead. A bit of suturing and a bandage, and the skin reattaches and heals. Any experienced veterinary surgeon should be able to do this easily. The horn grows normally in the middle of the forehead, and the animal learns to use it like any normal goat would use its two horns.
This doesn't work with horses, of course, since foals don't have horn buds. So the mythical horse-derived unicorn can't be created this way. But it works with goats, sheep and cattle, and probably with other horned animals.
I wonder why the Creation Museum wouldn't have a unicorn skull? Maybe because people would challenge them as fakes (like the horned rabbit skulls you see in tourist shops). If they were to explain the skull's origin, they'd have to get into actual biology, and that wouldn't be too comfortable for "creation scientists". It's probably safer to just ignore the issue.
Of course, dragons are too obvious. We do have a great many fossils of creatures very much like dragons, as well as a few rather large living reptiles. There are no modern flying reptiles, but we have fossils of them. None of them looked very much like our cartoon dragons, but then, Mickey Mouse and Bugs Bunny don't look very much like a real mouse or rabbit. I wonder if the creation-science people have written about dragons. For that matter, why didn't the biologists who first identified those funny "dinosaur" fossils call them dragons? Or maybe some of them did, but they were voted down?
Why is the creationism debate on Slashdot always posed as "Idiots who think God magiced the Earth into existence last tuesday*" vs "Reasonable people"?
Heresy!
It was last Thursday. Everyone knows that. Everyone who went to Thursday School as a child, that is. The rest are godless heathens, of course.
With all of that said, I have to say that the evolution crowd is often guilty of over-reaching by concocting hypothetical ways life may have originated. See Richard Dawkin's "The Blind Watchmaker" for a really good chuckle about how life began as clay.
Well, I wouldn't call that over-reaching. Granted, the origin of life is a different topic than the subsequent evolution of millions of species. But there's an obvious relation between the two. I'd sorta expect evolutionary biologists (and other interested scientists) to at least consider the question of how it all started.
As for those clays, I'd just list that as an interesting hypothesis. It's difficult to test, but so are all the other hypotheses about life's origin. So what we'd expect scientists to do is come up with as many such scenarios as they can think of. If we get them all out on the table, maybe others will come up with some useful tests.
The "panspermia" hypothesis isn't really a true origin hypothesis, of course. It merely removes the question from the Earth by suggesting that the origin may have been elsewhere. Astronomers explained several decades ago how micro-organisms can be expected to travel about the galaxy. Astronomers have also pointed out that the Earth's "dust tail" (much like a comet's tail, but thinner) contains lots of dust particles the size of bacterial spores, and the Earth has almost certainly been spraying this dust out into the galaxy for a few billion years. Presumably this happens with any other planet that has bacterial life. We don't really know much about the long-term viability of such spores over the many millions of years it would take to colonize another planet, but the scenario is reasonable according to our current data. It's likely that all those dust clouds out in the galaxy contain a tiny percentage of dormant bacterial spores, and some of them came from our Earth.
There's also the recent discovery of bacteria many kilometers down by the various deep-drilling projects. This has led to a "hot rock" scenario for the origins of life. This is also difficult to test, but it's another interesting hypothesis.
You can't stop scientists from making up hypotheses about such things, any more than you can stop the religious folks from claiming that their god did it. The main difference is that the scientists don't take them seriously until someone can turn up some good evidence.
Common sense, after all, tells us the Earth is flat.
;-) is taken up by a lot of very bumpy mountains. Now I live near Boston, which is generally a bit flatter, but I live on an obvious hill and the view out my windows shows several other very obvious hills.
Maybe if you live in Kansas. I grew up in the Seattle area, where most of the horizon (when it's clear enough to see that far
I've also spent time along the edge of oceans or large lakes, where the way that boats disappear over the horizon from the bottom up is very obvious. Or, if you're on the boat, buildings on shore also disappear from their bottom up. So the surface of the water is quite obviously not a plane. To a sailor, the world looks and acts like a curved surface of some sort, and this has been understood for millennia.
OTOH, I did sorta like the study[1] published a few years ago showing that Kansas is quite literally flatter than a pancake, by several orders of magnitude. So some parts of the Earth really are flat.
[1] Annals of Improbable Research, Volume 9, Number 3, May 2003 , pp. 16-18(3).
In any case, scientists rarely try to convince creationists. It's not worth the effort. Rather, the main goal of scientists is to find evidence about what really happened, and discuss theories to explain the data. Discussing such things with religious people is a pointless waste of time. It's a lot more interesting to discuss it with people who are open to reasoning about new ideas and new data.
/., with the constant attempts to deflect any biological topic to a discussion of religious pseudo-theories. This makes truly open discussions difficult, as you must try to teach the participants about logic, and that tends to take so much space that it buries the original topic. So public fora like /. are mostly useful for posting links to other sites where the topic may be discussed in some depth.
Of course, you can't stop the religious folks from noticing and intruding, and you can't really reason with people who ignore or willfully misinterpret evidence. But you can usually simply ignore them, continue your field research, and discuss the results.
There is a lot of experience in the online world saying that serious biological discussions need to be in a semi-restricted, moderated setting. You can see the reasons fairly clearly here on
Moreover, given the advantage Gate's OS has maintained for decades and its nearly endemic nature of viral infection...pretty much anybody logging onto a bank's servers has a virus on it and all a bank need do is task the police to recover a computer, find a virus and claim the bank is not at fault.
Well, now; it seems this situation is ripe for a nice setup. Get an account at a bank such as the Egg mentioned in other messages here, which strongly encourages use of IE and includes Active-X code in its pages. Arrange for your account data to be stolen by malware from a site that uses Active X as an infection vector. When the bank's investigators find the malware on your machine and disclaims responsibility, file suit against the bank, claiming fraud and entrapment (or whatever those are called in UK law). Show in court that they strongly encourage use of IE and Active X, which are well known to be major security risks.
I'd think some UK solicitors with a bit of tech knowledge might have a bit of fun taking on such a case.
Of course, you'd want to do this with a new account, and don't put a whole lot of your money into it.
It's only a matter of time before such a case happens. It might be best if it happens to people with the technical knowledge to show in court what's really going on. Maybe you can force the banks to not require customer use of the least secure software available.
If OOXML is to be an ISO standard, we'll be stuck with it
How so? OSI was (and still is) an ISO standard, which was supposed to supplant IP. How many of your computers are part of an OSI network? Do you know of any computers anywhere that are?
I was involved in a few ISO committees that worked on parts of the OSI standard. I was there as a rep from a smaller company that was developing the standards. We were repeatedly hit with things that sounded very much like this OOXML snafu. We'd suddenly find ourselves reading proposed standards docs that baffled all us tech guys. "How the hell can anyone implement this?" Invariably, it turned out that the new text came from consultants paid by a few of the big network companies, and what they were trying to do was get their own proprietary stuff rubber-stamped as part of the standard. And, as in this case, it always turned out that the proposed specs weren't detailed and unambiguous enough that we saw a way to implement them.
This sort of thing didn't derail ISO back in the 1980s, and it didn't in the 1990s. Why would it today?
Among my questions about Internet service is whether I'm permitted to run my own servers. I have a site (with several domain names) on which I provide net space for a small collection of friends and relatives. Nothing terribly commercial, except marginally for a couple of local bands. But keeping such things on a personal machine can be a good idea. That way you don't run afoul of the ISPs' penchant for claiming ownership of any files that you put on the "hosted" web site that they so conveniently provide for you. This is especially important for the bands, who would be rather upset if they found out that their ISP had claimed their MP3s and was selling them or using them in ads.
Right now, I have a DSL account through speakeasy, whose TOS promise that I can do all of this, and they won't take it away from me. The other ISPs hereabouts either flatly forbid home servers or "reserve the right" to change their permissions without notice. And they won't sell commercial service to a "home" customer. So FIOS et al would eliminate such family-and-friends services, as well as risking my friends' bands' control of their own recordings.
Anyone know of general solutions to this sort of problem? Not just for me, but for all the other geeks either doing or thinking of something similar? Is there a way we can put our own stuff online, and guarantee that the ISP can't take it away from us and use it for their own commercial purposes?
Does it annoy anybody else that a cup of coffee is a standard in and of itself?
Nah; anyone interested in actual standard measurements would be using (milli)liters. If you use the English Imperial system (or even worse, the American variant), you're stating right up front that you don't really care about standards. If you did, why would you intentionally use a "standard" that's designed to be confusing and illogical?
With coffee, a "cup" is the amount that nearly fills whatever size cup you happen to have grabbed off the shelf. And it means about the same thing in any retail establishment, except that you didn't choose the cup yourself.
It's especially meaningless when you consider how easy it is to vary the strength of the coffee. The amount of caffeine (and flavor chemicals) in a "cup" of coffee varies by a factor of 4 or 5, depending on all the obvious factors.
I thought the whole constitution had no application to the whole government?
;-)
After all, isn't it just a scrap of paper?
No, actually Bush was wrong about that, too. The US Constitution was written on parchment, not paper.
The Bush crowd just can't get anything right.
(To further confuse matters, replicas of the Constitution are commonly printed on "parchment paper", which is a kind of paper treated to superficially resemble parchment. But the original was on true parchment, made from stretched animal skin. A quick google search didn't turn up info on what sort of animal it was made from, though presumably that's known.)
. One would think they could tweak the source in firefox to change the address bar a different color for .mil addresses or something.
;-)
Except that they'd mostly need to tweak the source for Internet Explorer, and they probably don't have access to that.
Not much chance of becoming a non-planet like Pluto - it's 14 times the mass of Jupiter, ...
...
But there is the possibility that it'll go the other way, by accreting enough mass to graduate and become a small star.
Stick around for a few hundred thousand years, and find out
I can't believe that posters here are taking the original poster seriously as he is basically asking for advice on how to create submarine patents for the open source community.
I'm not sure I follow this. The "open source community", as far as I can tell, isn't a "person" in any legal sense, and can't sue or be sued. However, I am a "person", and I can be sued. What the OP was talking about was publishing his own ideas in such a way that a corporation can't later claim to own those ideas and sue him for using them.
Hey folks, when did the ends start justifying the means?
I also don't see how this applies. The "end" is a situation where I can use my own ideas without fear that a corporation can take my ideas and sue me for using them. The traditional "means" of doing this is prior publication, which if done correctly can invalidate a later patent claim. This seems to me to be quite justified, considering the history of corporations taking others' ideas, patenting them, and suing the originators for infringement.
In any case, the OP was asking how to correctly do prior publication in our current legal situation (which is essentially incomprehensible to the anyone but a trained IP lawyer). I'd think this is a topic that's well worth explaining to us laypersons.
Part of the current legal situation is that I, as a software developer, can easily be sued for violating patents that I don't have a chance of understanding. I and many others would like to know if we're just "screwed", or whether there might be some defense again this that we can understand and use effectively.
One major problem is: How would I know that I'd been charged fairly?
In my experience, when I get details of my net usage, there's a lot of stuff there that I can neither control nor account for. Thus, most browsers honor a page's request to refresh it every N minutes, and don't give me a way to turn it off. Any browser that's running can be using bandwidth without most users being aware of the fact. This is especially true for pages that include advertising.
For a while, I had a smartphone with wireless net access. Even when I didn't use it, it ran up packet charges. When I asked, I was simply told that the networking software sends packets on its own. "That's how it works." It's not obvious how a customer can challenge something like this, except via extremely expensive lawsuits.
And what about that advertising? I didn't want it, but it comes "free" with the content that I wanted. Would I be charged for downloading the ads? Of course, I would; what a silly question. Even (or especially) the flash ads. Yeah, I have flashblock installed, but not all browsers honor it, and not all users are aware that it's possible, so this is a potential source of large charges by the ISP.
But the fundamental question is: When my ISP tells me I used X gigabytes last month, how do I know they're not just making up a number? What tools are available that will tell a customer exactly how many bytes of bandwidth they actually used? And if this number differs from the ISP's number, would the accounting tools' data stand up in court?
Unless you can answer this, a pay-per-byte scheme is merely an way for an ISP to charge customers whatever they like, and the customers have no recourse other than to terminate the service entirely.
What is this NSFW thing you keep talking about?
New South Fuckin' Wales maybe?
If people disapprove of Microsoft's standards, then they should NOT USE THEM! PERIOD!!
;-)
Well, that's easy enough to say, but it can be pretty difficult if the "use" is reuired by a government agency with the power to send you to jail if you don't reply properly.
And the whole point of a "standard" like this is to make it legal for government agencies to send you docs in a Microsoft format that you are legally required to read and reply to. Either that, or you hire someone who can read it for you.
I have a few friends that are very busy right about now, because here in the US it's tax season, and their job is helping people do their taxes. They all explain how they hate Microsoft, but they have to use it, because a lot of the government's tax docs and forms are only available now in computer form, and most of them are only in MS formats.
The pretense of most standards agencies is that a standard is open to everyone, and anyone can implement software or other equipment according to the standard. But it's fairly common for standards agencies to rubber-stamp standards that are poorly defined. This is usually done by approving a standard written by "consultant" paid by a corporation, and the actual standard describes something that the corporation sells. This makes it nearly impossible for independents to develop to the standard, because you can't know the obscure details hidden in the big corporation's product. What you have to do is try to reverse-engineer the spec, and you always miss something. Customers inevitably come across cases that your product doesn't handle "correctly" (i.e., exactly the same as the big corporation's products). At that point, you lose all future sales to that customer, because their management decrees buying only the big corporation's products "to prevent similar future compatibility problems".
It's an old story. And the ISO has produced such standards many times. I worked for a few years back in the 1980s on some projects that involved developing ISO networking standards. We were repeatedly hit with proposed revisions to a new standard that made absolutely no sense to any of us. It always turned out that the text was written by people paid by IBM or Microsoft or Cisco or a few other major networking firms. It was clear that unless we could present a logical technical argument against the text, it would be accepted in the standard. And "We don't understand any way to implement it" wasn't a logical argument. (It was merely an admission of our ignorance.
Of course, the resulting confused mess was a lot of why OSI lost out to IP. And most of the corporate "contributions" to OSI were clearly intended as sabotage, since the corporations all wanted their own network rubber-stamped as the standard. They were sorta blindsided by the Internet, which they also didn't own (though they're working on that). But they did succeed in making OSI a standard that nobody much wanted to implement.
The only real news here is the extreme in-your-face arrogance of Microsoft this time around. Usually such problems are kept quiet until it's too late to do anything. But MS seems to feel that they can easily win this one. They may be right. Online discussions in the tech community don't seem to have affected the process very much, and chances are we can't really do anything about it. So we can look forward to a future of working with a poorly-specified standard that we'll never be able to implement correctly. In this case, there will be a big corporation selling software that complies with the standard, though of course "compliance" will be practically defined as working exactly as Microsoft's software does.
When I was in graduate school in the mid '90's I thought Parallelism would be the next big thing.
;-)
When I was in grad school back in the 1970s, people thought parallelism would be the next big thing, and it had some interesting technical challenges, so I got into it as much as was possible back then. Then I got out into the Real World [TM], where such ideas just got blank looks and "Let's move on" replies.
Some what later, in the 1980s, I worked on projects at several companies who thought that parallelism was the next big thing. That time around, I got my hands on a number of machines with hundreds of processors and gigabytes (Wow!) of memory, so I could actually try out some of the ideas from the previous decade. The main things that I learned was that 1) many of the concepts were viable, and 2) debugging in an environment where nothing is reproducible is hard. And I moved on, mostly to networking projects where you could actually do loosely-coupled multiprocessing (though management still gave you blank looks if you started talking in such terms).
Now we're getting personal computers with more than one processor. It's been a bit of a wait, but we even have management saying it's the "new^N thing". And debugging parallel code is still hard.
I'll predict that 1) We'll see a lot of commercial parallelized apps now, and 2) those apps will never be debugged, giving us flakiness that outshines the worst of what Microsoft sold back in the 1980s and 1990s. We'll still have the rush to market; developers will still be held to nonsensical schedules; debugging will still be treated as an "after-market" service; and we developers will still be looking for debugging tools that work for more than toy examples (and work with a customer's app that has been running for months when a show-stopper bug pops up).
There's a reason that, despite the existence of multi-process machines for several decades, we still have very little truly parallel code that works. Debugging the stuff is hard, mostly because bugs can rarely be reproduced.
(Of course, this won't prevent the flood of magical snake-oil tools that promise to solve the problem. There's a lot of money to be made there.
literally [lit'-ra-li] adv. See figuratively.
... your entire post was contained in the GP's comment about distcc?
Well, maybe, but it's also clear from the parent comment and several others in the general discussion that there's a belief that compilation is an example of a process that's not parallelizable. So I though maybe, for the benefit of those who haven't read everything here, it might be useful to point out that parallized versions of make have been around for a couple of decades, and compilation is actually a process that can easily benefit from the obvious use of multiple cpus to do cc commands in parallel.
It is funny how people get that such things are difficult. Of course, in this case there's little need for threads, since the chunks can run in parallel without any communication other than what's provided by every file system. But then, there seems to be a lot of conflation of different kinds of parallelism, some of which are easy (and we've done for decades), while others are very hard.
The discussion here seems to be among people that mostly consider parallelism to be a single problem. In reality, it's a collection of independent problems that have the misfortune of being covered by a single English-language term. Sorta like the medical field's problems with talking about "diseases" like the cold, flu, and cancer, each of which is a cover term for hundreds or thousands of different diseases that happen to share some major symptoms. They all illustrate the old problem of people thinking that they understand a problem when they've given it a name.
Well, I already decided that getting Ajax or
But that's an old story. I recall back in the 1980s, when a certain unnamed DBS had been out for about a year, and all the job ads asked for 3-5 years experience with it. That did a lot to dissuade me from becoming a DBS expert. Just as well, I suppose, because I know a bunch of people who are, and I mostly feel sympathy for them when they talk about their jobs.
The really interesting work is being done in how to do multithreading without mutexes, semaphores, and all the other lock-based concurrency systems, which I'm surprised to see few people talking about in my skimming so far. Possibly because the old bucks aren't aware of these things, think they aren't fundamentally different, or possibly think they've been tried already.
;-) about one such scheme about 25 years ago, and I've had a number of discussions with others that have done similar things. What a lot of us old bucks have seen is something different: We keep finding that the groups' managers simply don't believe that our weird scheme can work, and order us to use mutexes and semaphores.
;-)
Well, yes, a lot of them have been tried already. I published a paper (in one of them there geeky computer journals
In a few cases, I've managed to sorta sneak more efficient sync schemes into the code when nobody was looking. And in a few cases, when this was discovered, someone else rewrote the code with the usual locks, "so that it'll work". They never actually had evidence that it didn't work; they just "knew" that it couldn't work, and wanted to make sure that the software didn't depend on untested methods. The result inevitably was a significant loss of speed, of course, but that didn't matter.
Maybe I should start looking into such things again. Sometimes it can take a few decades (or centuries) for people to adopt something that has been rediscovered by many people in the past. Sometimes we have to wait until an idea gets into the textbooks, so that the younger bucks have heard about it and will consider using it. Meanwhile, those of us who know a bit of history are condemned to watch history repeat itself unnecessarily.
Who was it that said that most discoveries are named after the last person who discovered them? (Because once a discovery has a proper name attached, it can no longer be claimed as a new discovery.
Compilation is expressly NOT a parallelizable problem.
.c file to a .o file isn't parallelizable, but the overall task of converting a flock of .c files (and .a or .so files) to an executable is very parallelizable.
.c files, of course. The limit on a build was actually the speed at which make's storm of cc commands could be rendered on the terminal. Occasionally I had to clean out all the .o files and do a total build. There was a blur of cc commands shown on the screen, and in under a minute, the build was done. Most of the "cc -o foo.c" commands could be run in parallel with all the rest; the only exceptions were a few that had to wait for an #included file to be created.
;-)
Well, yes and no. Maybe the single sub-task of converting a
A few years back, I was involved in some unix kernel development on a system with 200+ processors and a terabyte or so of memory. The make(1) command had been extended to accept an environment variable or command-line option telling it how many parallel subprocesses it was allowed to run. The kernel consists of thousands of mostly small
Of course, this isn't "parallelism" in the multi-threaded sense that most people here are talking about. But parallelism at the coarser level of individual cc commands is parallelism. In this case, it did produce a speedup of nearly 200x. I verified this once by setting the allowed parallelism to 1, and verifying that it took about 200 times longer than usual. (I went out to lunch while it ran.
There are a few known tasks that can benefit significantly from parallelism. Some of them have tiny chunk sizes, others (like compilation) have fairly large chunks. The latter are usually easily handled by independent processes, and that's something that we understand fairly well today. It's really the ones with smaller chunk sizes and need to share large amounts of data that cause problems. We don't much know how to debug those, and our "system" software isn't of much help yet.
you can have multiple child instances in the same nine months by throwing more women at the problem.
;-)
True, and this corresponds directly to the approach to parallelism that the more experienced programmers have found works best: Divide the task among independently-running processes (mothers). Each one can devote its time and resources to its piece of the task, and it scales up to millions of processors (mothers) simultaneously.
Even in the case of colonial species like ants and bees, with a single mother per hive and thousands of young developing as any time, the work still isn't done inside the one mother. Rather, she produces only small fertilized eggs, and hands them over to workers for care and development. This similarly provides for many independently-running development processes, with the "processors" (workers) able to switch rapidly between larvae as needed.
Those of us who have worked on single-process ("threaded") parallelism have learned the hard way why Ma Nature has repeatedly done it this way. With a single process, the coordination and synchronization rapidly becomes so expensive and complex that the task typically runs slower than the version with many separate processes. It may be true that a few special tasks have been found (e.g., array arithmetic) that work well in parallel within a single process. But very few such tasks are known, and attempting single-process parallelism with most things we've done just turns out to be a loser.
Debugging is especially difficult, since multi-threaded tasks are generally not reproducible. This eliminates most of our debugging tools. Nature had billions of years to experiment; she could throw resources at the task and ruthlessly prune the huge majority of failures. We haven't had billions of years (or even hundreds) to develop software, though, so it's not surprising that we've done poorly at something that nature has generally given up on because it doesn't work well.
And employers generally don't look kindly on an approach of "Write thousands of programs, trying to find one that works, and throw the rest away".
(Actually, people have tried to use ants and bees as software models. There are some interesting lessons, especially for network operations. But the metaphor sorta falls apart if you look at it too closely. An ant isn't very much like a process at the atomic/bit level.
Other examples exist, where such a move actually worked. You can see a lot of Linux distributions that live off the idea that yes, you can technically get it for free, but enough people will want the support and pay us for it. I know it's not very popular here to bash linux distris (the first one to make a csh or ash joke gets kill -9'ed), but do you think they wouldn't start trying a similar stunt if it didn't work, and people just downloaded their distris, then get support from other parties?
/. would vociferously support their right to damage their customers' health. ;-)
Heh. Except that in this case, those "other parties" are the primary companies. Red Hat, Debian, Suse, etc. advertise quite openly that this is exactly what they're doing. Most of the FOSS community supports them, because they're honest about what they're doing (and they contribute valuable stuff back to the code base). After all, business people keep saying that they use IBM/Microsoft because of the customer support. Since linux itself (and the GNU stuff) don't come from the factory with any support, it makes sense that support companies would spring up to offer support to people and companies that don't want or can't afford their own crew of computer geeks.
What's annoying with this story is that Microsoft has produced the same sort of external-support ecosystem. In this case, MS claims to supply customer support, but it's so crappy that companies will pay other people for the support that MS doesn't actually supply. I have a number of friends who are making a living this way. And note that the support companies generally don't have full access to the source code, which limits what they can do for customers.
Actually, there's a much better auto analogy than what either of us used. Some histories have been written recently about the story of leaded gasoline. Google for "gasoline history tetraethyl lead" for lots of info. It seems that back in the 1920s, the auto industry knew quite well that ethanol did about as good a job as an anti-knock additive as gasoline history tetraethyl lead. But ethanol was cheap and public domain, while tetraethyl lead was patented and thus only available at a monopoly price from the patent owner (Du Pont). Via the well-known technique of interlocking directorates, the auto and petroleum industries decided to ignore cheap things like ethanol, and sell engines that used leaded gasoline. This had a disastrous effect on public health, but it enriched the bank accounts of those industry's leaders. It was completely open and legal in the US and most of the rest of the world.
At least in the current story, Meraki didn't change their product so that it poisoned their customers. Though if they did, and they used a patented poison, history says that US courts would probably support them. (At least we'd expect that people here on