In and of itself, LDAP started off as a partial implementation of the X.500 directory services - partial being the bits that people generally found useful. The LDAP specification has changed over time, reflecting a better understanding of what people actually needed - together with the fact that as systems became more powerful, people generally needed rather more out of services.
The first problem is that Netscape probably didn'tadd much to their Directory Service towards the end, and it is unclear how much Fedora has had to put resources into code cleanups and bug fixes, as opposed to adding the capabilities it is going to need.
The second problem is that there needs to be an Open Source system compatible with (and preferably better than) Microsoft's Active Directory. The LDAP side of that is absolutely critical. For this directory server to be of much interest to network administrators, this package absolutely must support two-way communication with Microsoft Active Directory's LDAP. It can support more - and it would be great if, for once, Open Source "embraced and extended" something from The Other Side...
To be of interest to system admins, it needs to work with PAM and preferably one of the standard "unified" admin interfaces, like Webmin or (yes, it is still used) linuxconf, in addition to specialized tools. It needs both. Specialized but simple command-line tools are great for doing batch tasks or quick tasks, which will be the bulk of routine tasks. More complex tasks, changing configuration files, etc, are often easier in a unified interface. For extremely precise operations, user interfaces hide too much detail, so for those you often do have to use some hefty command-line and probably a text editor for control and config files.
In other words, you've three distinct classes of operation and distinct types of interface for each. The "best" tools are ones which provide all three interface types and make it easy to develop others.
The last problem I'm seeing is that computing has moved on since Netscape ruled the world. Unified Parallel C is beginning to look like a serious rival to classical C, and even classical C compilers are gaining parallel support in the form of OpenMP (now included in a development branch of GCC). Fedora can't even keep their parallel patches in sync with the kernel. For that matter, their development repository is rarely synchronized, even though that's just a dependency chain they can follow from the SRPMs.
(Don't get me wrong - I like Fedora's distro, it is simply that if they are neglectful of something they can do in a script and a makefile, and of mere patches they had already made public, then how confident can I be of their ability to maintain a very complex piece of software?)
It is certainly possible to fix all of the bugs in any piece of software, but NOT by code audits and testing. If you rely on testing then if you have N different modules in the code, you have !N different ways those modules could interact. N doesn't have to be big to make this an impossible task.
Instead, you take the software and reverse-engineer a mathematical description of it. Once you have a mathematical model, you can use theorum provers to determine what parts of the code are mathematically illogical/incorrect/incomplete. Once you know what parts of the code simply don't make sense, you can restrict your debugging solely to those parts of the code. You don't need to investigate the code that works. Assuming there is any.
Of course, for "trivial" classes of bugs (buffer overflows, buffer underruns, null pointer access, etc), there are code validators which will specifically look for those flaws. splint (a lint derivative) is one, the Stanford Code Validator is another. As these form the bulk of easily exploited bugs, it would seem obvious to scan the code with these first. To make certain you've caught everything, there are also validating mallocs, such as Electric Fence, which detect obviously bogus memory accesses.
I don't know how long it would take to do a reasonable scan of the Windows source code, using such tools, but I would not think it likely to take more than a few months to do the most rigorous of these checks (convert to formal notation, then use a maths theorum prover) to locate all suspect areas, and maybe a few more months to actually correct all of these bugs. You'd probably want to use a memory profiller and/or a validating malloc first, though, to cure the really obviously bogus code.
After all that, you would then want to do regression testing to ensure you'd not broken anything in the process (or unbroken something that actually needs to be broken). This would not correct "all" of the bugs in the code, but it would reduce the number by a couple of orders of magnitude and in a timeframe that would be very reasonable.
Yes, it is their responsibility, in the sense that they're selling a product to be used - and you can't use that product if there are no drivers for it. On the other hand, no, unless they specifically advertise the product as being designed for Linux. If they say that, then a lack of drivers would fall under any trades description act, as it cannot then be used in the manner for which it was designed.
In practice, most users with a decent Linux distro should have the majority of drivers (especially printer drivers) they need. The commercial version of CUPS adds a whole bunch more. Hey, "Open Source" doesn't mean you don't have to pay for things. Nobody, after all this time, has any business confusing Open Source with "free as in beer".
If there is a device that you need kernel-level support for, then there's a pretty decent chance the kernel will have support. It just might not be compiled in. Again, "Open Source" doesn't mean "lazy". You may need to put in some work, but it's not going to kill you. There is a big difference between coal mining in China and running a makefile.
Finally, there's this matter of what is trivial. When was the last time you decorated the foundations of your house for Christmas? How many Slashdot readers can say for certain what type of cement and/or rock was used? How many have directly observed the foundations of their house? Never and none? Then surely they must also be trivial. Or maybe - just maybe - there are details which are extremely important, they just don't appear to be to the casual, ill-informed user.
Surface terraforming is unlikely - especially as the dust devils & storms would destroy any large structure. Subsurface teraforming is possible. Given the situation, the most likely solution would be to melt the ice underground, then use the bases normally used for undersea research. No problems with the surface conditions, then, and the water would provide a degree of protection from radiation.
All the probes that went missing... they were all in that region, weren't they? Would the magnetic anomoly in the region be sufficient to have confused them?:)
Politicians who write bills that would actually work would be crucified by the Religious Right. Given the current trend in extremism in the US, possibly literally.
On the other hand, I would certainly regard it as both fair and reasonable for Government to determine if "easter eggs" and other hidden content frequently contain illegal extras. I'm not just counting adult material in a juvenile game - the whole Sony DRM thing was definitely hidden content containing illegal extras.
This does not mean such material should not be circulated, but rather that the Government would seem to be in the ideal position to provide information on what products actually do, as opposed to what they are advertized to do. (As the media and consumer agencies have done bugger all to protect consumers, in recent years, if Senator Clinton is volunteering to do the job, I'd say let her. She can't do worse.)
Let's take it as read that Windows is just not a good platform for an embedded system. But what I want to know is why Diebold think they have to release the Windows source code at all. It's not part of their software, any more than the BIOS chip or any microcode on the CPU.
As far as I can see, this is not about Diebold being (fairly or unfairly) ordered to release a damn thing about Microsoft's software. This is about Diebold not wanting to release Diebold's software, and that is all. (Either that, or Diebold is totally ignorant on computer architecture, in which case I don't want it within a million lightyears of a voting machine.)
If we were to assume that ALL software - every last bit - had to be released under these orders, then the only way to do so would be to build from hardware on OpenCores and to have LinuxBIOS (or something like that for another F/OSS Operating System) as the sum total of all BIOS support on the system. Clearly it is possible, as I've supplied the links necessary to do it. I doubt it would be considered reasonable, from a legal standpoint, though.
Demonstrably, then, a total publication of ALL software and software-related material was not what was intended, which means Diebold's move has nothing to do with inability to follow the directives but rather has more to do with an attempt at blackmailing the State government.
I guess the next step would be for someone to take Diebold to court, for Diebold to make their (provably false) remarks in court and for the plaintiff to rake Diebold over the legal coals for it. Lawyers are smart. If there any lawyers on Slashdot, could there be any way of presenting an argument that deliberate FUD, when under oath, constituted perjury or contempt of court?
For that matter, nobody likes being taken for a ride - or even believing they have. The danger of FUD is that it is two-edged - particularly when the public are daily being fed reports of scandal, bribery and corruption from people in authority. It would be easy enough, if anyone had the desire, to use Diebold's own FUD and the current media epidemic to have Diebold branded so deep the PR scars will never heal. That is the danger of such weapons - they can turn against those who wield them.
Diebold, IMHO, is in an extremely vulnerable and dangerous position - whether there are any security flaws in their code or not (and we're all pretty sure there are). If we want provably honest electronic voting (and there are ways to do that), then now is the time we need to take the battle to them. Not just between geeks, but to those who haven't a clue as to what a BIOS is. If there's a way to force Diebold through the courts to give the REAL reason for the withdrawl, it might shake faith in them. Particularly if that reason includes security flaws.
It can always borrow against the State, then recoup through taxes, so it doesn't need the money in advance. A private hospital can't do that.
A public health system is not an isolated component, but a part of the country as a whole. Thus, people who get sick aren't earning. So, in such a system, hospitals really always cost more (overall) than they earn. The idea is to cost the least, by getting people healthy. The healthier the nation, the more money is earned in total, so the more profitable the healthcare system becomes.
A private healthcare system earns nothing when people are working, but earns everything when people are sick, so has no incentive to either prevent illness, to treat it quickly, or to remedy the fault completely. A hospital maximizes profit only if cures require continued treatment. This is why they opposed, vigorously - almost violently - the discovery that peptic ulcers are caused by bacteria. That was a BIG money-spinner for them.
Binaries are only available for only a very small number of platforms, but I need high-performance BLAS on a much wider range of systems, hence I can't use libgoto. "It might not be optimized for those platforms", you say. Well, having an optimized framework and the ability to add my own code would have solved that one.
High-performance libraries are great, but if they are closed-source can only EVER be great in the most restrictive case possible, which is useless in non-standard or heterogeneous environments.
For this reason, ATLAS is interesting to me. It's not as fast as it could be (by a long way), it doesn't support the full set of BLAS/LAPACK functions (which is crappy), it also doesn't provide optimizations on many chips that Linux will run on (doubly crappy) and it's a one-man project where the one man is massively overworked on the non-existant time available to maintain the project. On the other hand, it's Open Source (so I can add code I consider missing), it's Open Source (so I can compile on any platform I like) and it's Open Source (so I know the code will get some support from someone, for as long as it is in use).
Where I need more speed, and DON'T have the time to make the necessary changes - well, I'm screwed, because there is bugger all in the way of good BLAS/LAPACK libraries for Broadcom's SB1 processor. Not even Broadcom support their own processors. Such is life.
The problem with PCI Express is that it adds about 4 ms latency. Many PCI Express network cards quote latency of about 2.5 ms, but that's component latency, not integrated latency. Integrated, you have to add them together (6.5 ms). But that's still best-case, as it doesn't include any latencies in transferring data off the bus and onto the card, as that is not going to be included in either specification.
Now, onto fat trees. Fat trees are simple enough - any two layers of the network have the same bandwidth, just divided by a different number of nodes. Here we run into our furst saturation problem. If two nodes transmit to one node, at any level in that tree, they will have to do so no faster than at half-speed (on average) because their combined bandwidth is (by definition) twice as much as the bandwidth of the receiving node. This is made worse by the fact that Fat Trees are "non-blocking". If they blocked, the tree itself could schedule packets as capacity became available. By being non-blocking, they are subject to contention and saturation. (Network QoS won't help here, because you'd need to use "dumb" switches for minimum latency, which means the switches can't support QoS to prevent network overload. Besides, nobody writes applications to support ECN signals for turning the noise down.)
When dealing with matrix algebra and systems of linear equations, you will very often have many (or even all) of the leaf nodes sending to a common destination, at the same time. If you've a few hundred - or even a few thousand - nodes, this can be extremely messy. The total upstream bandwidth is going to be, in the case of a thousand node network, 999 times greater than the downstream network. (A node usually doesn't transmit across the network to itself.)
This will kill the leaf node, but it will also kill every switch upstream of the leaf node, because there will be far more traffic than the network can support. Since only 1 in every 999 packets can get through, 998 packets out of every 999 will need to be lost. Assuming a reliable transport mechanism, this means you'll have every one of those packets resent. The congestion will cause havoc, not only for that one moment, but until all packets can get through. The best possible case is that the average latency will be 500 times normal. In practice, it is likely to be far worse.
Now we get to all-to-all calculations. At SC2005, I was told that this amounted to about 80-90% of all HPC work. All-to-all is never kind on a network. In our example of a thousand leaf node cluster, you have all thousand machines doing general broadcasts to all of the others. But broadcasts can't be done efficiently as a reliable protocol. Very likely, you'll use a NAK-based protocol to guarantee everything gets through. Since the order of successful packets is going to be largely random, and as most NIC cards are poor on handling out-of-order delivery, virtually everything will need to be repeated many times over to ensure everything has been received. And even then, you've got to go through a whole bunch of synchonizing messages.
Fat trees are simply not built for this kind of work. They're fine for 1:1 and 1:N transmissions, they are positively crap for N:1 receptions and can barely function for N:M mass transfers of data.
The "correct" network design for N:1 and N:M transfers was proposed by the British mathematician Roger Penrose. In a Penrose network, there is one interconnect between any two nodes. It's that simple. Such a network has no contention, because there is nothing to contend with. It cannot be saturated, because all individual connections are 1:1. Hot-spots can occur at individual leaf nodes, but won't spread. There's no switching layer to spread through.
There are problems with a Penrose network. It is extremely expensive, if built as a wired network, and the need for physical connectors and cables places an upper limit on the number of nodes you can have. After a certain point, you simply won
That is perfectly true. The cost always comes from somewhere. I'm nopt seeing this "choice" thing you speak of, though - most companies offer only one health insurance company and usually only one plan from it. If you go elsewhere (this "choice", I guess), you are still going to be paying 90% of the costs of the plan you didn't select, because that's all done within the company.
In the end, you have no more (or less) choice than you would have in a system where there was national health coverage, PLUS private insurance you could buy on top of that. It works out to about the same, money-wise. The difference is that you lose scale efficiency, as you've a large number of organizations squeezing profits out of the money flow.
Assuming that's not satire, the answer is that you actually pay 100% of the cost - your wages are simply reduced by the amount that the company has to fork over for the remainder. Where else did you think the money came from? Generous shareholders?
But the money still has to be earned, which means you pay for everyone else's health care expenses in higher-priced goods. So, in essence, the US has nationalized health care anyway - you're just being taxed by the corporations and not the Government. Well, perhaps. Tax write-offs also have to be financed by someone, which means some of your income tax is actually going to pay your corporation for their contribution for your benefits.
Inflated prices, inflated taxes and reduced wages - all so that you can claim the company is paying the lion's share of the insurance. Someone's getting ripped off, royally.
Apache 2.x seems to be considered solid but sluggish, compared to the 1.x series, so I suspect there are people who held off the 2.0 series in the hopes that 2.1 will improve performance. And. yes, whilst I fully understand the natural desire to maintain high standards in coding, I do think that the Apache group cold-shouldering SGI's Apache Acceleration Project was probably not the greatest of responses. The fact that these were performance patches, given that 2.x has proved to be slower, has probably soured a few opinions along the way. Diplomacy is not a four-letter word (5 letters to many) and I'm sure that it would have been possible to have done more in a cooperative, rather than competitive, fashion.
On the other projects on the Apache site - Ant seems to be almost universally accepted as a build tool, and Tomcat seems to be one of the more significant servlet engines out there. Struts gets a lot of press, too. Never knew SpamAssassin was part of Apache, but there's no doubt it is also very popular. Beehive - not at this time, at least. The best-known Maven was a videoconferencing tool for the Apple Mac. The other tools listed also don't seem to have much publicity - yet. I'm not sure all of them are that useful, either. Tcl/Tk is used a lot for scripted GUIs, but is not suitable for web work, really. There WAS a Tcl/Tk plugin for Netscape - wonder what happened to that.
Some projects I'm surprised are NOT there:
Pike seems to be interesting for web work and is certainly in (limited) use for that purpose.
If there is any way of using client-side certificates for authentication or access control lists, it's not well documented.
Multiviews for languages is all fine and good, but what about for browser capabilities? I doubt many people set the default language on their browser, anyway, and even fewer seem to configure their web servers to support the feature.
Webcasts are horribly slow and inefficient because they are often accessed by many people at the same time. It would be better if Apache had a mechanism for supporting multicast webcasts.
I would want to inject just one sour note, though. First, way too much clear-cut. It damages the soil and the rivers, reduces the environment for the wildlife, and looks positively horrible from the air.
I'd also caution against pride - Denmark has won the "best place to live" award from the UN for the past five or six years.
It is true that nationalized healthcare systems, such as the NHS of Britain, and the Canadian system, are slow. That could be fixed by adding more doctors. It's a solvable problem. In the US, insurance costs are through the roof (you could probably rival Bill Gates on wealth just by not getting sick), medicare is rife with fraud by hospitals and not all insurance is even accepted at all hospitals, so you can get turfed out even in life-or-death situations.
(Actually, in America, you might get turfed out in critical situations anyway. Many hospitals don't have an emergency room, as they cost more than they make and US hospitals are there for profit not care. Those ER rooms that do exist are hopelessly overcrowded, overworked and are considered by the CDC to be extremely high risk areas in the event of an outbreak of a contageous disease. If bird flu ever goes critical, it will likely do so in a US emergency room.)
The American situation, unlike the British and Canadian counterparts, is not fixable. Because hospitals in the US are profit ventures, not health-care centers, they have no interest in doing anything that will cost more than it will earn. Proper emergency care is expensive and earns little, as most accident and crime victims are uninsured and/or flat broke. They have no interest in lowering prices, because the bulk of "paying" customers have health insurance and so never see the real price tag and therefore have no reason to care what it is.
Insurance companies in the US are also money-grubbers and they know how to rake the money in. By charging the companies a "reduced rate" for bulk purchases, they can absolutely guarantee that customers never see the real cost to their paychecks. The victim - errr, employee - only sees a given deduction for their deduction. What they don't see is what the company is really paying and therefore what the company is really calculating payscales on. In the end, you pay the full cost but you only see a fraction of it on the pay stub.
By these accounting tricks and other fraud, the US employees are bilked billions of dollars and somehow consider themselves better off because they don't have the wait. Trust me, if you threw billions of dollars out the window in England, you'd get prompt healthcare too. Well, just as soon as anyone realized that was real money and not something from a Monopoly game.
(For that matter, there's always BUPA, if you insist on the insurance thing in more civilized lands.)
These days, a "high speed interconnect" means doing Infiniband better. Many of the exhibits at the SC2005 show were using Linux, OpenIB and Inifiniband, which is a good start - but slow, because Infiniband is generally implemented as a pseudo-bus run on top of PCI or PCI Express. The added layering adds a lot of latency, and it is latency that is killing a lot of high-end applications. That, and the fact that fat-trees saturate so easily, killing performance.
Certainly, in the first 500,000 years of Earth's existance as a solid body, there was no free oxygen at all. Once life evolved, oxygen levels rose. Since then, the biosphere (as a whole) has been relatively stable. Which is remarkable, given that most of it is inherently unstable and, without life, would collapse extremely quickly.
The situation is further complicated by the fact that we're coming to the end of an interglacial period - the last Ice Age technically didn't finish, and will be back for more. Such periods are unstable, in and of themselves, as they change very rapidly on a geological timescale.
There is also the fact that we've got masses of sunspots over a prolonged period, unusual geological activity, etc. All of these will complicate any attempt to model the environment and will muddle which variables humans are responsible for and by how much.
HOWEVER, we must also look at the nature of natural events. Volcanos are very short-term things and they pump the gasses into a much higher part of the atmosphere than do humans. We can therefore filter out natural contributions to the greenhouse effect, because those will go into an entirely different cycle. Human activity is prolonged (and, these days, often 24 hours a day, all year round), is highly regionalized and is often in areas that have a reduced ability to act as sinks. Water near industrialized ports is likely going to have a thin film of oil, making it harder to absorb gasses. Land near industrialized cities is often badly deforrested, with the same results. Farmland is no better, as farmers don't do crop rotation and use chemicals to add nitrates, etc.
Whether you can deduce from all of this that humans are responsible for all damage is tough. I believe so, but I wouldn't be able to produce a convincing argument for it. What CAN be deduced is that the climate has become unstable and may not be survivable if nothing is done. I believe the focus of the debate should be less on who did what (because nobody is taking responsibility, regardless) and should be much more firmly focussed on preserving as much of the biosphere as possible.
Damage to the Amazon jungle is something like 60% worse than previously believed, because loggers have been using thinning techniques to hide evidence of illegal logging. I believe that is a problem. Fish stocks are 10% of where they were at the turn of the 20th century. I believe that is also a problem. Species are becoming extinct at an accerating rate, which I definitely think is a problem. I believe that if we do something to correct these problems, then a lot of other problems will take care of themselves. We then only have to deal with whatever is left over.
People are generally lazy, politicians doubly so, so any plan that involves relatively little work (and less pain) now would surely be a better bet no matter who is right on the global warming front.
Does that mean your post was on a tangent? And are the claims of environmental scientists merely hyperbole, or should we consider that they may in fact be parabolic?
Have had their own pet scenarios that they repeatedly use in their stories. With Asimov, it was linked minds and robotics. For Arthur C Clarke, it has generally been a mix of Earth blowing up and the consequences of humans mixing with other civilizations.
Actually, this last one is significant even if there are no aliens within contactable distance of Earth. There are extremely few positive cases of advanced human societies mixing with less advanced societies. The response has ranged from "cargo cults" to extermination campaigns to the utter collapse of native culture, followed by extreme chemical dependencies and other addictions. More than a few of the troubles in the Middle East, for example, have been due to extreme, prolonged culture shock. Many of the islands visited by Captain Cook, described as paradise at the time, are now little more than brothels with an ocean-front view for the rich.
So, whilst I don't regard the call for an Interstellar protocol to be particularly useful in and of itself, IF we take this opportunity to look at how to communicate with others without causing damage, I would consider it a worthy investment of time and effort. If it leads to the undoing of the mindless destruction inflicted in the past, so this world can be the richer for the cultures that still exist, then it will have paid for itself many times over.
If all it does is deter people from questioning how they treat others, then we'll keep paying an absurdly high price from something only a tiny handful will ever get anything from.
...is that you're right. I like PHP as a scripting language - it is powerful, flexible and as an alternative to CGI scripting, is truly amazing. However, the lack of namespaces is a big problem, which they MIGHT address in version 6, but that's still only under discussion.
Java used to be regarded as a horrible language for the web, but ever since GCC included a Java compiler, it's actually beginning to be fast enough to be worth the hastle.
Now, a PHP front-end for GCC would be an interesting project, and could offer some serious competition to Zend. Which means it is likely to last all of three seconds before being found dead in an electronic alleyway. However, as it stands, the syntax is horribly inconsistent and not particularly generic. For example, I like the fact that PHP lets me use a crypto library, but why should I have to care if it is mcrypt, gcrypt or some other package out there?
In the same way that a database-neutral API now exists for SQL functions, there should be other implementation-neutral APIs for all of the other libraries. Forcing people to hard-code is a mortal sin and verily should thine hard-code-forcing-coders be delivered unto the rabbit at Aaaargh.
Slashdot Mirror
I'm impressed. Most troll postings have no information content. This is the first time I think I've seen a posting with less than that.
That was exactly my point, although you did a much better job of expressing it.
The first problem is that Netscape probably didn'tadd much to their Directory Service towards the end, and it is unclear how much Fedora has had to put resources into code cleanups and bug fixes, as opposed to adding the capabilities it is going to need.
The second problem is that there needs to be an Open Source system compatible with (and preferably better than) Microsoft's Active Directory. The LDAP side of that is absolutely critical. For this directory server to be of much interest to network administrators, this package absolutely must support two-way communication with Microsoft Active Directory's LDAP. It can support more - and it would be great if, for once, Open Source "embraced and extended" something from The Other Side...
To be of interest to system admins, it needs to work with PAM and preferably one of the standard "unified" admin interfaces, like Webmin or (yes, it is still used) linuxconf, in addition to specialized tools. It needs both. Specialized but simple command-line tools are great for doing batch tasks or quick tasks, which will be the bulk of routine tasks. More complex tasks, changing configuration files, etc, are often easier in a unified interface. For extremely precise operations, user interfaces hide too much detail, so for those you often do have to use some hefty command-line and probably a text editor for control and config files.
In other words, you've three distinct classes of operation and distinct types of interface for each. The "best" tools are ones which provide all three interface types and make it easy to develop others.
The last problem I'm seeing is that computing has moved on since Netscape ruled the world. Unified Parallel C is beginning to look like a serious rival to classical C, and even classical C compilers are gaining parallel support in the form of OpenMP (now included in a development branch of GCC). Fedora can't even keep their parallel patches in sync with the kernel. For that matter, their development repository is rarely synchronized, even though that's just a dependency chain they can follow from the SRPMs.
(Don't get me wrong - I like Fedora's distro, it is simply that if they are neglectful of something they can do in a script and a makefile, and of mere patches they had already made public, then how confident can I be of their ability to maintain a very complex piece of software?)
Instead, you take the software and reverse-engineer a mathematical description of it. Once you have a mathematical model, you can use theorum provers to determine what parts of the code are mathematically illogical/incorrect/incomplete. Once you know what parts of the code simply don't make sense, you can restrict your debugging solely to those parts of the code. You don't need to investigate the code that works. Assuming there is any.
Of course, for "trivial" classes of bugs (buffer overflows, buffer underruns, null pointer access, etc), there are code validators which will specifically look for those flaws. splint (a lint derivative) is one, the Stanford Code Validator is another. As these form the bulk of easily exploited bugs, it would seem obvious to scan the code with these first. To make certain you've caught everything, there are also validating mallocs, such as Electric Fence, which detect obviously bogus memory accesses.
I don't know how long it would take to do a reasonable scan of the Windows source code, using such tools, but I would not think it likely to take more than a few months to do the most rigorous of these checks (convert to formal notation, then use a maths theorum prover) to locate all suspect areas, and maybe a few more months to actually correct all of these bugs. You'd probably want to use a memory profiller and/or a validating malloc first, though, to cure the really obviously bogus code.
After all that, you would then want to do regression testing to ensure you'd not broken anything in the process (or unbroken something that actually needs to be broken). This would not correct "all" of the bugs in the code, but it would reduce the number by a couple of orders of magnitude and in a timeframe that would be very reasonable.
In practice, most users with a decent Linux distro should have the majority of drivers (especially printer drivers) they need. The commercial version of CUPS adds a whole bunch more. Hey, "Open Source" doesn't mean you don't have to pay for things. Nobody, after all this time, has any business confusing Open Source with "free as in beer".
If there is a device that you need kernel-level support for, then there's a pretty decent chance the kernel will have support. It just might not be compiled in. Again, "Open Source" doesn't mean "lazy". You may need to put in some work, but it's not going to kill you. There is a big difference between coal mining in China and running a makefile.
Finally, there's this matter of what is trivial. When was the last time you decorated the foundations of your house for Christmas? How many Slashdot readers can say for certain what type of cement and/or rock was used? How many have directly observed the foundations of their house? Never and none? Then surely they must also be trivial. Or maybe - just maybe - there are details which are extremely important, they just don't appear to be to the casual, ill-informed user.
Yonah was the one that didn't follow the programmed instructions and was eventually consumed by Wales.
Surface terraforming is unlikely - especially as the dust devils & storms would destroy any large structure. Subsurface teraforming is possible. Given the situation, the most likely solution would be to melt the ice underground, then use the bases normally used for undersea research. No problems with the surface conditions, then, and the water would provide a degree of protection from radiation.
All the probes that went missing... they were all in that region, weren't they? Would the magnetic anomoly in the region be sufficient to have confused them? :)
On the other hand, I would certainly regard it as both fair and reasonable for Government to determine if "easter eggs" and other hidden content frequently contain illegal extras. I'm not just counting adult material in a juvenile game - the whole Sony DRM thing was definitely hidden content containing illegal extras.
This does not mean such material should not be circulated, but rather that the Government would seem to be in the ideal position to provide information on what products actually do, as opposed to what they are advertized to do. (As the media and consumer agencies have done bugger all to protect consumers, in recent years, if Senator Clinton is volunteering to do the job, I'd say let her. She can't do worse.)
As far as I can see, this is not about Diebold being (fairly or unfairly) ordered to release a damn thing about Microsoft's software. This is about Diebold not wanting to release Diebold's software, and that is all. (Either that, or Diebold is totally ignorant on computer architecture, in which case I don't want it within a million lightyears of a voting machine.)
If we were to assume that ALL software - every last bit - had to be released under these orders, then the only way to do so would be to build from hardware on OpenCores and to have LinuxBIOS (or something like that for another F/OSS Operating System) as the sum total of all BIOS support on the system. Clearly it is possible, as I've supplied the links necessary to do it. I doubt it would be considered reasonable, from a legal standpoint, though.
Demonstrably, then, a total publication of ALL software and software-related material was not what was intended, which means Diebold's move has nothing to do with inability to follow the directives but rather has more to do with an attempt at blackmailing the State government.
I guess the next step would be for someone to take Diebold to court, for Diebold to make their (provably false) remarks in court and for the plaintiff to rake Diebold over the legal coals for it. Lawyers are smart. If there any lawyers on Slashdot, could there be any way of presenting an argument that deliberate FUD, when under oath, constituted perjury or contempt of court?
For that matter, nobody likes being taken for a ride - or even believing they have. The danger of FUD is that it is two-edged - particularly when the public are daily being fed reports of scandal, bribery and corruption from people in authority. It would be easy enough, if anyone had the desire, to use Diebold's own FUD and the current media epidemic to have Diebold branded so deep the PR scars will never heal. That is the danger of such weapons - they can turn against those who wield them.
Diebold, IMHO, is in an extremely vulnerable and dangerous position - whether there are any security flaws in their code or not (and we're all pretty sure there are). If we want provably honest electronic voting (and there are ways to do that), then now is the time we need to take the battle to them. Not just between geeks, but to those who haven't a clue as to what a BIOS is. If there's a way to force Diebold through the courts to give the REAL reason for the withdrawl, it might shake faith in them. Particularly if that reason includes security flaws.
High-performance libraries are great, but if they are closed-source can only EVER be great in the most restrictive case possible, which is useless in non-standard or heterogeneous environments.
For this reason, ATLAS is interesting to me. It's not as fast as it could be (by a long way), it doesn't support the full set of BLAS/LAPACK functions (which is crappy), it also doesn't provide optimizations on many chips that Linux will run on (doubly crappy) and it's a one-man project where the one man is massively overworked on the non-existant time available to maintain the project. On the other hand, it's Open Source (so I can add code I consider missing), it's Open Source (so I can compile on any platform I like) and it's Open Source (so I know the code will get some support from someone, for as long as it is in use).
Where I need more speed, and DON'T have the time to make the necessary changes - well, I'm screwed, because there is bugger all in the way of good BLAS/LAPACK libraries for Broadcom's SB1 processor. Not even Broadcom support their own processors. Such is life.
Now, onto fat trees. Fat trees are simple enough - any two layers of the network have the same bandwidth, just divided by a different number of nodes. Here we run into our furst saturation problem. If two nodes transmit to one node, at any level in that tree, they will have to do so no faster than at half-speed (on average) because their combined bandwidth is (by definition) twice as much as the bandwidth of the receiving node. This is made worse by the fact that Fat Trees are "non-blocking". If they blocked, the tree itself could schedule packets as capacity became available. By being non-blocking, they are subject to contention and saturation. (Network QoS won't help here, because you'd need to use "dumb" switches for minimum latency, which means the switches can't support QoS to prevent network overload. Besides, nobody writes applications to support ECN signals for turning the noise down.)
When dealing with matrix algebra and systems of linear equations, you will very often have many (or even all) of the leaf nodes sending to a common destination, at the same time. If you've a few hundred - or even a few thousand - nodes, this can be extremely messy. The total upstream bandwidth is going to be, in the case of a thousand node network, 999 times greater than the downstream network. (A node usually doesn't transmit across the network to itself.)
This will kill the leaf node, but it will also kill every switch upstream of the leaf node, because there will be far more traffic than the network can support. Since only 1 in every 999 packets can get through, 998 packets out of every 999 will need to be lost. Assuming a reliable transport mechanism, this means you'll have every one of those packets resent. The congestion will cause havoc, not only for that one moment, but until all packets can get through. The best possible case is that the average latency will be 500 times normal. In practice, it is likely to be far worse.
Now we get to all-to-all calculations. At SC2005, I was told that this amounted to about 80-90% of all HPC work. All-to-all is never kind on a network. In our example of a thousand leaf node cluster, you have all thousand machines doing general broadcasts to all of the others. But broadcasts can't be done efficiently as a reliable protocol. Very likely, you'll use a NAK-based protocol to guarantee everything gets through. Since the order of successful packets is going to be largely random, and as most NIC cards are poor on handling out-of-order delivery, virtually everything will need to be repeated many times over to ensure everything has been received. And even then, you've got to go through a whole bunch of synchonizing messages.
Fat trees are simply not built for this kind of work. They're fine for 1:1 and 1:N transmissions, they are positively crap for N:1 receptions and can barely function for N:M mass transfers of data.
The "correct" network design for N:1 and N:M transfers was proposed by the British mathematician Roger Penrose. In a Penrose network, there is one interconnect between any two nodes. It's that simple. Such a network has no contention, because there is nothing to contend with. It cannot be saturated, because all individual connections are 1:1. Hot-spots can occur at individual leaf nodes, but won't spread. There's no switching layer to spread through.
There are problems with a Penrose network. It is extremely expensive, if built as a wired network, and the need for physical connectors and cables places an upper limit on the number of nodes you can have. After a certain point, you simply won
In the end, you have no more (or less) choice than you would have in a system where there was national health coverage, PLUS private insurance you could buy on top of that. It works out to about the same, money-wise. The difference is that you lose scale efficiency, as you've a large number of organizations squeezing profits out of the money flow.
But the money still has to be earned, which means you pay for everyone else's health care expenses in higher-priced goods. So, in essence, the US has nationalized health care anyway - you're just being taxed by the corporations and not the Government. Well, perhaps. Tax write-offs also have to be financed by someone, which means some of your income tax is actually going to pay your corporation for their contribution for your benefits.
Inflated prices, inflated taxes and reduced wages - all so that you can claim the company is paying the lion's share of the insurance. Someone's getting ripped off, royally.
On the other projects on the Apache site - Ant seems to be almost universally accepted as a build tool, and Tomcat seems to be one of the more significant servlet engines out there. Struts gets a lot of press, too. Never knew SpamAssassin was part of Apache, but there's no doubt it is also very popular. Beehive - not at this time, at least. The best-known Maven was a videoconferencing tool for the Apple Mac. The other tools listed also don't seem to have much publicity - yet. I'm not sure all of them are that useful, either. Tcl/Tk is used a lot for scripted GUIs, but is not suitable for web work, really. There WAS a Tcl/Tk plugin for Netscape - wonder what happened to that.
Some projects I'm surprised are NOT there:
I'd also caution against pride - Denmark has won the "best place to live" award from the UN for the past five or six years.
(Actually, in America, you might get turfed out in critical situations anyway. Many hospitals don't have an emergency room, as they cost more than they make and US hospitals are there for profit not care. Those ER rooms that do exist are hopelessly overcrowded, overworked and are considered by the CDC to be extremely high risk areas in the event of an outbreak of a contageous disease. If bird flu ever goes critical, it will likely do so in a US emergency room.)
The American situation, unlike the British and Canadian counterparts, is not fixable. Because hospitals in the US are profit ventures, not health-care centers, they have no interest in doing anything that will cost more than it will earn. Proper emergency care is expensive and earns little, as most accident and crime victims are uninsured and/or flat broke. They have no interest in lowering prices, because the bulk of "paying" customers have health insurance and so never see the real price tag and therefore have no reason to care what it is.
Insurance companies in the US are also money-grubbers and they know how to rake the money in. By charging the companies a "reduced rate" for bulk purchases, they can absolutely guarantee that customers never see the real cost to their paychecks. The victim - errr, employee - only sees a given deduction for their deduction. What they don't see is what the company is really paying and therefore what the company is really calculating payscales on. In the end, you pay the full cost but you only see a fraction of it on the pay stub.
By these accounting tricks and other fraud, the US employees are bilked billions of dollars and somehow consider themselves better off because they don't have the wait. Trust me, if you threw billions of dollars out the window in England, you'd get prompt healthcare too. Well, just as soon as anyone realized that was real money and not something from a Monopoly game.
(For that matter, there's always BUPA, if you insist on the insurance thing in more civilized lands.)
These days, a "high speed interconnect" means doing Infiniband better. Many of the exhibits at the SC2005 show were using Linux, OpenIB and Inifiniband, which is a good start - but slow, because Infiniband is generally implemented as a pseudo-bus run on top of PCI or PCI Express. The added layering adds a lot of latency, and it is latency that is killing a lot of high-end applications. That, and the fact that fat-trees saturate so easily, killing performance.
There was a scinet at the SC2005 show - all it needs now is a few typos.
Cos()es! I gauss you've beat me on the puns, this time. Drat. I exp()ect you've a whole bunch more, too.
The situation is further complicated by the fact that we're coming to the end of an interglacial period - the last Ice Age technically didn't finish, and will be back for more. Such periods are unstable, in and of themselves, as they change very rapidly on a geological timescale.
There is also the fact that we've got masses of sunspots over a prolonged period, unusual geological activity, etc. All of these will complicate any attempt to model the environment and will muddle which variables humans are responsible for and by how much.
HOWEVER, we must also look at the nature of natural events. Volcanos are very short-term things and they pump the gasses into a much higher part of the atmosphere than do humans. We can therefore filter out natural contributions to the greenhouse effect, because those will go into an entirely different cycle. Human activity is prolonged (and, these days, often 24 hours a day, all year round), is highly regionalized and is often in areas that have a reduced ability to act as sinks. Water near industrialized ports is likely going to have a thin film of oil, making it harder to absorb gasses. Land near industrialized cities is often badly deforrested, with the same results. Farmland is no better, as farmers don't do crop rotation and use chemicals to add nitrates, etc.
Whether you can deduce from all of this that humans are responsible for all damage is tough. I believe so, but I wouldn't be able to produce a convincing argument for it. What CAN be deduced is that the climate has become unstable and may not be survivable if nothing is done. I believe the focus of the debate should be less on who did what (because nobody is taking responsibility, regardless) and should be much more firmly focussed on preserving as much of the biosphere as possible.
Damage to the Amazon jungle is something like 60% worse than previously believed, because loggers have been using thinning techniques to hide evidence of illegal logging. I believe that is a problem. Fish stocks are 10% of where they were at the turn of the 20th century. I believe that is also a problem. Species are becoming extinct at an accerating rate, which I definitely think is a problem. I believe that if we do something to correct these problems, then a lot of other problems will take care of themselves. We then only have to deal with whatever is left over.
People are generally lazy, politicians doubly so, so any plan that involves relatively little work (and less pain) now would surely be a better bet no matter who is right on the global warming front.
Does that mean your post was on a tangent? And are the claims of environmental scientists merely hyperbole, or should we consider that they may in fact be parabolic?
Actually, this last one is significant even if there are no aliens within contactable distance of Earth. There are extremely few positive cases of advanced human societies mixing with less advanced societies. The response has ranged from "cargo cults" to extermination campaigns to the utter collapse of native culture, followed by extreme chemical dependencies and other addictions. More than a few of the troubles in the Middle East, for example, have been due to extreme, prolonged culture shock. Many of the islands visited by Captain Cook, described as paradise at the time, are now little more than brothels with an ocean-front view for the rich.
So, whilst I don't regard the call for an Interstellar protocol to be particularly useful in and of itself, IF we take this opportunity to look at how to communicate with others without causing damage, I would consider it a worthy investment of time and effort. If it leads to the undoing of the mindless destruction inflicted in the past, so this world can be the richer for the cultures that still exist, then it will have paid for itself many times over.
If all it does is deter people from questioning how they treat others, then we'll keep paying an absurdly high price from something only a tiny handful will ever get anything from.
Java used to be regarded as a horrible language for the web, but ever since GCC included a Java compiler, it's actually beginning to be fast enough to be worth the hastle.
Now, a PHP front-end for GCC would be an interesting project, and could offer some serious competition to Zend. Which means it is likely to last all of three seconds before being found dead in an electronic alleyway. However, as it stands, the syntax is horribly inconsistent and not particularly generic. For example, I like the fact that PHP lets me use a crypto library, but why should I have to care if it is mcrypt, gcrypt or some other package out there?
In the same way that a database-neutral API now exists for SQL functions, there should be other implementation-neutral APIs for all of the other libraries. Forcing people to hard-code is a mortal sin and verily should thine hard-code-forcing-coders be delivered unto the rabbit at Aaaargh.