Also there have been very FEW viruses that infect PDF's,
You mean none? PDF doesn't allow embedded arbitrary code like PostScript.
-Kevin
Re:PDF Files arn't easily modifiable.
on
Microsoft takes on PDF
·
· Score: 5, Insightful
Just because you use XML doesn't mean that your format is open/accessible. XML is just a low level file format that requires a language to be useful. I mean binary is an open format because all computers understand 1s and 0s right? No...
PDF isn't a very good format either because Adobe controls the spec. It isn't open.
Looking at Microsoft's XDocs FAQ since I can't get to the article, it appears to be geared primarily towards creating forms so it's not obvious how it competes directly. I never liked PDF forms and they seems to be used rarely.
The evilness of XDocs depends on whether you will be able to easily use them without Office. PDF has wide support on many platforms.
I think you're forgetting the.NET servers scored better on scalability and reliability - look at the CPU scaling graphs and remember one of the app servers failed after just two hours.
Yeah, that's great if your app runs on one box. I mean real scalability with multiple machines, multiple databases, and so on. Many companies can throw hardware at problems as long as the app will scale. An app server failure in this simplistic test proves nothing, though I have seen no indication that.NET is unreliable or won't scale.
And performance DOES matter - an application that serves twice as fast may require as few as half the number of CPUs to serve a given user base.
Again, that is just a naive view. CPU is only a part of the picture. Many real enterprise apps will have issues like I/O, database storage, and network access across many machines. The high importance of CPU is a very PC-centric view. In many cases, it's I/O I/O I/O. Mainframes don't have fast CPUs, they have mega I/O and those funky networked DASD drives. All the CPU in the world does you no good if you're constrained by bad I/O and you can't keep it fed with data.
And guess what, Unix boxes with storage arrays (and mainframes) are the hardware of choice for a lot of data heavy applications. That knocks.NET out of the picture as an end to end solution. I don't doubt.NET is a great platform for some applications or part of other applications, it just isn't the end all be all. Personally I don't like the proprietary nature of Java, but I really can't stand the single OS limitation of.NET. Down at the code factory, we have stuff on Windows, Solaris, AIX, and Linux plus there are bridges from the mainframes. J2EE/Java is far from perfect, but at least it is more flexible from a hardware standpoint.
Was it faster than the PetStore that Sun provided? Yes? Then they optimized the code.
Maybe "extensively" means something different to you, but to me it means very optimized, possibly close to optimal. They weren't even using the current version of Sun's implementation (which is CMP based, btw)!
Oracle already published benchmarks a long time ago, there is another pet store implementation, and so on. Your calls to put up or shut up aren't necessary because the Java community already did a long time ago. The onus is on the.NET community to prove why this immature platform should be able to copy J2EE, run only on a single OS platform, and proclaim itself as a competitor in the enterprise arena (where everyone doesn't run Windows!).
Performance doesn't matter for enterprise apps like it might for desktop apps. It's a big consideration, buy scalability and reliability tend to be bigger issues. Performance is rarely an absolute requirement or we'd all code in hand optimized assembly.
My understanding is that Microsoft doesn't JIT adaptively like Java does, so there's quite a difference in the bytecode to native code translation. Microsoft had a clean slate and Java to learn from and they (IMO) made a simpler design that seems to perform just as well.
Perl is not interpreted and has not been for a long, long time.
Perl is interpreted, it just doesn't use a bytecode representation. Java is much faster than Perl in my experience because Java is compiled (at runtime).
the whole BS on here as if Microsoft should go to great lengths to polish Sun's code is just hilarious
First of all, this is TMC, not Microsoft.
Secondly, you're twisting what was said into something anti-MS. But then you're coming off as a Microsoft church member, so maybe that's a requirement of the Holy EULA.
_TMC_ said they optimized the code. They shouldn't have said it if it wasn't true, or they should have stated their lack of J2EE expertise. Their behavior was unethical if that is the case (I have still not made a conclusion, though I'd have to say that their expertise is in question).
"This report contains the results of an extensive new series of benchmarks based on a new implementation of the Java Pet Store, developed by the Middleware Company. The new implementation has been extensively optimized for performance and scalability, and tested in two leading J2EE application servers. "
Also, I bet I was one of the first people to write Netscape email and ask for a way to stop animated GIFs, preferrably with a permanent option. Yes, it's been a pet peeve for a while;). Oh, the bad ol 0.9 beta days with Trumpet Winsock...
It's a toy compared to a real RDBMS like Oracle, DB2, Sybase, even SQL Server;). MySQL didn't even have proper transactions until recently. My gripe with the big RDBMSs is how overly complicated they are to maintain and the endless parameters that have to be set by a DBA. At least that's my experience with DB2/UDB.
I thought lots of malloc implementations deferred allocating pages. Just because you allocate 10m doesn't mean you're going to use it. I don't see how the scenario you described could even happen with correct VM accounting.
This is a tangent, but I was recently bored and researching malloc and calloc at work because we had some C code that called malloc and memset a lot instead of calloc. On Linux, calloc defers clearing. I don't completely understand how it works -- I think some MMUs will clear for you. I got ahold of Sun regarding Solaris and it turns out calloc just calls malloc! I thought it was amusing. The performance difference was negligible for my purposes on Solaris.
I think that is excellent performance at this point. There's a lot more complexity having Mach, BSD, and I assume still significant parts of NextStep, than having one monolithic kernel.
Why can't they just change the address bus / MMU later? They're dumbing down the addressing from the Power 4 anyway - I assume they'll take notes so they can remember how to switch it back;-).
That's pretty good. I would explain it a little differently with more emphasis on there being stages to executing one instruction, and contrasting with superscalar.
First off, "superscalar" is when multiple functional units can do work in parallel. For example, two adds can happen at the same time on most processors. This is what I take "wide" to mean. Lots of true parallelism.
Pipelining is not really executing various instructions at the same time. It is executing _parts_ of those instructions at the same time.
That's important to bear in mind.
In order to execute an instruction, several steps (stages in the pipeline) must occur, the fetch, decode, execution and memory access he mentions. That's for just one instruction.
Each "step" happens on a clock cycle before the instruction can move on to the next stage and instructions may take many cycles to complete. This is like putting something into a pipe and waiting for it to come out the other end.
To speed this up, you don't execute multiple instructions at once, you start processing the next instruction before the previous one is done. When instruction A is on step 2, instruction B can be on step 1 because A is no longer using that part of the processor.
This is similar to putting several things into a pipe before the first one comes out the other end. They will all come out close together (e.g. 1 clock cycle) even though each instruction took many clock cycles total. You put in 16 things and they still come out one at a time, but much closer together than if you waited for each one (exactly like the good washing example above) That is pipelining. If your processor was 16 adders (a lot!) "wide" you could put in 16 adds and they would complete at the _same_ time. That's superscalar.
For the curiouser: instruction prefetch is used to keep pipelines busy. Branches are the bane of pipelines because you may have to throw away all the partially finished instructions because you just found out you're going somewhere else. There are ways to deal with that such as branch prediction.
I'm concerned about the possible wrong uses of freedom.
That statement scares me.
If you give people choices, they may make bad choices. I don't believe that makes choice bad.
Freedom has no conscience, but restrictions on freedom do. I think the fault lies with restricting freedom for that reason: someone or some group's motivations to restrict what you can do or say seems more dangerous to me.
I don't think restricting freedom is justified by assuming people are criminals, which is exactly what most of this DRM stuff does. Finally, I don't believe that companies have a right to profit that should be able to trump freedom.
Slashdot Mirror
You mean none? PDF doesn't allow embedded arbitrary code like PostScript.
-Kevin
PDF isn't a very good format either because Adobe controls the spec. It isn't open.
Looking at Microsoft's XDocs FAQ since I can't get to the article, it appears to be geared primarily towards creating forms so it's not obvious how it competes directly. I never liked PDF forms and they seems to be used rarely.
The evilness of XDocs depends on whether you will be able to easily use them without Office. PDF has wide support on many platforms.
-Kevin
-Kevin
s/anecote/anecdote/g;
-Kevin
Yeah, that's great if your app runs on one box. I mean real scalability with multiple machines, multiple databases, and so on. Many companies can throw hardware at problems as long as the app will scale. An app server failure in this simplistic test proves nothing, though I have seen no indication that .NET is unreliable or won't scale.
And performance DOES matter - an application that serves twice as fast may require as few as half the number of CPUs to serve a given user base.
Again, that is just a naive view. CPU is only a part of the picture. Many real enterprise apps will have issues like I/O, database storage, and network access across many machines. The high importance of CPU is a very PC-centric view. In many cases, it's I/O I/O I/O. Mainframes don't have fast CPUs, they have mega I/O and those funky networked DASD drives. All the CPU in the world does you no good if you're constrained by bad I/O and you can't keep it fed with data.
And guess what, Unix boxes with storage arrays (and mainframes) are the hardware of choice for a lot of data heavy applications. That knocks .NET out of the picture as an end to end solution. I don't doubt .NET is a great platform for some applications or part of other applications, it just isn't the end all be all. Personally I don't like the proprietary nature of Java, but I really can't stand the single OS limitation of .NET. Down at the code factory, we have stuff on Windows, Solaris, AIX, and Linux plus there are bridges from the mainframes. J2EE/Java is far from perfect, but at least it is more flexible from a hardware standpoint.
-Kevin
Maybe "extensively" means something different to you, but to me it means very optimized, possibly close to optimal. They weren't even using the current version of Sun's implementation (which is CMP based, btw)!
Oracle already published benchmarks a long time ago, there is another pet store implementation, and so on. Your calls to put up or shut up aren't necessary because the Java community already did a long time ago. The onus is on the .NET community to prove why this immature platform should be able to copy J2EE, run only on a single OS platform, and proclaim itself as a competitor in the enterprise arena (where everyone doesn't run Windows!).
-Kevin
-Kevin
-Kevin
Perl is interpreted, it just doesn't use a bytecode representation. Java is much faster than Perl in my experience because Java is compiled (at runtime).
-Kevin
First of all, this is TMC, not Microsoft.
Secondly, you're twisting what was said into something anti-MS. But then you're coming off as a Microsoft church member, so maybe that's a requirement of the Holy EULA.
_TMC_ said they optimized the code. They shouldn't have said it if it wasn't true, or they should have stated their lack of J2EE expertise. Their behavior was unethical if that is the case (I have still not made a conclusion, though I'd have to say that their expertise is in question).
"This report contains the results of an extensive new series of benchmarks based on a new implementation of the Java Pet Store, developed by the Middleware Company. The new implementation has been extensively optimized for performance and scalability, and tested in two leading J2EE application servers. "
-Kevin
-Kevin
-Kevin
-Kevin
-Kevin
-Kevin
This is a tangent, but I was recently bored and researching malloc and calloc at work because we had some C code that called malloc and memset a lot instead of calloc. On Linux, calloc defers clearing. I don't completely understand how it works -- I think some MMUs will clear for you. I got ahold of Sun regarding Solaris and it turns out calloc just calls malloc! I thought it was amusing. The performance difference was negligible for my purposes on Solaris.
-Kevin
-Kevin
-Kevin
First off, "superscalar" is when multiple functional units can do work in parallel. For example, two adds can happen at the same time on most processors. This is what I take "wide" to mean. Lots of true parallelism.
Pipelining is not really executing various instructions at the same time. It is executing _parts_ of those instructions at the same time. That's important to bear in mind.
In order to execute an instruction, several steps (stages in the pipeline) must occur, the fetch, decode, execution and memory access he mentions. That's for just one instruction.
Each "step" happens on a clock cycle before the instruction can move on to the next stage and instructions may take many cycles to complete. This is like putting something into a pipe and waiting for it to come out the other end.
To speed this up, you don't execute multiple instructions at once, you start processing the next instruction before the previous one is done. When instruction A is on step 2, instruction B can be on step 1 because A is no longer using that part of the processor.
This is similar to putting several things into a pipe before the first one comes out the other end. They will all come out close together (e.g. 1 clock cycle) even though each instruction took many clock cycles total. You put in 16 things and they still come out one at a time, but much closer together than if you waited for each one (exactly like the good washing example above) That is pipelining. If your processor was 16 adders (a lot!) "wide" you could put in 16 adds and they would complete at the _same_ time. That's superscalar.
For the curiouser: instruction prefetch is used to keep pipelines busy. Branches are the bane of pipelines because you may have to throw away all the partially finished instructions because you just found out you're going somewhere else. There are ways to deal with that such as branch prediction.
-Kevin
That statement scares me.
If you give people choices, they may make bad choices. I don't believe that makes choice bad.
Freedom has no conscience, but restrictions on freedom do. I think the fault lies with restricting freedom for that reason: someone or some group's motivations to restrict what you can do or say seems more dangerous to me.
I don't think restricting freedom is justified by assuming people are criminals, which is exactly what most of this DRM stuff does. Finally, I don't believe that companies have a right to profit that should be able to trump freedom.
-Kevin
What do you think it is? Beautiful artwork? Lovely poetry? pics of the goatse guy?
-Kevin
try this with request freesite by URI
KSK@images/humor
-Kevin
-Kevin