Omniture gives two different numbers for "Internet Average" for two different customers? That is interesting. The note at the bottom of the operating system report page for my account says "This column contains the average percentage collected from serveral thousand business web sites." The only reason that I can image for differences would be:
They use different collections of "thousands of web sites" for different customers. (everyone gets a few thousand, but no one gets the same group of comparison web sites.)
They are differentiating "business web sites" from other types of web sites. (In which case I'm not sure why we would be in the "business" category and not "news.")
They are lying through their teeth.
If you are interested asking Omniture about the discrepency, feel free to contact me privately.
Actually, there are a lot of companies that will provide Web Analytics, which probably makes things worse rather than better to find a definitive answer for something like "What percentage of people use a mac to surf the web?"
I work for a large news oriented web site and they use Omniture for stats. They claim that the percentage of our users that use Macs is 6.2% and that it is lower than the "Internet Average" of 9.5%. (and in case you buy that line from OSOpinions that the "other" column should count for Macs then 0.6% as "not specified")
NextSTEP was always based on gcc, so it didn't cost them to bundle it with the OS. (well, the only cost was that they discovered that it would require them to release the source for the Objective C front end, but that was a one time cost, not per unit)
Irix didn't have a bundled compiler. It was actually worse than most because the header files (/usr/include) came with the unbundled compiler, so you couldn't easily get a third party replacement like gcc.
In the mid-80's USL's license scheme charged vendors more to sell with a compiler and with troff, so many of them unbundled their compilers. Some of them (those assuming that most of their customers needed a compiler.) paid USL the extra money, got a volume discount, and continued bundling the comiler. Since a good portion of Sun's customers were buying their workstations for things like CAD workstations, passing on USL's price increase wouldn't have made sense.
Ugh. Anyone else notice that I mixed up the text and the links in my message above? (the Iranian Coup link points to the DOJ memo article and vice versa)
Probably not the moderators who marked it as "Informative".
The US government likely has a whole slew of laws about how its citizens should handle classified government documents. (most of them saying "don't") There is very likely nothing in Italian law about how its citizens should handle documents the US has declared classified.
If you are talking about Debian Linux on PPC, you aren't talking about binary compatibility with a many other versions of Unix.
Unix has never been about binary compatibility anyway. It has never had a strict about source compatibility either. In that case, you are right that there are often differences in the members of the Unix OS family, but I wouldn't call getting most unix programs to run on OS X non-trivial. Especially most of the free and open source software that has been ported to Linux.
OS X might be different than Linux, but no more than Linux is different than FreeBSD. Or FreeBSD is different than IRIX. Or IRIX is different than AIX.
Things like autoconf and Metaconfig are designed to gloss over the differences.
What it does isn't so much write out a bunch of code and include a bunch of libraries, but rather what it does is make a live graph objects and then serialize them on save. Starting a nextstep,openstep, cocoa, or gnustep application reconstitutes the serialized object stream from the nib file.
In the interview Daddy, Are we There Yet Alan Kay mentions that he read a paper on Simula in 1966. As he says in the interview much is lost to the programming community because we don't have a good sense of history.
This planet has - or rather had - a problem which was this: most of the people who were living on it were pretty much unhappy most of the time. Many solutions where suggested for this problem, but most of these were largely concerned with the movements of small green pieces of paper, which was odd because on the whole it wasn't the small green pieces of paper that were unhappy. -- Douglas Adams
And then thought that maybe it isn't the Euro notes that are bland and boring.
People will still recognize rotary phones as long as we keep giving toys like the Fisher Price Chatter Phone to our kids. Who can forget that red, white, and blue phone with the googly eyes that moved as it was pulled.
I remember it when I was a kid. I just noticed one in our house, so someone must have bought one for my kids. It would surprise me if it is the only rotary phone my kids have ever seen.
This is where Open Source might be a less effective rallying point than Free Software. Since Open Source encourages practical reasons why someone using software distributed with source ( like the arguments Eric Raymond gives in "The Magic Cauldron" of cost sharing, risk spreading, or the arguments that file formats are open if the code is visible, etc.), they are designed to appeal to companies and organizations that want to reduce cost and risk. Free Software is much more moralistic that computer owners should be able do as they wish with their machines, and anything less than full right to change and redistribute source code is evil.
The Massachusetts state governments IT department doesn't care about open source. What they do care about is that a MS Word document created by one of the users they support can be read by another user. Or by the same user five years later. Or that the documents can be manipulated by other tools (like automatic indexing, automatic taxonomy generation, or even virus scanners.) They used the request for "Open Standards" to solve this particular issue, and to their satisfaction Microsoft licensing changes solve this problem as well
The advantage of the practical arguments for Open Source is that one can find just need to find one of the arguments compelling to come on board. The disadvantage is that you can lose them just as easily by solving that same issue in a closed source manner. The argument for Free Software is much more absolutist, and it may be easier to get someone to join, but you won't lose them nearly as easily.
Sun produces patches in support for Solaris two years after the last ship date, and ends support five years after the last ship date. That has them creating patches for Solaris 7 until next August and phase 2 support for Solaris 2.5.1 ending next September.
Newspapers and other traditional media have worked on moving into the internet advertising space. One example is Classified Ventures, a joint venture of a half dozen media companies is an example. You might know them for their cars.com or Apartments.com products.
You seem to imply that New York Times is doing poorly. That is far from the case. Consider this. You might be far too astute to want to give away all of the information they ask for in their registration form. You are probably also too astute to be their primary market for their advertisers.
I'm sorry, I thought you meant meant the bloat of SOAP over other RPC mechanisms (ONC-RPC, DCE, Java RMI, or even COM and CORBA) and were complaining about constant XML parsing and conversion from UTF-8 to internal data type representation. The complexity of SOAP over XML-RPC is obvious from specs. For an equivalent RPC call I'm not entirely sure that I'd believe that there is much of a difference in the payload size or in the time spent marshalling/unmarshelling the data. Of course with all the extra feature of SOAP, its easy to go and drown yourself in stuff you wouldn't need if it wasn't there.
I'm sure that with each step Microsoft took when warping XML-RPC into SOAP, someone had some sort of problem that they couldn't support adequately with the facilities that existed. A problem no matter how obscure and no matter how much pain it inflicts everyone else. I doubt everyone is going to use every added feature of SOAP, and so you just wind up with SOAP as a wire-level replacement for XML-RPC. I didn't have a strong opinion of Token Ring vs. Ethernet until the marketplace decided. And then once they did, the change all happened underneath my application without my having to do anything.
Not with SOAP, but I have been able to do some useful things with ZOPE and XML-RPC. If you view Zope as essentially a large graph of persistent objects, the URLs of wind up corresponding to a method of a running application. Any request made as a standard HTTP request, spits up the return value of the method. (as perhaps modified by python's str() when it sends it out the stream back to the client.) For Zope's XML-RPC support, it will just automatically marshall the Python return value into an XML-RPC string when it sees the input request is XML-RPC.
Zope doesn't come with SOAP support as standard. There is some work (like the SOAPByCIGNEX module) being done to allow it to be available as an add-on.
Yes, Zope is an application server. Yes, it is written almost entirely in python. Yes, I've seen zope serve web sites that serve millions of hits a day. (well, zope along with Squid for a caching tier.)
The design of Zope is significantly different than the J2EE spec, so if you are looking at things in terms of "what is the Zope equivalent of JNDI?", it will be difficult to see what it has to offer.
I started to write a detailed explanation of Zope development here, but I realized that it was too Zope 2 oriented. I don't have any practical experience with Zope 3 so far. (In fact, what I say below is probably too Zope 2 oriented as well.) I general, Zope revolves around a object database (usually their ZODB product or a relational object mapper.) Persistent objects are mapped to URL space and each object or method of a class are associated with access controls. Zope development is essentially divided up between component developers working on Zope Products components and application designers using Zope through the web facilities to develop ZPT templates and snippets of programability in a restricted subset of python.
I'll accept your criticism about screwing up the return value of read, but I disagree about partial reads. Perl's read is equivalent to C's fread() which will retry from partial reads.
Although the shell version is working in blocks, it will not leave bytes unreplaced at the end. It might perhaps increase the logical size of the file before removes it. (du will report the number of blocks in use, and round a partial block to the next block. The file system will always allocate space in some multiple of a block size, so extending it to the end of the block won't actually increase the disk space allocated to the file.)
And since I'm enumerating what I agree and disagree with, I guess I should add that I agree with the utility of File::Copy. Thank you for it.
Besides a certain sentimental attachment to File::Copy, what is "copy(\*R, \*F) or last;" from the File::Copy module giving you that you can't get from "seek F, 0;print F read S, $size" using the builtin print and read operators?
How about?
#!/bin/sh files=$@ for file in $files; do
set `du $file`;
size=$1
for times in 0 1 2;
do
dd if=/dev/urandom of=$file count=$size conv=notrunc
done
rm $file done
Since they didn't have a voting system of their own at the time, they needed to purchase an existing company or product to get into the market quickly. Once they've made the first sale, they can offer bugfixes or upgrades to their current customers. If they didn't get to the contract, they are going to be purchasing those upgrades from someone else.
OK, if you really couldn't follow it, here my take on what a cliff's notes version of the speech would be. Just like Cliffs Notes, these are intended to be a study aid and not a replacement the original work.
He is admitting that it has been difficult to gauge perl 6 development. He tends to let matters stew internally and come fully formed. His thought process isn't as goal driven as Damain's mind is. Damain is important to the Perl 6 development process.
Larry's health kept him from doing a lot of work on Perl 6. It probably set the project back six months.
Although he is hopeful that these health issues are in the past, the perl development community might consider adding a new golden rule for when Larry no longer working on Perl. The first two are that Larry is always right, and that Larry isn't held to rule number one when he changes his mind. The third rule should be that when Larry is no longer actively maintaining opinions on rules one and two, that past pronouncements should no longer apply. (If Larry ever leaves Perl development, I can't imagine a week would go by without the question "WWLD" being brought up.)
Over the landscape of computer languages, the business landscape seems to be favoring a few aggressive, well funded closed source languages. Perl will need to find its ecological niches to maintain viability.
Although delayed, the Perl 6 language definition is mostly complete, and the Perl 6 interpreter (parrot) is essentially complete. Actual implementations of the perl 6 language should be available in the next year.
Now obviously, my bullet points are leaving out a lot of the information from the speech. One way of looking at things is that Larry is trying to convey a lot less concrete ideas through metaphors and imagery. Another way to look at it would be to consider it "spin" used to obscure the points. The other post that compared this to an SEC filing or a shareholder meeting has a point and if a corporation had to give news like this, there would probably be a lot of work trying to mitigate some of the harsher points that need to be made. In another point of view, this speech is supposed to be a rallying point for Perl developers, and as such is probably best to not just have the bare facts but also the opinions, and non-verbal points of view of the head of the perl development.
Dylan was created in the early 90s. By then other object oriented languages like C++, both Apple, Borland, and maybe even Microsoft at that point had their Object oriented versions of Pascal (Microsoft's was closer to Apple's Object Pascal. Borland made their object model compatible with C++) Also consider that the Gang of Four's book Design Patterns was out around that time. (There is a brief mention of Dylan in the book.)
What made Dylan stand out was an object model that was closer to CLOS, with generics and multiple dispatch. It also was a dynamic language that could compile into something as efficient as C. (between type narrowing that could give hints to the compiler, and implicit typing that could determine how a type was used, it could often optimize out most of the dynamic behavior into a simple subroutine call.) The developers of Dylan were also interested in making the language work well within a Hypercode IDE envionment, where the code was kept in a cross-referenced database.
If you are interested in hints of where Dylan was going, there is a free software project called Gwidion Dylan that has implemented a subset of the language and environment.
The original NeXT system, like the Macintosh, needed to be supplied with its own hardware platform because it was impossible to get the appropriate features and performance out of commodity hardware at the time. Originally NeXT sold exclusively to the academic market. It fit their requirements for a 3M machine (a megabyte of memory, a megapixel display, and a megaflop rating of processor performance) It was priced competitively to workstation offerings from Sun, HP, and others.
Be also made novel hardware for the time. Hardware that showed off the advantages of BeOS far greater than commodity hardware could at the time. (What great gains can a thoroughly low latency multithreaded OS show without dual processors to exercise it.) Although I don't think the realized it at the time, managed to find themselves in a quirk of pricing that made component prices low enough that they could affordably build a machine. BeBoxes used Motorola two 603 processors for their dual processor system. This was the first PPC chip that Motorola designed and manufactured on their own. (the 601 was mostly IBM's work.) During the design and manufacture of of Apple's first 603 systems, they found that the cache design of the 603 was entirely insufficient to run their 68k emulator that was originally written on the 601. (the 601's unified 16K cache could keep most of the emulator cached, the 603's separate 8D+8I cache could not.) Motorola fixed Apple's problem quickly by producing the 603e, which bumped things to 16D+16I, but that left a glut on the market of the smaller, cheaper 603s. You could buy two 603s for the same price as a 603e, which made the business case for building a dual proessor 603 system. Eventually, the processor market rectified itself and Be's manufacturing costs made it unviable to continue to make their own hardware.
Slashdot Mirror
If you are interested asking Omniture about the discrepency, feel free to contact me privately.
Do you mean someone like Nielson//NetRatings?
Actually, there are a lot of companies that will provide Web Analytics, which probably makes things worse rather than better to find a definitive answer for something like "What percentage of people use a mac to surf the web?"
Last Febuary, Infoworld did a review of some of the major web analytics providers, Coremetrics, NetIQ, Omniture, and WebSideStoryI work for a large news oriented web site and they use Omniture for stats. They claim that the percentage of our users that use Macs is 6.2% and that it is lower than the "Internet Average" of 9.5%. (and in case you buy that line from OSOpinions that the "other" column should count for Macs then 0.6% as "not specified")
NextSTEP was always based on gcc, so it didn't cost them to bundle it with the OS. (well, the only cost was that they discovered that it would require them to release the source for the Objective C front end, but that was a one time cost, not per unit)
Irix didn't have a bundled compiler. It was actually worse than most because the header files (/usr/include) came with the unbundled compiler, so you couldn't easily get a third party replacement like gcc.
In the mid-80's USL's license scheme charged vendors more to sell with a compiler and with troff, so many of them unbundled their compilers. Some of them (those assuming that most of their customers needed a compiler.) paid USL the extra money, got a volume discount, and continued bundling the comiler. Since a good portion of Sun's customers were buying their workstations for things like CAD workstations, passing on USL's price increase wouldn't have made sense.
Ugh. Anyone else notice that I mixed up the text and the links in my message above? (the Iranian Coup link points to the DOJ memo article and vice versa)
Probably not the moderators who marked it as "Informative".
There were at least two publicized incidents Memory Hole Un-Redacts Redacted DOJ Memo and Iranian Coup Plotters Exposed By PDF File were the PDF was discovered to be layered with the graphic blacking out the text over the original.
You would think by now that the government would either distributed a tool for correctly redacting PDFs or prohibit them.
The US government likely has a whole slew of laws about how its citizens should handle classified government documents. (most of them saying "don't") There is very likely nothing in Italian law about how its citizens should handle documents the US has declared classified.
If you are talking about Debian Linux on PPC, you aren't talking about binary compatibility with a many other versions of Unix. Unix has never been about binary compatibility anyway. It has never had a strict about source compatibility either. In that case, you are right that there are often differences in the members of the Unix OS family, but I wouldn't call getting most unix programs to run on OS X non-trivial. Especially most of the free and open source software that has been ported to Linux. OS X might be different than Linux, but no more than Linux is different than FreeBSD. Or FreeBSD is different than IRIX. Or IRIX is different than AIX. Things like autoconf and Metaconfig are designed to gloss over the differences.
What it does isn't so much write out a bunch of code and include a bunch of libraries, but rather what it does is make a live graph objects and then serialize them on save. Starting a nextstep,openstep, cocoa, or gnustep application reconstitutes the serialized object stream from the nib file.
In the interview Daddy, Are we There Yet Alan Kay mentions that he read a paper on Simula in 1966. As he says in the interview much is lost to the programming community because we don't have a good sense of history.
People will still recognize rotary phones as long as we keep giving toys like the Fisher Price Chatter Phone to our kids. Who can forget that red, white, and blue phone with the googly eyes that moved as it was pulled.
I remember it when I was a kid. I just noticed one in our house, so someone must have bought one for my kids. It would surprise me if it is the only rotary phone my kids have ever seen.
This is where Open Source might be a less effective rallying point than Free Software. Since Open Source encourages practical reasons why someone using software distributed with source ( like the arguments Eric Raymond gives in "The Magic Cauldron" of cost sharing, risk spreading, or the arguments that file formats are open if the code is visible, etc.), they are designed to appeal to companies and organizations that want to reduce cost and risk. Free Software is much more moralistic that computer owners should be able do as they wish with their machines, and anything less than full right to change and redistribute source code is evil.
The Massachusetts state governments IT department doesn't care about open source. What they do care about is that a MS Word document created by one of the users they support can be read by another user. Or by the same user five years later. Or that the documents can be manipulated by other tools (like automatic indexing, automatic taxonomy generation, or even virus scanners.) They used the request for "Open Standards" to solve this particular issue, and to their satisfaction Microsoft licensing changes solve this problem as well
The advantage of the practical arguments for Open Source is that one can find just need to find one of the arguments compelling to come on board. The disadvantage is that you can lose them just as easily by solving that same issue in a closed source manner. The argument for Free Software is much more absolutist, and it may be easier to get someone to join, but you won't lose them nearly as easily.
Sun produces patches in support for Solaris two years after the last ship date, and ends support five years after the last ship date. That has them creating patches for Solaris 7 until next August and phase 2 support for Solaris 2.5.1 ending next September.
Newspapers and other traditional media have worked on moving into the internet advertising space. One example is Classified Ventures, a joint venture of a half dozen media companies is an example. You might know them for their cars.com or Apartments.com products.
You seem to imply that New York Times is doing poorly. That is far from the case. Consider this. You might be far too astute to want to give away all of the information they ask for in their registration form. You are probably also too astute to be their primary market for their advertisers.
I'm sorry, I thought you meant meant the bloat of SOAP over other RPC mechanisms (ONC-RPC, DCE, Java RMI, or even COM and CORBA) and were complaining about constant XML parsing and conversion from UTF-8 to internal data type representation. The complexity of SOAP over XML-RPC is obvious from specs. For an equivalent RPC call I'm not entirely sure that I'd believe that there is much of a difference in the payload size or in the time spent marshalling/unmarshelling the data. Of course with all the extra feature of SOAP, its easy to go and drown yourself in stuff you wouldn't need if it wasn't there.
I'm sure that with each step Microsoft took when warping XML-RPC into SOAP, someone had some sort of problem that they couldn't support adequately with the facilities that existed. A problem no matter how obscure and no matter how much pain it inflicts everyone else. I doubt everyone is going to use every added feature of SOAP, and so you just wind up with SOAP as a wire-level replacement for XML-RPC. I didn't have a strong opinion of Token Ring vs. Ethernet until the marketplace decided. And then once they did, the change all happened underneath my application without my having to do anything.
Not with SOAP, but I have been able to do some useful things with ZOPE and XML-RPC. If you view Zope as essentially a large graph of persistent objects, the URLs of wind up corresponding to a method of a running application. Any request made as a standard HTTP request, spits up the return value of the method. (as perhaps modified by python's str() when it sends it out the stream back to the client.) For Zope's XML-RPC support, it will just automatically marshall the Python return value into an XML-RPC string when it sees the input request is XML-RPC.
Zope doesn't come with SOAP support as standard. There is some work (like the SOAPByCIGNEX module) being done to allow it to be available as an add-on.
There was a recent discussion about it on the Zope-dev mailing list.
Yes, Zope is an application server. Yes, it is written almost entirely in python. Yes, I've seen zope serve web sites that serve millions of hits a day. (well, zope along with Squid for a caching tier.)
The design of Zope is significantly different than the J2EE spec, so if you are looking at things in terms of "what is the Zope equivalent of JNDI?", it will be difficult to see what it has to offer.
I started to write a detailed explanation of Zope development here, but I realized that it was too Zope 2 oriented. I don't have any practical experience with Zope 3 so far. (In fact, what I say below is probably too Zope 2 oriented as well.) I general, Zope revolves around a object database (usually their ZODB product or a relational object mapper.) Persistent objects are mapped to URL space and each object or method of a class are associated with access controls. Zope development is essentially divided up between component developers working on Zope Products components and application designers using Zope through the web facilities to develop ZPT templates and snippets of programability in a restricted subset of python.
I'll accept your criticism about screwing up the return value of read, but I disagree about partial reads. Perl's read is equivalent to C's fread() which will retry from partial reads.
Although the shell version is working in blocks, it will not leave bytes unreplaced at the end. It might perhaps increase the logical size of the file before removes it. (du will report the number of blocks in use, and round a partial block to the next block. The file system will always allocate space in some multiple of a block size, so extending it to the end of the block won't actually increase the disk space allocated to the file.)
And since I'm enumerating what I agree and disagree with, I guess I should add that I agree with the utility of File::Copy. Thank you for it.
Besides a certain sentimental attachment to File::Copy, what is "copy(\*R, \*F) or last;" from the File::Copy module giving you that you can't get from "seek F, 0;print F read S, $size" using the builtin print and read operators?
How about?
#!/bin/sh
files=$@
for file in $files;
do
set `du $file`;
size=$1
for times in 0 1 2;
do
dd if=/dev/urandom of=$file count=$size conv=notrunc
done
rm $file
done
Diebold didn't create the GEMS election system themselves. They bought the company Global Election Systems in 2002 in hopes to make money Congress was throwing around with the Help America Vote Act of 2001
Since they didn't have a voting system of their own at the time, they needed to purchase an existing company or product to get into the market quickly. Once they've made the first sale, they can offer bugfixes or upgrades to their current customers. If they didn't get to the contract, they are going to be purchasing those upgrades from someone else.
Now obviously, my bullet points are leaving out a lot of the information from the speech. One way of looking at things is that Larry is trying to convey a lot less concrete ideas through metaphors and imagery. Another way to look at it would be to consider it "spin" used to obscure the points. The other post that compared this to an SEC filing or a shareholder meeting has a point and if a corporation had to give news like this, there would probably be a lot of work trying to mitigate some of the harsher points that need to be made. In another point of view, this speech is supposed to be a rallying point for Perl developers, and as such is probably best to not just have the bare facts but also the opinions, and non-verbal points of view of the head of the perl development.
Dylan was created in the early 90s. By then other object oriented languages like C++, both Apple, Borland, and maybe even Microsoft at that point had their Object oriented versions of Pascal (Microsoft's was closer to Apple's Object Pascal. Borland made their object model compatible with C++) Also consider that the Gang of Four's book Design Patterns was out around that time. (There is a brief mention of Dylan in the book.)
What made Dylan stand out was an object model that was closer to CLOS, with generics and multiple dispatch. It also was a dynamic language that could compile into something as efficient as C. (between type narrowing that could give hints to the compiler, and implicit typing that could determine how a type was used, it could often optimize out most of the dynamic behavior into a simple subroutine call.) The developers of Dylan were also interested in making the language work well within a Hypercode IDE envionment, where the code was kept in a cross-referenced database.
If you are interested in hints of where Dylan was going, there is a free software project called Gwidion Dylan that has implemented a subset of the language and environment.
The original NeXT system, like the Macintosh, needed to be supplied with its own hardware platform because it was impossible to get the appropriate features and performance out of commodity hardware at the time. Originally NeXT sold exclusively to the academic market. It fit their requirements for a 3M machine (a megabyte of memory, a megapixel display, and a megaflop rating of processor performance) It was priced competitively to workstation offerings from Sun, HP, and others.
Be also made novel hardware for the time. Hardware that showed off the advantages of BeOS far greater than commodity hardware could at the time. (What great gains can a thoroughly low latency multithreaded OS show without dual processors to exercise it.) Although I don't think the realized it at the time, managed to find themselves in a quirk of pricing that made component prices low enough that they could affordably build a machine. BeBoxes used Motorola two 603 processors for their dual processor system. This was the first PPC chip that Motorola designed and manufactured on their own. (the 601 was mostly IBM's work.) During the design and manufacture of of Apple's first 603 systems, they found that the cache design of the 603 was entirely insufficient to run their 68k emulator that was originally written on the 601. (the 601's unified 16K cache could keep most of the emulator cached, the 603's separate 8D+8I cache could not.) Motorola fixed Apple's problem quickly by producing the 603e, which bumped things to 16D+16I, but that left a glut on the market of the smaller, cheaper 603s. You could buy two 603s for the same price as a 603e, which made the business case for building a dual proessor 603 system. Eventually, the processor market rectified itself and Be's manufacturing costs made it unviable to continue to make their own hardware.
This topic is probably so old that no one is reading it any more, but I just came across an old note that I left to myself about this document summarizing the differences between POSIX and LSB