Actually they got to send their spam and get away with it. Note that even in the apology they're promoting their services.
You may think I'm being overly cynical, but we had a case where a client said something like "You know all those people who said they didn't want to receive mail from us? Well how would it be if we made a 'mistake' then apologised?".
Robots like this have been available for a lot longer than five years. I remember a robot with a similar drivetrain to Descartes being available in the UK in the eighties -- it was typically used with a BBC Micro. I'm fairly certain that even that wasn't the first.
Well that's pretty much the way with ideal worlds. Just as it's common to consider frictionless systems I think it's reasonable to think about how an SMP system would behave if these constrainsts didn't exist. We all know it's hypothetical, but that doesn't make it worthless.
Interestingly they couldn't then go on to use as much of the information as they might have wished because if they had the Germans would have know that their messages were being intercepted.
It is believed, for example, that considerable advance warning was available about the invasion of Crete, but the Allied command were prevented from acting on it because that would have revealed that the German encryption had been cracked.
Setting aside for the moment the fact that Java is a compiled language, the benefits of its much touted portability extend far beyond portability for whole applications. Code reuse across multiple platforms and multiple environments on those platforms is in many ways a far more significant advantage.
As a trivial example we have a simple HTML parser that, to date, we've used in an Applet, a stand alone application which runs on a number of platforms, a number of servlet based systems and in a Lotus Domino agent. We can do this because the same standard classes are available at runtime in all these environments.
Now you might observe that C++ also has a standard library, but for various reasons it is much less pervasive. I recently wrote some C++ to get Visio talking to Lotus Notes. At one point within the scope of a single function I was dealing with three different string types, none of which came from the STL. C++ is great for pure C++ applications, but increasingly developers spend at least some of their time writing glueware and if you do that in C++ you're quite likely to find out that more than 50% of your code is concerned with
bashing strings from one string type to another
duplicating functionality that exists in the STL but is not available here, now
munging errors into exceptions and vice versa
etc, etc
I've been trying to achieve meaningful amounts of code reuse for years, but it's only since we've started using Java that this has become a reality.
Usual disclaimer: YMMV. I'm not a language bigot; I've used Perl, Java and C++ today;-)
...in 277 pages that describe a substantially Java like language they manage not to mention Java once . Seems that they're so arrogant that they're not even prepared to acknowledge their debt to Sun on this one. Evidently being beaten up by the DoJ hasn't taught them any humility.
I agree 100% with the point you make. This failure to understand his own role in relation to free software (there are no users, only collaborators) also informs his downstream argument where he fails to see that a company such as his might contribute to an open source project out of enlightened self interest. As it is he identifies that companies sometimes fund open source development without really detailing the huge benefit (namely that they end up with high quality tools that do exactly what they want at a fraction of the cost of developing them from scratch) that they derive from doing so.
All that said I do have some sympathy with his argument. I can't bring myself to believe that it is always morally wrong to charge for software. What the open source phenomenon should tell us is that it isn't always right or sensible to charge for software, but it isn't always wrong either.
For me the overarching moral issue is the availability of source code -- selling somebody something that is almost certainly broken (because software is) while denying even those of them who have the ability to fix it the possibility of doing so is so very obviously wrong that I can't understand why more people aren't militant about it.
Re:Why is MySQL more popular than PostgreSQL?
on
Why Not MySQL?
·
· Score: 1
Or, in our case, we do understand about the database integrity dangers and are prepared to deal with them at application level. Ignorance isn't the only reason to use MySQL. Arrogance about one's own ability to avoid the pitfalls is a factor too!
Firstly I think you negated what I was describing as counter intuitive; I was actually agreeing with you that it seems counter intuitive that compiled code could be as fast as hand coded assembler. Sorry if that wasn't clear
I'm inclined to dispute whether GC is inherently less efficient than discrete alloc / dealloc. I guess we could argue about it until the cows come home, and I certainly can't prove the point either way, but I've heard compelling arguments to the effect that, because a GC effectively deals with multiple deallocations at once there are economies of scale it can benefit from. My own experience with shifting heap allocator certainly supports this view.
Of course, as I pointed out elsewhere, if there is any performance advantage inherent in garbage collection you could just re-implement your alloc/dealloc manager in terms of my garbage collector and make your dealloc call a NOP.
I agree that current Java implementations are in part enslaved by Java's requirement for dynamic despatching, but even some current compilers are capable of determining many of the cases where methods can be despatched statically. Smarter compilers can mop up most of the remaining disadvantage.
I still don't see anything here that means that Java (and other p-code language systems) must be inherently slower than hand coded assembler. Nothing technical anyhow. Economic issues are clearly another thing...
Incidently, although I like Java, I didn't set out to advocate Java + JIT as an alternative to other languages. I don't find language wars productive. On a good day I might find myself using ARM Assembler, x86 Assembler, PPC Assembler, Perl, C, C++, VB, LotusScript, Java (OK, that would be a very good day).
I didn't exactly mean that Java should use the stack, just something that looked like a stack. In its most basic implementation a stack is a pointer that marches through memory advancing by the size of each object that is placed on it. Of course it is usual to pull things back off the stack and you can only normally do that in reverse order.
malloc() / free() in conrast have rather more work to do. malloc() has to search through a number of data structures to find an appropriate chunk of memory, and free() has to return memory to the heap in such a way that the heap is still usable.
My point is that when you have a garbage collector that can take an overview of the whole heap, your allocation strategy can be much more simple. The most simple possible case would be to have a pointer (c.f. stack pointer) that simply moves forward through memory by the size of each block allocated. Then all the work falls to the garbage collector which has to sort out a heap that may potentially have a number of gaps in it (corresponding to objects that have gone out of scope in 'non stack' order).
In practice garbage collected memory manager that worked in this way would be a little naive, but I would still maintain that a GC system should be able to achieve better performance than a malloc() / free() system because malloc() / free() have to micro-manage the heap, keeping it in a usable state after each call whereas a garbage collector can do all its heap optimisation at once.
Actually I'm cheating a bit here, so I better come clean before someone else points it out. malloc() / free() can actually enjoy all the benefits that I attribute to a garbage collecting memory manager if you implement them like this:
voidfree(void*mem) { /*donothingatall*/ (void)mem; } In other words you can implement malloc() / free() on top of a garbage collector. This is what happens with the garbage collector libraries for C++; new() just calls the GC's allocator and delete() does nothing.
It might also be said that humans can always write a better compiler than the one they just completed.
For arguments sake let's arrange a code off between a completely optimal compiler (this is a somewhat idealised scenario) and a completely optimal human programmer.
In a normal compile once, run many times scheme of things, assuming the human and the compiler program equally well neither has the advantage, but if you make the compiler into a JIT compiler that works actively to optimise the code in real time, perhaps recompiling more than once before it is satisfied, the human loses out. It becomes the equivalent of shipping a highly skilled assembly language programmer with each copy of the software and having them tweak it in real time (assuming they could program very, very quickly).
I can't see too many theoretical reasons why a compiler shouldn't program as well as a human. All of the obvious ones are consequences of the human having a better understanding of the problem so that for example s/he knows that a variable can only ever hold a small subset of the values its size would allow. Most of these things though are either moot in the context of modern processor design (because the natural word length is fastest) or are actually better left to a JIT compiler that can monitor the program in real time and, if necessary, rewrite it also in real time.
Imagine for example a numerically intensive algorithm which processes a data stream who's character changes slowly over time (image compression for example). A JIT compiler (+ instrumentation) could watch the algorithm as it runs and, at some point mid data stream, decide it needs to re-optimize the code. No problem: it rewrites the code and switches it in real time.
I suppose this is the core point I'm making: all other things being roughly equal Transmeta style technology may have the potential to yield processor architectures that actually work faster than the current theoretical maximum.
Well Open Source stuff is OK, but I was making the point that companies are increasingly targetting Linux for binary only releases, and quite often only produce X86 versions.
There are a load of 'commitment to Linux' announcements at the moment because that's what the world's media are talking about. I agree with you that companies that 'get it' are more likely to embrace open source in general as opposed to thinking Linux == the whole thing.
Also, why does Linux support so often end up being X86 only? Within 5 feet of me I have Linux running on Sparc, StrongARM and PowerPC, but there are many Linux applications distributed as binaries only that I can only use on an Intel box.
This highlights a general problem. Some companies are embracing Linux (/Open Source/whatever) because they've actually had some kind of epiphany and can see a way for their company to join the revolution. Others have noticed that Linux is getting a lot of publicity and have worked out that/. and others are willing to publicise their company if they make some kind of 'supporting Linux announcement'.
Perhaps there is a case for a/. spin-off site that watches companies that make Linux related commitments over a period of time and attempts to assess the sincerity of those company's efforts.
I think you're missing the point here. I presume this technology is not measuring the density of cellphones ('there are a large number of cellphones here, so there must be a lot of cars'), but the speed of a small sample of cellphones. Assuming you can estimate how a bunch of cellphones are moving you can generalise about the speed of the traffic. Fewer cellphones will, of course, mean less reliable data -- that just means you get two results from the maths: the estimated speed of the traffic and the reliability of that estimate.
It would be interesting to see what justifications are being used within companies to get the go-ahead for O/S releases. It's still a difficult business model to sell to conservative minds.
I would say the onus was on the spider writer to deal with broken HTML, loops, traps &c. I wrote this in response to another posting as a little demo of a spider trap. Although a human visitor will rapidly get bored it's not trivial to see how a robot could reasonably avoid being sucked in. The only general solution I can see is to get the spider to request human mediation if it finds that it's indexing a huge number of pages all from the same domain.
Since opening fifteen short minutes ago, the spider trap at this little Servlet has taken several hundred hits and the hit rate seems to be climbing pretty steadily. Advertising anyone?;-)
Slashdot Mirror
Well if it's released under a free license they can't really 'steal' it -- it's already theirs.
You're allowed to use your editor of choice and cut and paste...
You may think I'm being overly cynical, but we had a case where a client said something like "You know all those people who said they didn't want to receive mail from us? Well how would it be if we made a 'mistake' then apologised?".
It wasn't 7.30 everywhere in the world of course...
Robots like this have been available for a lot longer than five years. I remember a robot with a similar drivetrain to Descartes being available in the UK in the eighties -- it was typically used with a BBC Micro. I'm fairly certain that even that wasn't the first.
Well that's pretty much the way with ideal worlds. Just as it's common to consider frictionless systems I think it's reasonable to think about how an SMP system would behave if these constrainsts didn't exist. We all know it's hypothetical, but that doesn't make it worthless.
It is believed, for example, that considerable advance warning was available about the invasion of Crete, but the Allied command were prevented from acting on it because that would have revealed that the German encryption had been cracked.
As a trivial example we have a simple HTML parser that, to date, we've used in an Applet, a stand alone application which runs on a number of platforms, a number of servlet based systems and in a Lotus Domino agent. We can do this because the same standard classes are available at runtime in all these environments.
Now you might observe that C++ also has a standard library, but for various reasons it is much less pervasive. I recently wrote some C++ to get Visio talking to Lotus Notes. At one point within the scope of a single function I was dealing with three different string types, none of which came from the STL. C++ is great for pure C++ applications, but increasingly developers spend at least some of their time writing glueware and if you do that in C++ you're quite likely to find out that more than 50% of your code is concerned with
I've been trying to achieve meaningful amounts of code reuse for years, but it's only since we've started using Java that this has become a reality.
Usual disclaimer: YMMV. I'm not a language bigot; I've used Perl, Java and C++ today ;-)
Hey, I remember when 8k was enough for an OS and a Basic interpreter ;-)
Anyone fancy writing something really small?
Hence the Mac version of IE. No, wait a minute. That can't be right.
...in 277 pages that describe a substantially Java like language they manage not to mention Java once . Seems that they're so arrogant that they're not even prepared to acknowledge their debt to Sun on this one. Evidently being beaten up by the DoJ hasn't taught them any humility.
I agree 100% with the point you make. This failure to understand his own role in relation to free software (there are no users, only collaborators) also informs his downstream argument where he fails to see that a company such as his might contribute to an open source project out of enlightened self interest. As it is he identifies that companies sometimes fund open source development without really detailing the huge benefit (namely that they end up with high quality tools that do exactly what they want at a fraction of the cost of developing them from scratch) that they derive from doing so.
All that said I do have some sympathy with his argument. I can't bring myself to believe that it is always morally wrong to charge for software. What the open source phenomenon should tell us is that it isn't always right or sensible to charge for software, but it isn't always wrong either.
For me the overarching moral issue is the availability of source code -- selling somebody something that is almost certainly broken (because software is) while denying even those of them who have the ability to fix it the possibility of doing so is so very obviously wrong that I can't understand why more people aren't militant about it.
Or, in our case, we do understand about the database integrity dangers and are prepared to deal with them at application level. Ignorance isn't the only reason to use MySQL. Arrogance about one's own ability to avoid the pitfalls is a factor too!
From what I've read about Crusoe ARM still has a substantial lead in power consumption.
I'm inclined to dispute whether GC is inherently less efficient than discrete alloc / dealloc. I guess we could argue about it until the cows come home, and I certainly can't prove the point either way, but I've heard compelling arguments to the effect that, because a GC effectively deals with multiple deallocations at once there are economies of scale it can benefit from. My own experience with shifting heap allocator certainly supports this view.
Of course, as I pointed out elsewhere, if there is any performance advantage inherent in garbage collection you could just re-implement your alloc/dealloc manager in terms of my garbage collector and make your dealloc call a NOP.
I agree that current Java implementations are in part enslaved by Java's requirement for dynamic despatching, but even some current compilers are capable of determining many of the cases where methods can be despatched statically. Smarter compilers can mop up most of the remaining disadvantage.
I still don't see anything here that means that Java (and other p-code language systems) must be inherently slower than hand coded assembler. Nothing technical anyhow. Economic issues are clearly another thing...
Incidently, although I like Java, I didn't set out to advocate Java + JIT as an alternative to other languages. I don't find language wars productive. On a good day I might find myself using ARM Assembler, x86 Assembler, PPC Assembler, Perl, C, C++, VB, LotusScript, Java (OK, that would be a very good day).
malloc() / free() in conrast have rather more work to do. malloc() has to search through a number of data structures to find an appropriate chunk of memory, and free() has to return memory to the heap in such a way that the heap is still usable.
My point is that when you have a garbage collector that can take an overview of the whole heap, your allocation strategy can be much more simple. The most simple possible case would be to have a pointer (c.f. stack pointer) that simply moves forward through memory by the size of each block allocated. Then all the work falls to the garbage collector which has to sort out a heap that may potentially have a number of gaps in it (corresponding to objects that have gone out of scope in 'non stack' order).
In practice garbage collected memory manager that worked in this way would be a little naive, but I would still maintain that a GC system should be able to achieve better performance than a malloc() / free() system because malloc() / free() have to micro-manage the heap, keeping it in a usable state after each call whereas a garbage collector can do all its heap optimisation at once.
Actually I'm cheating a bit here, so I better come clean before someone else points it out. malloc() / free() can actually enjoy all the benefits that I attribute to a garbage collecting memory manager if you implement them like this:
void*malloc(size_tsize)
/*getmemoryfromagarbagecollect edstorageallocator*/
/*donothingatall*/
{
returngc_alloc_new(size);
}
voidfree(void*mem)
{
(void)mem;
}
In other words you can implement malloc() / free() on top of a garbage collector. This is what happens with the garbage collector libraries for C++; new() just calls the GC's allocator and delete() does nothing.
For arguments sake let's arrange a code off between a completely optimal compiler (this is a somewhat idealised scenario) and a completely optimal human programmer.
In a normal compile once, run many times scheme of things, assuming the human and the compiler program equally well neither has the advantage, but if you make the compiler into a JIT compiler that works actively to optimise the code in real time, perhaps recompiling more than once before it is satisfied, the human loses out. It becomes the equivalent of shipping a highly skilled assembly language programmer with each copy of the software and having them tweak it in real time (assuming they could program very, very quickly).
I can't see too many theoretical reasons why a compiler shouldn't program as well as a human. All of the obvious ones are consequences of the human having a better understanding of the problem so that for example s/he knows that a variable can only ever hold a small subset of the values its size would allow. Most of these things though are either moot in the context of modern processor design (because the natural word length is fastest) or are actually better left to a JIT compiler that can monitor the program in real time and, if necessary, rewrite it also in real time.
Imagine for example a numerically intensive algorithm which processes a data stream who's character changes slowly over time (image compression for example). A JIT compiler (+ instrumentation) could watch the algorithm as it runs and, at some point mid data stream, decide it needs to re-optimize the code. No problem: it rewrites the code and switches it in real time.
I suppose this is the core point I'm making: all other things being roughly equal Transmeta style technology may have the potential to yield processor architectures that actually work faster than the current theoretical maximum.
Oracle and Lotus spring to mind among others.
Also, why does Linux support so often end up being X86 only? Within 5 feet of me I have Linux running on Sparc, StrongARM and PowerPC, but there are many Linux applications distributed as binaries only that I can only use on an Intel box.
Perhaps there is a case for a /. spin-off site that watches companies that make Linux related commitments over a period of time and attempts to assess the sincerity of those company's efforts.
I think you're missing the point here. I presume this technology is not measuring the density of cellphones ('there are a large number of cellphones here, so there must be a lot of cars'), but the speed of a small sample of cellphones. Assuming you can estimate how a bunch of cellphones are moving you can generalise about the speed of the traffic. Fewer cellphones will, of course, mean less reliable data -- that just means you get two results from the maths: the estimated speed of the traffic and the reliability of that estimate.
It would be interesting to see what justifications are being used within companies to get the go-ahead for O/S releases. It's still a difficult business model to sell to conservative minds.
I would say the onus was on the spider writer to deal with broken HTML, loops, traps &c. I wrote this in response to another posting as a little demo of a spider trap. Although a human visitor will rapidly get bored it's not trivial to see how a robot could reasonably avoid being sucked in. The only general solution I can see is to get the spider to request human mediation if it finds that it's indexing a huge number of pages all from the same domain.