But once you taste the water, you realize the potential
This could mean any of the following:
Their process uses electrical currents, so what you get when in contact with the water really IS the potential
They've discovered a way to turn the pollutants into hallucinogenic substances, allowing them to earn a fortune
Same as the above, only they can pipe it into their opponent's water supply
Same as the above, only the troops are now berserkers and think they're indestructible
They've discovered a way to turn the fumes into something that will make photographs invisible to journalists
The water is, in fact, the elixier of life, so forever guaranteeing no US casualties
They have discovered a way to fractionally condense diesel fumes which they will patent and use to collect the revenue gained by suing every school in the western hemisphere for having physics or chemistry textbooks
The TRIPS homepage has nine published papers on how this design will work and a schematic diagram of what they're expecting the design to end up looking like. They are also promising simulators and compilers later this year.
I'd agree that the ethics of a person should be examined, prior to them being ANY kind of judge. Those from England will remember a substantial number of miscarriages of justice where the innocent have been convicted - or even executed - on superficial or non-existant evidence.
We're never going to get straight answers from nominees in the US judicial system, but it would be interesting to know how nominees would have handled the cases of Derek Bentley, Carol Hanson or other such cases of political convictions or other malpractices. Why these cases? They were in the UK, after all. That is precisely why. The cases are from a country similar enough that knowing the answers would tell us a lot, but different enough that the nominee is less likely to feel pressure by one American lobby group or another. No candidate sane enough to qualify is likely to be insane enough to comment on an issue likely to cause a pressure group to block the nomination, which means questions about issues hot within the US are a non-starter when it comes to finding anything out.
So ask questions that'll get you the information you want, but in a way that is unlikely to trigger a political third-world war against the nominee.
Microsoft should be liable for defects, as it is the defects that they cause. They don't cause the damage, that is done by the consumer using that feature. This is the same method used when other products are withdrawn or banned from sale - a recall applies to ALL products that are deemed unsafe. The bridgestone fiasco, for example, applied to the range of tires - those that had already failed were beyond recall.
In practice, Microsoft isn't liable at all for anything, as they don't sell anything other than a permission slip and the permission was working just fine.
Having said that, I do agree that "experience" means very little. What matters is the ability to apply the facts of the case to the laws governing the case. That is not a matter of experience. Indeed, it couldn't be, as there are way too many statutary laws and way too much case law for an individual to actually remember it all. All you NEED to remember is procedure because that it all that can reasonably be expected of a person to remember. The rest is necessarily something the judge (or lawyer or whoever) will need to research on their own, in their own time.
My biggest concern is the same I would have about any judge - will they be able to impartially apply those procedures, or will they attempt to play favourites or "repay" sponsors who helped them get to their position? Honestly, I'm not sure judges should be appointed by political entities - especially as those entities are also involved in writing the laws AND in enforcing them (by controlling who is in charge of the Department of Justice). There's a high risk of a conflict of interest, regardless of whether any specific individual actually has such a conflict or whether they resolve it or not.
...software isn't sold. It remains the posession of the company that wrote it. All you buy is a license to be granted the permission to attempt to run the program. You're not even licensed to ACTUALLY run the program, as the license usually states that there is no guarantee the program will be free of defects. Since a defect can include not doing anything useful, or even running at all, ALL that you have is the right to make the attempt to run the program.
If Microsoft put completely blank CDs or DVDs in the boxed edition of Windows Vista, you would have no right of reply. You aren't buying the program, ALL you buy is the license. If the company provides the program, it is strictly a bonus and is not a part of the sale.
Do I agree with this stance? Do I hell! I believe that software should be bought and sold, and that although "totally free of defects" is unrealistic, there are probably realistic variants of "fit for the purpose for which it was sold" that software could be placed under. Either that, or software should be required to carry indicators of risk. That last one might be better, as it would work even for Open Source and research software, where "purpose" is often ill-defined as it is infinitely variable.
For ASCII text, the easiest way to maintain a log system is to use a revision control system such as RCS, CVS, Subversion, etc. Essentially, that's all these systems are - except they usually support forks in the log, they're not strictly linear collections of diffs.
For binary document formats (eg: MS Office's.doc format), things get tougher. There are versions of diff that'll work on binary files (which is why you can get binary patches), but it's more common to see logging done as a series of macros where the instruction sequence is replayed to get the same result, as opposed to recording actual changes. (Most so-called program "flight recorders" operate by this method.)
A better approach might be a hybrid of these - have a method of extracting/inserting the text as ASCII (which you can then log using a conventional source-control system) and have control sequences recorded as a macro on top of that. You then have to be absolutely certain that the correct two are applied together and in the right order, which may get complicated if there are branches, but the increase in complexity should be more than matched by a reduction in the amount you need to actually store.
As mentioned on the LFS website, there were a number of attempts to implement a log-based filesystem for Linux. Some did work for the kernels they were written for, others do not appear to have worked at all. Virtually all were abandoned - and, to judge from my own research and that of the people who wrote the LFS website, many were abandoned around the Linux 2.2 era.
I guess you can argue that if a project is actively maintained, any problems are potentially fixable. Even with Open Source, an abandoned project is going to be a lot tougher to work on - especially if it was broken at the time it was abandoned, as then you've got to spend time figuring out what was intended, not just what was coded.
Personally, I'd be more in favour of improving the file system layering - eg: having a layer that supports different forms of journalling and logging. Then you could remove explicit logging from the filesystems themselves, you'd only need to provide hooks to the journal/log layer. This would surely reduce bloat, allow people to experiment with different combinations of journal/log and filesystem, etc. If you add a metadata layer, you could even resolve many of the politics of Reiser4 by moving the directories-as-files and other metadata code into such a layer, making it universally available to all filesystems.
It is certainly true that abstracting out and encapsulating in this way usually produces slower code, as you can't have the calls as tightly written or the layer as specialized. On the other hand, I'm going to argue that loose bindings make for easier maintenance and will also increase the number of people who would have an interest in maintaining the code, which will eventually lead to better code and therefore faster code. Only it won't just be faster for one filesystem, it'll be faster for ALL filesystems the user has linked that log/journal component to.
The equipment used by the Department of Homeland Paranoia is great... for detecting cheese* and kitty litter**. It seems to have a very poor track record of detecting explosives, guns or other nasties. I would be more impressed with the article (which I read, even though this is Slashdot) if it showed if the researchers had tested against substances that are chemically deceptively similar but which are definitely quite different.
*Cheese releases fumes that many chemical sniffers will register as those of an explosive. **Kitty litter is often slightly radioactive. It's probably a beta emitter - alpha gets absorbed too easily - but I can't find a definitive source of information.
If these new detectors can detect a nanogram of stilton, but still miss people with semi-automatics, then I don't see we've gained much. Unless there's a plan to use the next NASA mission to the moon to verify its composition is not, as Google claim, swiss cheese.
Of course, we could run into other problems. Will there be false alarms from residue? A lot of Americans do own guns, which means residue on the sorts of scale we're talking about is certainly possible. The security guards are also armed, which means there will be a background reading from those weapons. If cheese is still detected, then not only will we have to deal with actual pieces of cheese, but also any person who has eaten cheese in the past month.
There is no doubt we need a good, functioning weapons detector. I am rather hoping these guys have figured out how to build one. If I am skeptical, it is because I want to see better evidence that they really HAVE figured out how to build one.
The problem is, it's a Dromedary. (Only has one hump.) For development cycles, you really need a Bactrian camel. The prehistoric Camel of North America was about the size of a rabbit, which would make it perfect for embedded systems.
A LISP machine is very similar to a modern-day Java Virtual Machine - it's a device for running LISP - usually in bytecode form, but sometimes as an interpreted language. Depends on the implementation.
LISP, itself, is a language developed for parsing describable information - usually text. It was developed by an AI professor at MIT, IIRC, in one of the early attempts to develop a machine capable of learning.
Because LISP was run in a virtual machine, it was 100% portable. Any machine that had a LISP machine could run a LISP program. It was the real start of "run-anywhere" programming. Although LISP is not the most popular of languages, it has always been a surprise that it has never taken off amongst web developers for purely text-based processing. Java is way too heavy for that and Javascript is very cumbersome for text operations, yet LISP would be ideal for such work.
I'm not 100% sure of this, but I believe Tcl/Tk is derived from LISP, and the syntax used by the LambdaMOO virtual world is very similar and was probably influenced by it.
If they WEREN'T forced to replace all the servers we'd just melted, can you imagine what would have happened when they put the live streaming video feed from the NASA control center during the next moon landing? Dunno about you, but I'd rather they get themselves equipt to handle that kind of mass onslaught now.
On the other hand, studios have invested an enormous amount in advertising (according to most of the reports - I didn't know cheap plastic from sweat-shops in third-world countries cost that much, myself) and are largely complaining that they've seen next to zero return on investment. But, since studios ALWAYS say that (so as to avoid paying taxes, employees on profit-sharing scams, etc) it is often hard to tell fact (or what passes for it) from fiction.
Part of the reason they're 'fessing up is because movies like March of the Penguins were actually doing better than "blockbuster" titles like Fantastic Four. (Per screen, on release, March of the Penguins actually did make more money than Fantastic Four. It has now made more money than Fifth Element, in total, according to some articles.) It is hard to keep claiming that it's someone else's fault when even a French wildlife documentary can outsell multi-million dollar projects from Hollywood.
I think the other part of the reason is that the RIAA is starting to take a turn for the worse in the courts, and the MPAA wants a backup plan in case this spreads to their own lawsuits. In other words, if a movie does crap and fileswappers cases get kicked out, then they can now say "well, we TOLD you the script for that specific movie was no good!" It also didn't help the MPAA when eDonkey started talking about quitting. If there are no fileswapper companies to blame, it's going to get harder for them to push responsibility onto others.
(After all, they've known for HOW LONG that other people's movies were selling just fine? They were having a downturn for how many YEARS before fuel costs shot up? But it was only very recently that fileswapper cases stopped doing well, and only in the last week that eDonkey talked out quitting.)
Will this get Hollywood to make something worth watching? Uh, no. What it'll mean is that they'll spend even MORE on public relations to persuade people that the next movie is worth seeing. That's the usual corporate reaction - why change things, when you only have to convince people they're changed?
If the box says 'opening this implies agreement with the license' and you don't actually get to see the license until you open the box, then the license means nothing. It's not even technically legal. If the license itself is illegal (which is increasingly the case), then by what license do you actually use the software?
The second problem is when the license (and/or other published material) is vague, contains serious omissions or is flat-out wrong. If I were to buy a wordprocessor but be given a blank CD, then I would want my money back. I've not been sold a damn thing. Legally, though, I'd be entitled to nothing since there's no guarantee there's even a product.
The third problem is with the assumption that a case has to involve lawyers AND that it has to be the fault of the consumer. In the case of a blank CD being sold as a wordprocessing package, how hard would it really be for a software company to say "oops!" and replace the CD with one that works? Wouldn't that be easier all round? And if there is no product, but they're really just out to rob people blind, is it reasonable for the consumers to say "oh, forgive us oh master! Please, take more of our money and give us nothing in return!"?
Responsibility is a shared thing, always. So share it!
If I buy a car (under warranty) and it doesn't work, then I can reasonably expect the place I bought it from to either repair or replace it. If I buy a lightbulb, I don't have an absolute guarantee it'll be fault-free, but I do have a guarantee it isn't actually napalm in a lightbulb-shaped container.
What's wrong with a "lemon law" which says that if you say a computer program does X, Y and Z, on such-and-such a platform, then you are entitled to expect it to do X, Y an Z on that platform? And an expectation for businesses, retailers, etc, to honor that?
America is lawsuit-happy, because that's often the only way to get things done. NOBODY takes responsibility for their share of the problem, preferring to push everything onto somebody else. Honesty is optional, integrity is available for a price and selling to ignorance has become the norm. (It wasn't too long ago that American software giants tried to push a bill through where it would be illegal to review software without their permission. I'm not 100% it actually failed.)
If I install a Linux package under Windows, I have no business expecting it to work and should have no right of complaint. Unless it was sold as a Windows package. If I install a Windows package under Windows - correct version, correct platform, everything to specs - and I discover that it has errors even the most superficial QA should have spotted (such as not working at all), then I should also have a right - at the very least - to my money back. This isn't about fixing every bug (or shouldn't be), but about providing what has been sold.
And that's the crux. If Microsoft had (as has been claimed) 65,535 known bugs in the Windows 2000 database at the time of release, then it should have come with a warning that serious defects were known to exist and that not everything would behave as expected. The documentation should also have been modified to note anything that seriously deviated from the behaviour as published. That would have been honest. Sure, fewer people would have bought the program. If Microsoft had needed to do this, they might even have held off on the release until the more user-visible bugs have been cleared up. But would that have been so terrible?
I've no problem with buggy software being released, but software companies should be honest about when there ARE bugs and how serious those bugs are likely to impact typical users.
We need IPv6 and IPSec to be mandatory. By yesterday, preferably. (IPv6 isn't just about namespace - it provides mobility, smart MTUs, automatic configuration, mandatory security, superior routing and reduced latency.) DNS is so political, everyone registers the same name on every TLD, making the entire concept of TLDs utterly futile. DNS servers need to be using DNSSEC. If people used routing protocols that supported multipath, you wouldn't get router loops. Multicast should be supplied to the home, not just the corporate giants.
I'd call what we have not just broken but shot to shit. To quote Twisted Sister, "If that's your best, your best won't do!"
You managed to look through a whole reply without reading it. A distributed kernel cannot be one of OpenBSD's goals, because Theo didn't know what a distributed kernel was. You cannot seek to do something you don't know about.
And THAT, my dear, has been my point all along. You CANNOT seek to do something you know nothing about. THAT is why generalists are essential, because only a generalist knows enough subjects to be able to expand the horizons of a project to the logical conclusion. It is ALSO why specialists are essential, because only a specialist knows enough about a given element to see it to completion and to do it right.
"But what if a project doesn't want to expand?"
If that is the correct approach, then the new variant will die off. "Survival of the fittest" applies to computer programs, just as much as it does to biological entities. If it is the wrong approach, the more restrictive original branch will die off. You will also get situations where BOTH variants can survive, and often this is the preferred result, particularly if the variants coexist peaceably. Actually, this is how you tell if something IS feature-complete - if a variant dies, then it is either too restrictive OR too extensive. Feature-complete variants will always be preferred by natural selection. When two variants have different domains, provided BOTH are feature-complete within their domains, they will both survive. If one is feature-complete and the other not, then the one that is not will be selected against.
(There is one, and only one, exception to this. Arrogantly assuming you are the be-all and end-all. There will ALWAYS be someone that little bit smarter, that little bit quicker and/or that little bit more flexible in their thinking. If they are welcomed as a friend - however alien their thoughts - then your pool of talent will always grow and you will never stagnate and rot in thought. If they are cast aside as though they were inferior, then at best you WILL stagnate. At worst, they'll take the best of what you have, build something so far beyond anything you've ever imagined that you will never seriously compete, and your project will be doomed to the dustbins of history.)
"We can't do one -and- the other! Don't be stupid!"
Let us use the example of a distributed kernel, because that's a nice, extreme example and it's not something anyone is doing right now so isn't politically hot. The lowest levels of the OS would need to be the same - the hardware hasn't changed. The uppermost layers of the OS would need to remain the same - distribution done right is going to be transparent to the applications. Only the middle would need changing, then.
CVS supports branches, but it's not so hot on branches of only a subset of a project. What we're wanting here is to make use of all development, avoiding unnecessary duplication of effort. The initial effort in producing a distributed kernel would be in allowing the whole of that middle layer of the kernel to be executed in parallel. That would probably be best maintained as a patch set, relative to the baseline OS.
Once that is done, you'd create a second fork. This second fork would be a patch-set relative to the initial parallelization effort, and would be concerned with efficient communication between parallel threads within the kernel. If threads are on the same physical machine, you want to use memory. That is fast and efficient. If the threads are on DIFFERENT machines, you want to be able to pass data as efficiently as physically possible.
Once that is done, you'd create a third fork. The third fork would allow the communications to take place between different kernels as if they were the same kernel. You now have transparent clustering, but you're still not truly distributed as these are still different kernels. You'd need a fourth fork, where redundancy could be eliminated on-the-fly and where you could have multiple instances of a single component - some local,
Humbug. Humbug, I say. If indefinitely expanding on a proven design was workable in the long-run, we'd all be programming in PL/I on machines with magnetic core memory using punch cards. You know that the Ramjet was designed in 1907 - trust me, it wasn't done by testing the pieces out first. Thrust-SSC was designed by through modelling the full system on computer then physically, before being built full-scale. The full system, not one wheel at a time.
A partial specification is impossible to prove, as is a partial program. You design from the top down, you implement from the bottom up, you NEVER, EVER do either from side to side. If you want to lay a railway track, it is of absolutely no value if you implement one rail first. You cannot test a single rail under real conditions. You do not implement it half a sleeper at a time. You certainly do not implement the rails first and then come back to do the sleepers later.
The "Extreme Programming" methodology you are talking about is very fashionable and is superb for producing single modules of very high quality. Single, focussed modules. OpenSSH, as the OpenBSDers have it, is indeed a remarkably well-polished single module of indisputable quality. A positive gem, in many respects. No doubt about it. I would never question that. And to polish a gem, you go to a specialist. That is no work for someone who has not honed their skills to the limit.
But could that specialist turn that gem into a fully-functional radio? Probably not, but virtually any electronics amateur who has played with radios has scratch-built a crystal set by turning a lump of rock into a functioning crystal oscillator. If you go further, and use leads that are fine enough and well-enough placed, you can build a functional transistor.
Specialists had been building machines that could follow a sequence of operations for years - one of the earliest such machines was the Jaquard Loom, in the Industrial Revolution. It took two generalists (Alan Turing and John von Neumann) who were skilled not only in mathematics but also biology and philosophy, to actually turn these specialized devices into general computing machines. Once generalist machines were built, it then took specialists to find a way to use them, but once that was established, it took generalists (usually garage developers) to turn them into machines people could actually use.
If you were to compare someone who had passed with a First from Oxford or Cambridge in England with the best MIT or Harvard could turn out, you'd consider them pretty equal. Different, but equal. But how can they be so different? Oxford and Cambridge are considered "Classical Education", with a high emphasis on producing people who are multi-disciplinarians. MIT and Harvard generally produce specialists within a very narrow subset of a single discipline.
Neither is better, and if you were to look to trying to gather the best of the best, you'd want people from both backgrounds. Nothing less would be even halfway decent, however bright the people were. You need both.
I don't have a problem with Theo, his methods or his beliefs. In fact, I consider them essential. It seems a pity to me that neither he, nor those who code alongside him, are quite so willing to consider others in the same light, but I also don't see it as my problem that they don't. If they're right, then Darwinism means they'll be the only ones left in the field. If I'm right, then both they AND the more classical programmers will be. They have nothing to lose either way, and I only have something to lose if I'm wrong, regardless of their opinions in the matter.
Newcomers! Honest. My first computer was a Commodore PET 3032. Not too long after, I started coding on the Apple II. Moved on to the BBC Micro, Vic 20, Commodore 64, Acorn Electron, Prime 350, Prime 750 and DEC PDP-11. Next up was the Ferranti PC, the Viglen PC, the Master 512 and the Acorn Archimedes. For the PC OS, around that time, I used MS-DOS, DR-DOS, Windows (starting with version 2), GEM and DesqView. A few years later, I added the Sun Sparcstation, the Motorola 68040 + VxWorks, 386BSD, Linux and the DEC VAX. Hmmm, after that I went through FreeBSD, NetBSD and OpenBSD, Solaris (x86 and Sparc), OSF/1, HP-UX and a little AIX. More recently, I've added Inferno, Plan9, ExoPC, EROS, HURD and the Linux variants of L4Linux and MOSIX/OpenMOSIX.
Not too shabby, either, given I turned 36 yesterday!
It's a fairly normal Software Engineering practice to make a product feature-complete, then refactor it to produce something that is of higher quality. Optimise too soon and you end up with unmaintainable code that you can only extend to do what you want with extreme difficulty.
My purpose is to do this the Right Way (by Software Engineering standards), which means getting the code feature-complete FIRST. The purpose of software engineering principles is not to have "neat" code, it is to have complete code. And, yes, that likely means the codebase will be larger. Is this bloat? No - bloat is unnecessary code. If it is necessary, it cannot be bloat, no matter how large the sourcefile becomes.
Once the codebase is complete, THEN you can worry about refactoring, optimising, cleaning out redundancy, etc. You can't decide what is unnecessary, though, until you know what IS necessary. If you cannot define one, you cannot define either.
Seeing bloat where none exists is a common form of myopia amongst certain groups of hackers. You can tell who suffers from it, because their skill-sets don't grow as quickly. You can't learn new technologies or new approaches when you're convinced that they're useless by definition. Such hackers are absolutely brilliant at their specialist fields, precisely because they're undistractable, but they're like a fish in hard vaccuum when confronted with anything they're unfamiliar with.
This is exactly why you need generalists. These are people who know how to link ideas together, know what ideas you should even TRY to link together, and are willing to explore the fringes of possibility in an effort to squeeze even one more drop of usefulness out of something.
If you want the absolute best design, you get a generalist. If you want the absolute best implementation of that design, you get a specialist. Specialists can't design to save their life (which is why the Shuttle is a piece of crap), generalists without specialist knowledge are too distractible to produce a good implementation (which is why you don't see many top Software Engineers in industry) and generalists WITH specialist knowledge tend to be the legends of the industry.
The ideal is to have teams with both types of people, so you can get the benefit of both types of skill without having to rely on having any legends around. Legends are too rare to rely on and impossible to replace if they quit or die. This isn't just true of computing - look at the music industry. A good 90% of all the top composers were in partnerships (Lennon/McCartney, for example) where the extreme gifts complemented each other rather than competed. The other 10% were gifted ENOUGH that they could cover both the breadth and depth at the same time.
If a partnership is impossible (as is blatantly obvious to anyone reading the AC replies to my posts!) then you have to apply the approach in layers. Use specialist and generalist skills alternately, to gain the maximum functionality, the minimum footprint, the maximum usability and the minimum risk. The OpenSSH team, as it stands, isn't capable of this. They're specialists, with a specialist mindset, and the egos you invariably get with specialist thinking. They're good coders, but they are intrinsically incapable of recognising the worth of others or the worth of avenues outside of their own fields.
When Theo was interviewed on Slashdot, I asked him about OpenBSD as a distributed kernel. He had no idea what that was and was clearly not about to find out.
For those interested, a distributed kernel is an OS kernel that runs on a cluster as a single kernel, not as a collection of independent kernels. If you want maximum performance on the cluster, you absolutely don't want the overheads of running code you don't want. This means you absolutely don't want the full OS on each node, you only want the bits that are actually needed on a local basis. (If a node is running a single program, you wouldn't even want
There are some interesting estimates out on the web of how fast the human brain can process data. Current estimates are between 10^13 and 10^16 operations per second, which would put the upper limit at about 10 giga mips (remember, 'mips' is a million instructions per second). If we assume the brain handles 'reals' rather than integer values for data, then this translates to about 10 peta flops.
In comparison, the world's fastest supercomputer (BlueGene/L) is rated at a maximum of 183,500 gigaflots, which is about 0.2 peta flops, or one fiftieth of the maximum speed of the human brain.
Now, you don't NEED the full processing power of the human brain in order to drive. That's not my point. My point is that a car-load of computer parts, at the current level of technology, is probably going to drive about as well as a Horseshoe Crab. I'm actually very impressed that developers have actually got as far as they have, as they're very unlikely to be using state-of-the-art technology for this, most are probably using pile-of-PC architectures, not much more than some webcams for vision and basic motors for the robot linkage, most likely continuous for power - steppers have vastly superior accuracy but have no force behind them.
You also have to look at the power cleaning systems they need - car batteries are NOT smooth and car electrical systems are typically pretty rough. On the other hand, computers need power that is spike-free and ADCs (analog-to-digital converters) rely on a steady reference voltage to be able to do anything useful. A noisy power system would be Bad News for a self-operating vehicle. Oh, and computers don't do well when hot, but air conditioning units - particularly if they switch on and off - are going to add some serious noise to the power.
Whoever builds a car that can go a decent distance is worthy of vast respect and awe, because there are some massive technical problems that require ingenious hacking of mechanical, electrical and microelectronic systems to operate in some pretty harsh environments.
I do think DARPA would be foolish to end the contest if there is a winner this year - rather, they should extend the challenge. Have the vehicles go through a wider range of terrains, as a multi-stage rally, perhaps, with cars who succeed in the desert then having to navigate through a forest, swamps, along the tops of snow-covered mountains - pretty much any terrain that a vehicle could realistically encounter if used for military missions.
If DARPA did that, and the contestents succeeded, then (and pretty much only then) would DARPA have a general-purpose robotic vehicle they could throw into any arena that would be hazardous for humans under combat conditions. Why stop when you have something that could have made things easier three years ago had it existed, but which may be useless in a scenario three years from now, when the dangers may be completely different?
If the car has IP/trade-secret technology the company needs to protect -or- technology that would violate somebody else's IP, then destroying the car may be legally necessary to protect the company. Having said that, I can't think of any IP that they could cash in on that they'd need to protect, and nobody in their right minds would risk putting unlicensed tech on something like this - the scandal if a story like that broke would far outweigh the prize on offer.
I can think of no reason at all. Hell, most "Science and Technology Museums" would love to have a car like that as an exhibit! And, last I heard, jet engines and a cruising speed of 716 mph wasn't street-legal anywhere, but the Thrust-SSC team didn't put their car through the trash compactor.
Slashdot Mirror
This could mean any of the following:
The TRIPS homepage has nine published papers on how this design will work and a schematic diagram of what they're expecting the design to end up looking like. They are also promising simulators and compilers later this year.
We're never going to get straight answers from nominees in the US judicial system, but it would be interesting to know how nominees would have handled the cases of Derek Bentley, Carol Hanson or other such cases of political convictions or other malpractices. Why these cases? They were in the UK, after all. That is precisely why. The cases are from a country similar enough that knowing the answers would tell us a lot, but different enough that the nominee is less likely to feel pressure by one American lobby group or another. No candidate sane enough to qualify is likely to be insane enough to comment on an issue likely to cause a pressure group to block the nomination, which means questions about issues hot within the US are a non-starter when it comes to finding anything out.
So ask questions that'll get you the information you want, but in a way that is unlikely to trigger a political third-world war against the nominee.
In practice, Microsoft isn't liable at all for anything, as they don't sell anything other than a permission slip and the permission was working just fine.
Having said that, I do agree that "experience" means very little. What matters is the ability to apply the facts of the case to the laws governing the case. That is not a matter of experience. Indeed, it couldn't be, as there are way too many statutary laws and way too much case law for an individual to actually remember it all. All you NEED to remember is procedure because that it all that can reasonably be expected of a person to remember. The rest is necessarily something the judge (or lawyer or whoever) will need to research on their own, in their own time.
My biggest concern is the same I would have about any judge - will they be able to impartially apply those procedures, or will they attempt to play favourites or "repay" sponsors who helped them get to their position? Honestly, I'm not sure judges should be appointed by political entities - especially as those entities are also involved in writing the laws AND in enforcing them (by controlling who is in charge of the Department of Justice). There's a high risk of a conflict of interest, regardless of whether any specific individual actually has such a conflict or whether they resolve it or not.
If Microsoft put completely blank CDs or DVDs in the boxed edition of Windows Vista, you would have no right of reply. You aren't buying the program, ALL you buy is the license. If the company provides the program, it is strictly a bonus and is not a part of the sale.
Do I agree with this stance? Do I hell! I believe that software should be bought and sold, and that although "totally free of defects" is unrealistic, there are probably realistic variants of "fit for the purpose for which it was sold" that software could be placed under. Either that, or software should be required to carry indicators of risk. That last one might be better, as it would work even for Open Source and research software, where "purpose" is often ill-defined as it is infinitely variable.
For binary document formats (eg: MS Office's
A better approach might be a hybrid of these - have a method of extracting/inserting the text as ASCII (which you can then log using a conventional source-control system) and have control sequences recorded as a macro on top of that. You then have to be absolutely certain that the correct two are applied together and in the right order, which may get complicated if there are branches, but the increase in complexity should be more than matched by a reduction in the amount you need to actually store.
I guess you can argue that if a project is actively maintained, any problems are potentially fixable. Even with Open Source, an abandoned project is going to be a lot tougher to work on - especially if it was broken at the time it was abandoned, as then you've got to spend time figuring out what was intended, not just what was coded.
Personally, I'd be more in favour of improving the file system layering - eg: having a layer that supports different forms of journalling and logging. Then you could remove explicit logging from the filesystems themselves, you'd only need to provide hooks to the journal/log layer. This would surely reduce bloat, allow people to experiment with different combinations of journal/log and filesystem, etc. If you add a metadata layer, you could even resolve many of the politics of Reiser4 by moving the directories-as-files and other metadata code into such a layer, making it universally available to all filesystems.
It is certainly true that abstracting out and encapsulating in this way usually produces slower code, as you can't have the calls as tightly written or the layer as specialized. On the other hand, I'm going to argue that loose bindings make for easier maintenance and will also increase the number of people who would have an interest in maintaining the code, which will eventually lead to better code and therefore faster code. Only it won't just be faster for one filesystem, it'll be faster for ALL filesystems the user has linked that log/journal component to.
*Cheese releases fumes that many chemical sniffers will register as those of an explosive. **Kitty litter is often slightly radioactive. It's probably a beta emitter - alpha gets absorbed too easily - but I can't find a definitive source of information.
If these new detectors can detect a nanogram of stilton, but still miss people with semi-automatics, then I don't see we've gained much. Unless there's a plan to use the next NASA mission to the moon to verify its composition is not, as Google claim, swiss cheese.
Of course, we could run into other problems. Will there be false alarms from residue? A lot of Americans do own guns, which means residue on the sorts of scale we're talking about is certainly possible. The security guards are also armed, which means there will be a background reading from those weapons. If cheese is still detected, then not only will we have to deal with actual pieces of cheese, but also any person who has eaten cheese in the past month.
There is no doubt we need a good, functioning weapons detector. I am rather hoping these guys have figured out how to build one. If I am skeptical, it is because I want to see better evidence that they really HAVE figured out how to build one.
The problem is, it's a Dromedary. (Only has one hump.) For development cycles, you really need a Bactrian camel. The prehistoric Camel of North America was about the size of a rabbit, which would make it perfect for embedded systems.
LISP, itself, is a language developed for parsing describable information - usually text. It was developed by an AI professor at MIT, IIRC, in one of the early attempts to develop a machine capable of learning.
Because LISP was run in a virtual machine, it was 100% portable. Any machine that had a LISP machine could run a LISP program. It was the real start of "run-anywhere" programming. Although LISP is not the most popular of languages, it has always been a surprise that it has never taken off amongst web developers for purely text-based processing. Java is way too heavy for that and Javascript is very cumbersome for text operations, yet LISP would be ideal for such work.
I'm not 100% sure of this, but I believe Tcl/Tk is derived from LISP, and the syntax used by the LambdaMOO virtual world is very similar and was probably influenced by it.
They're using a p2p fileswapping program to distribute it - doesn't that make it defacto music piracy?
If they WEREN'T forced to replace all the servers we'd just melted, can you imagine what would have happened when they put the live streaming video feed from the NASA control center during the next moon landing? Dunno about you, but I'd rather they get themselves equipt to handle that kind of mass onslaught now.
Maybe that's a giant luffa sponge made of cheese. (It actually looks like a lump of pumice.)
Part of the reason they're 'fessing up is because movies like March of the Penguins were actually doing better than "blockbuster" titles like Fantastic Four. (Per screen, on release, March of the Penguins actually did make more money than Fantastic Four. It has now made more money than Fifth Element, in total, according to some articles.) It is hard to keep claiming that it's someone else's fault when even a French wildlife documentary can outsell multi-million dollar projects from Hollywood.
I think the other part of the reason is that the RIAA is starting to take a turn for the worse in the courts, and the MPAA wants a backup plan in case this spreads to their own lawsuits. In other words, if a movie does crap and fileswappers cases get kicked out, then they can now say "well, we TOLD you the script for that specific movie was no good!" It also didn't help the MPAA when eDonkey started talking about quitting. If there are no fileswapper companies to blame, it's going to get harder for them to push responsibility onto others.
(After all, they've known for HOW LONG that other people's movies were selling just fine? They were having a downturn for how many YEARS before fuel costs shot up? But it was only very recently that fileswapper cases stopped doing well, and only in the last week that eDonkey talked out quitting.)
Will this get Hollywood to make something worth watching? Uh, no. What it'll mean is that they'll spend even MORE on public relations to persuade people that the next movie is worth seeing. That's the usual corporate reaction - why change things, when you only have to convince people they're changed?
The second problem is when the license (and/or other published material) is vague, contains serious omissions or is flat-out wrong. If I were to buy a wordprocessor but be given a blank CD, then I would want my money back. I've not been sold a damn thing. Legally, though, I'd be entitled to nothing since there's no guarantee there's even a product.
The third problem is with the assumption that a case has to involve lawyers AND that it has to be the fault of the consumer. In the case of a blank CD being sold as a wordprocessing package, how hard would it really be for a software company to say "oops!" and replace the CD with one that works? Wouldn't that be easier all round? And if there is no product, but they're really just out to rob people blind, is it reasonable for the consumers to say "oh, forgive us oh master! Please, take more of our money and give us nothing in return!"?
Responsibility is a shared thing, always. So share it!
What's wrong with a "lemon law" which says that if you say a computer program does X, Y and Z, on such-and-such a platform, then you are entitled to expect it to do X, Y an Z on that platform? And an expectation for businesses, retailers, etc, to honor that?
America is lawsuit-happy, because that's often the only way to get things done. NOBODY takes responsibility for their share of the problem, preferring to push everything onto somebody else. Honesty is optional, integrity is available for a price and selling to ignorance has become the norm. (It wasn't too long ago that American software giants tried to push a bill through where it would be illegal to review software without their permission. I'm not 100% it actually failed.)
If I install a Linux package under Windows, I have no business expecting it to work and should have no right of complaint. Unless it was sold as a Windows package. If I install a Windows package under Windows - correct version, correct platform, everything to specs - and I discover that it has errors even the most superficial QA should have spotted (such as not working at all), then I should also have a right - at the very least - to my money back. This isn't about fixing every bug (or shouldn't be), but about providing what has been sold.
And that's the crux. If Microsoft had (as has been claimed) 65,535 known bugs in the Windows 2000 database at the time of release, then it should have come with a warning that serious defects were known to exist and that not everything would behave as expected. The documentation should also have been modified to note anything that seriously deviated from the behaviour as published. That would have been honest. Sure, fewer people would have bought the program. If Microsoft had needed to do this, they might even have held off on the release until the more user-visible bugs have been cleared up. But would that have been so terrible?
I've no problem with buggy software being released, but software companies should be honest about when there ARE bugs and how serious those bugs are likely to impact typical users.
I'd call what we have not just broken but shot to shit. To quote Twisted Sister, "If that's your best, your best won't do!"
Are those American, Imperial or Metric Hours?
And THAT, my dear, has been my point all along. You CANNOT seek to do something you know nothing about. THAT is why generalists are essential, because only a generalist knows enough subjects to be able to expand the horizons of a project to the logical conclusion. It is ALSO why specialists are essential, because only a specialist knows enough about a given element to see it to completion and to do it right.
"But what if a project doesn't want to expand?"
If that is the correct approach, then the new variant will die off. "Survival of the fittest" applies to computer programs, just as much as it does to biological entities. If it is the wrong approach, the more restrictive original branch will die off. You will also get situations where BOTH variants can survive, and often this is the preferred result, particularly if the variants coexist peaceably. Actually, this is how you tell if something IS feature-complete - if a variant dies, then it is either too restrictive OR too extensive. Feature-complete variants will always be preferred by natural selection. When two variants have different domains, provided BOTH are feature-complete within their domains, they will both survive. If one is feature-complete and the other not, then the one that is not will be selected against.
(There is one, and only one, exception to this. Arrogantly assuming you are the be-all and end-all. There will ALWAYS be someone that little bit smarter, that little bit quicker and/or that little bit more flexible in their thinking. If they are welcomed as a friend - however alien their thoughts - then your pool of talent will always grow and you will never stagnate and rot in thought. If they are cast aside as though they were inferior, then at best you WILL stagnate. At worst, they'll take the best of what you have, build something so far beyond anything you've ever imagined that you will never seriously compete, and your project will be doomed to the dustbins of history.)
"We can't do one -and- the other! Don't be stupid!"
Let us use the example of a distributed kernel, because that's a nice, extreme example and it's not something anyone is doing right now so isn't politically hot. The lowest levels of the OS would need to be the same - the hardware hasn't changed. The uppermost layers of the OS would need to remain the same - distribution done right is going to be transparent to the applications. Only the middle would need changing, then.
CVS supports branches, but it's not so hot on branches of only a subset of a project. What we're wanting here is to make use of all development, avoiding unnecessary duplication of effort. The initial effort in producing a distributed kernel would be in allowing the whole of that middle layer of the kernel to be executed in parallel. That would probably be best maintained as a patch set, relative to the baseline OS.
Once that is done, you'd create a second fork. This second fork would be a patch-set relative to the initial parallelization effort, and would be concerned with efficient communication between parallel threads within the kernel. If threads are on the same physical machine, you want to use memory. That is fast and efficient. If the threads are on DIFFERENT machines, you want to be able to pass data as efficiently as physically possible.
Once that is done, you'd create a third fork. The third fork would allow the communications to take place between different kernels as if they were the same kernel. You now have transparent clustering, but you're still not truly distributed as these are still different kernels. You'd need a fourth fork, where redundancy could be eliminated on-the-fly and where you could have multiple instances of a single component - some local,
A partial specification is impossible to prove, as is a partial program. You design from the top down, you implement from the bottom up, you NEVER, EVER do either from side to side. If you want to lay a railway track, it is of absolutely no value if you implement one rail first. You cannot test a single rail under real conditions. You do not implement it half a sleeper at a time. You certainly do not implement the rails first and then come back to do the sleepers later.
The "Extreme Programming" methodology you are talking about is very fashionable and is superb for producing single modules of very high quality. Single, focussed modules. OpenSSH, as the OpenBSDers have it, is indeed a remarkably well-polished single module of indisputable quality. A positive gem, in many respects. No doubt about it. I would never question that. And to polish a gem, you go to a specialist. That is no work for someone who has not honed their skills to the limit.
But could that specialist turn that gem into a fully-functional radio? Probably not, but virtually any electronics amateur who has played with radios has scratch-built a crystal set by turning a lump of rock into a functioning crystal oscillator. If you go further, and use leads that are fine enough and well-enough placed, you can build a functional transistor.
Specialists had been building machines that could follow a sequence of operations for years - one of the earliest such machines was the Jaquard Loom, in the Industrial Revolution. It took two generalists (Alan Turing and John von Neumann) who were skilled not only in mathematics but also biology and philosophy, to actually turn these specialized devices into general computing machines. Once generalist machines were built, it then took specialists to find a way to use them, but once that was established, it took generalists (usually garage developers) to turn them into machines people could actually use.
If you were to compare someone who had passed with a First from Oxford or Cambridge in England with the best MIT or Harvard could turn out, you'd consider them pretty equal. Different, but equal. But how can they be so different? Oxford and Cambridge are considered "Classical Education", with a high emphasis on producing people who are multi-disciplinarians. MIT and Harvard generally produce specialists within a very narrow subset of a single discipline.
Neither is better, and if you were to look to trying to gather the best of the best, you'd want people from both backgrounds. Nothing less would be even halfway decent, however bright the people were. You need both.
I don't have a problem with Theo, his methods or his beliefs. In fact, I consider them essential. It seems a pity to me that neither he, nor those who code alongside him, are quite so willing to consider others in the same light, but I also don't see it as my problem that they don't. If they're right, then Darwinism means they'll be the only ones left in the field. If I'm right, then both they AND the more classical programmers will be. They have nothing to lose either way, and I only have something to lose if I'm wrong, regardless of their opinions in the matter.
Not too shabby, either, given I turned 36 yesterday!
My purpose is to do this the Right Way (by Software Engineering standards), which means getting the code feature-complete FIRST. The purpose of software engineering principles is not to have "neat" code, it is to have complete code. And, yes, that likely means the codebase will be larger. Is this bloat? No - bloat is unnecessary code. If it is necessary, it cannot be bloat, no matter how large the sourcefile becomes.
Once the codebase is complete, THEN you can worry about refactoring, optimising, cleaning out redundancy, etc. You can't decide what is unnecessary, though, until you know what IS necessary. If you cannot define one, you cannot define either.
Seeing bloat where none exists is a common form of myopia amongst certain groups of hackers. You can tell who suffers from it, because their skill-sets don't grow as quickly. You can't learn new technologies or new approaches when you're convinced that they're useless by definition. Such hackers are absolutely brilliant at their specialist fields, precisely because they're undistractable, but they're like a fish in hard vaccuum when confronted with anything they're unfamiliar with.
This is exactly why you need generalists. These are people who know how to link ideas together, know what ideas you should even TRY to link together, and are willing to explore the fringes of possibility in an effort to squeeze even one more drop of usefulness out of something.
If you want the absolute best design, you get a generalist. If you want the absolute best implementation of that design, you get a specialist. Specialists can't design to save their life (which is why the Shuttle is a piece of crap), generalists without specialist knowledge are too distractible to produce a good implementation (which is why you don't see many top Software Engineers in industry) and generalists WITH specialist knowledge tend to be the legends of the industry.
The ideal is to have teams with both types of people, so you can get the benefit of both types of skill without having to rely on having any legends around. Legends are too rare to rely on and impossible to replace if they quit or die. This isn't just true of computing - look at the music industry. A good 90% of all the top composers were in partnerships (Lennon/McCartney, for example) where the extreme gifts complemented each other rather than competed. The other 10% were gifted ENOUGH that they could cover both the breadth and depth at the same time.
If a partnership is impossible (as is blatantly obvious to anyone reading the AC replies to my posts!) then you have to apply the approach in layers. Use specialist and generalist skills alternately, to gain the maximum functionality, the minimum footprint, the maximum usability and the minimum risk. The OpenSSH team, as it stands, isn't capable of this. They're specialists, with a specialist mindset, and the egos you invariably get with specialist thinking. They're good coders, but they are intrinsically incapable of recognising the worth of others or the worth of avenues outside of their own fields.
When Theo was interviewed on Slashdot, I asked him about OpenBSD as a distributed kernel. He had no idea what that was and was clearly not about to find out.
For those interested, a distributed kernel is an OS kernel that runs on a cluster as a single kernel, not as a collection of independent kernels. If you want maximum performance on the cluster, you absolutely don't want the overheads of running code you don't want. This means you absolutely don't want the full OS on each node, you only want the bits that are actually needed on a local basis. (If a node is running a single program, you wouldn't even want
In comparison, the world's fastest supercomputer (BlueGene/L) is rated at a maximum of 183,500 gigaflots, which is about 0.2 peta flops, or one fiftieth of the maximum speed of the human brain.
Now, you don't NEED the full processing power of the human brain in order to drive. That's not my point. My point is that a car-load of computer parts, at the current level of technology, is probably going to drive about as well as a Horseshoe Crab. I'm actually very impressed that developers have actually got as far as they have, as they're very unlikely to be using state-of-the-art technology for this, most are probably using pile-of-PC architectures, not much more than some webcams for vision and basic motors for the robot linkage, most likely continuous for power - steppers have vastly superior accuracy but have no force behind them.
You also have to look at the power cleaning systems they need - car batteries are NOT smooth and car electrical systems are typically pretty rough. On the other hand, computers need power that is spike-free and ADCs (analog-to-digital converters) rely on a steady reference voltage to be able to do anything useful. A noisy power system would be Bad News for a self-operating vehicle. Oh, and computers don't do well when hot, but air conditioning units - particularly if they switch on and off - are going to add some serious noise to the power.
Whoever builds a car that can go a decent distance is worthy of vast respect and awe, because there are some massive technical problems that require ingenious hacking of mechanical, electrical and microelectronic systems to operate in some pretty harsh environments.
I do think DARPA would be foolish to end the contest if there is a winner this year - rather, they should extend the challenge. Have the vehicles go through a wider range of terrains, as a multi-stage rally, perhaps, with cars who succeed in the desert then having to navigate through a forest, swamps, along the tops of snow-covered mountains - pretty much any terrain that a vehicle could realistically encounter if used for military missions.
If DARPA did that, and the contestents succeeded, then (and pretty much only then) would DARPA have a general-purpose robotic vehicle they could throw into any arena that would be hazardous for humans under combat conditions. Why stop when you have something that could have made things easier three years ago had it existed, but which may be useless in a scenario three years from now, when the dangers may be completely different?
If the car has IP/trade-secret technology the company needs to protect -or- technology that would violate somebody else's IP, then destroying the car may be legally necessary to protect the company. Having said that, I can't think of any IP that they could cash in on that they'd need to protect, and nobody in their right minds would risk putting unlicensed tech on something like this - the scandal if a story like that broke would far outweigh the prize on offer.
I can think of no reason at all. Hell, most "Science and Technology Museums" would love to have a car like that as an exhibit! And, last I heard, jet engines and a cruising speed of 716 mph wasn't street-legal anywhere, but the Thrust-SSC team didn't put their car through the trash compactor.