Seriously, insofar as he's doing this to get work done or make some contribution, well OK, but he also crows loudly about running all over the world just for fun. Is this something we want to celebrate?
An anonymous warehouse in Richmond, CA is the new Library at Alexandria. Is this progress?
Anyway, kudos to Brewster Kahle for doing something very, very important.
It really depends on the individuals and what you're trying to do, but too many organizations fool themselves into thinking: this virtual team stuff better be cheap and not involve much travel, because I'm counting on it being cheap. For some teams, what you'll gain spending full days in the same place together regularly, including going to meals, etc., will be tremendously more valuable than what you can ever achieve remotely. For others, where everyone is on the same page and easily understands each other and the job's needs, well fine not so much travel is needed, maybe none.
My point is: don't count on not needing contact just because you don't want to budget for it. If you need it, whether to get your actual group planning right, or to build trust, or just to take the measure of who can do what and work with whom, then something big is likely to be lost of you don't arrange for it. BTW: just sending just a manager doesn't always do it either. Sometimes teams need to really spend time with each other.
And yes, the carbon footprint for travel like this is awful. But then again, that's one of the reasons for building a team that's centralized in the first place. You don't have to tradeoff face-to-face contact for travel time, cost, expense and pollution.
This is an important debate, but Neil McAllister's article suffers from a number of problems. For example, it references the recently popular Webkit Comparison Table along with Peter-Paul Koch's claim that there is no “WebKit on Mobile”. The article didn't point out that some people like Alex Russel have dug deeper and have found that the facts don't support PPK's conclusions as strongly as one might think. Yes, if you include lots of older devices, there's quite a divergence in Webkit deployments, but what PPK and Neil McAllister don't say is that compatibility is much better on devices that ship recent versions, it's especially good for core features, and it's improving all the time.
McAllister also implies that the mobile Web is in trouble because "On my BlackBerry, JavaScript performance is abysmal". Using that argument, I can prove that Windows will never be successful, because I could in the early days show you PC's that ran it with abysmal performance. The potential of technologies like Javascript needs to be evaluated using the best implementation you can find; that shows what's possible. He does go on to say: "And even when a handset vendor does improve JavaScript performance, as Apple did with iPhone OS 3.0, it's a relative increase." Aren't they all? "You're still dealing with a poky handheld processor (and in Apple's case, one that developers speculate is too feeble for Flash or Java)."
Uh, so now the reason that the HTML and Javascript will fail is that ARM processors are too slow to run Java? What's the connection I'm missing? The fact is, that there are some pretty good AJAX sites for mobile, so we know the ARM processors are good enough to run that Javascript. Try, for example, going to http://www.gmail.com using Safari on your iPhone. Not a usable experience? Even works offline using HTML 5 local storage (not Gears). Also, even if Javascript performance were somehow related to Java performance, I bet the Android folks would like to hear that Java doesn't run right on ARM processors, since the entire upper level infrastructure of Android, including user applications, is built on just that combination (as optimized using the Dalvik VM).
Unfortunately, articles like this can do real damage. Many people who are not expert in these things are struggling to figure out which mobile application development models are going to be workable.
I happen to believe that the Mobile Web will, like the desktop embodiment of the Web, grow as disruptive technologies tend to: from something that's a bit shaky at first to the model that dominates? Why? Because unlike Mr. McAllister, I believe that the underlying processors and system technologies are capable of running it, and the value of a model that is fully cross-platform, can support zero install operation (you might want to install a mapping application to find a restaurant, but you almost surely don't want to install the restaurant's application to read menus or get discount coupons), can also scale to support installable applications (Widgets) and offline operation, is compelling. Furthermore, as has been the case for years, the Web has the unique value of allowing you to link to the over 1 trillion Web pages, without jumping out from some proprietary application container to a Web browser.
Whether I'm right about the likely success of the mobile Web or not, this whole question deserves a much more careful analysis than McAllister's article provides.
Unfortunately, there will be many people who read it and jump to the conclusion that the mobile Web is failing. A shame.
Though not primarily about the code or machine structure, the recently published book "Digital Apollo: Human and Machine in Spaceflight" by David A. Mindell (Amazon) has lots of interesting insights into the design decisions and tradeoffs that led to the Apollo software being discussed here.
In particular, it explores debates that might now seem quaint as to whether computers could be programmed to make the decisions necessary to reliably fly and land a spacecraft, and especially, what the right tradeoffs are between direct human control, fully automatic operation, and intermediate modes in which the computers provide the human with higher level abstractions than the raw hardware.
Ultimately, for the moon landings, it seems to be this intermediate design point that proved compelling: when Armstrong "overrode" the automatic guidance to choose a landing spot, he was not directly controlling each thruster or the main descent rocket; rather, he was instructing a program to reposition the craft, change speeds, etc., and the computer adjusted the various thrusters and engines appropriately.
There's also a quite good discussion of the famous 1202 errors that almost caused an abort, and of how they related to what was then the very novel and robust architecture of the software created by MIT and the Instrumentation Lab.
The book also provides lots of interesting information about scheduling issues (nobody noticed until relatively late in the game that software would be important or difficult), some about hardware architecture (the so-called "ropes" that carried the code in a form that we would think of as ROM today).
Overall, a good book for those interested in details.
There are at least two reasons I didn't move to Vista:
Vista twice trashed an XP system that was dual booting on the same system...I think it got over anxious about updating file system indexes while booting (and I'm sort of picky about running OS's that trash my systems)
Vista wouldn't support the perfectly good Epson Perfection 1200U scanner that I bought some years ago, and for which Epson chose not to release Vista drivers.
Likewise for other devices.
I'm willing to give Microsoft the benefit of the doubt and assume that Win7 solves problem #1. Anyone know whether Win7 will support all those perfectly good devices I have that work just fine on Windows/XP, and that I was supposed to throw out when I installed Vista? If the answer is "no", I'm sticking to XP for a long time (or moving to Mac, for which drivers are indeed available).
I'm curious: if you go traveling and neglect to authorize your machine before leaving the US, do the new rules prevent you from authorizing while on the road, or is it just that you can't buy new songs?
If you can't authorize, that's worse, because it means that not only can't you purchase, you can't even listen to what you've already paid for. Furthermore, it suggests that someone who moves long term is at real risk of losing access to their whole library.
I'm sorry you took the question as biased. As a user of Windows systems at home both home and work, I will be delighted to find out that either a) those who've claimed that Vista DRM brings with it a wide variety of disadvantages are wrong and/or 2) that insofar as there are such disadvantages, Win7 addresses them.
Certainly there have been detailed claims of concerns that would affect not just authors of Vista device drivers, but more indirectly, users who would not be able to connect devices that they own (I.e. because the drivers could not be written or deployed), or who would find features (echo cancellation) missing from the drivers they could get. See for example: http://www.cs.auckland.ac.nz/~pgut001/pubs/vista_cost.html
I'm not claiming that article is accurate or unbiased. On the contrary, I'm asking: if concerns like this were real with respect to Vista, to what extent are they resolved in Win7. If the answer is: the article is incorrect with respect to Vista, then all the better.
By the way, my reason for not having significant direct experience with using Vista device drivers is that on the several occasions I tried Vista, I ran into so many compatibility and integrity problems that I had to back out to XP. I don't think this is the place to go into what those problems were, but I can detail them if you care.
And no, I haven't had the opportunity to write device drivers for Windows. The last time I wrote device drivers was for Unix systems, and it was quite awhile ago.
Is DRM in Win7 interestingly different from DRM in Vista? My impression is that Vista DRM had many ramifications for things like writing and deploying device drivers, etc.
Exactly as spineboy says. Those are the advantages, especially better coverage, no need to recharge batteries every 2nd or 3rd night. I love being able to get back to people when I'm ready. I use skytel. Phone is only on when I'm ready to actually take calls; pager is on all the time.
Like so many others, this article starts from the false premise that Network Neutrality implies unlimited or unmetered access, and then goes on to point out that such a model wouldn't work.
Network neutrality doesn't mandate unlimited access. It doesn't even mandate high volume access. What it does require is that any limits be expressed in terms of unbiased metrics such as the instantaneous bandwidth provided, the packet rate allowed, the guaranteed latency, etc. Network neutrality does imply that my ISP must not discriminate based on other factors, such as that they've got a financial kickback arrangement with Movies R US.
From a network neutrality point of view, there's nothing wrong with my ISP offering a cheap plan with very strict limits, even as low as 100 MBytes per month or 1 MBit/second, as long as those limits are applied independent of which Web resources I'm connecting to, or which protocols I'm using to do it.
Now, if the protocol I choose, say Bittorrent, takes a higher speed connection to perform well, I'll probably want to pay for a faster connection, but then I should have a choice of using any of the protocols that leverage the better connection, and I should be able to connect at the higher rate to my choice of Internet sites.
I've yet to hear why this sort of Network Neutrality is impractical, or why it isn't essential to supporting continued widespread innovation on the Internet.
Indeed. There are a variety of certificate-related hassles with Linksys admin through Firefox 3. Not only do the self-signed certs cause a problem, but it's easy to wind up in a state where Firefox claims that you have a duplicate certificate, and there's no convenient UI for allowing an exception on that. You have to know how to go manage your list of certificates, figure out where the duplicate (listed to Cisco, I think), manually delete it, then try again, then allow for the self-signed certificate exception.
The chances that the typical Linksys owner will succeed in administering it after an upgrade to Firefox 3.0 seem to be near zero. What's worse, few such users need to get to the browser panel more than occasionally. By the time they encounter the error, they might not even associate it with the browser change, and might assume it's a failure in the router.
The router presents a self-signed cert. These routers were easily administered using early versions of Firefox. Now with Firefox 3 there's lots of confusion, with many users falling back to IE.
Turns out the situation is complicated by the fact that you can easily convince FF3 that you've got duplicate certs; to get past that you've got to do some wizard-level magic to get rid of the dups before you even get to wrestle with allowing the exception for the self-signed cert. After all that, you can indeed use FF3 to administer your router. On good days.
Does using https in this case add to security? In practice, I think the answer is, "yes, to a significant degree." I'd rather have the admin traffic to my router encrypted, even if in principle a hacker with perfect timing could have gotten "in the middle" just as I was accepting the cert.
There is a Ramac in the lobby of the IBM Almaden Research Center south of San Jose in California. If for any reason you get to go inside the lab, there is also one of the early experimental engineering testbeds in a hallway, with seek mechanisms, platters, etc. This thing was used to determine whether the technology would work. According to a card sitting next to the testbed, the early experimental coating was the same paint that was being used at the time on the Golden Gate Bridge (apparently contains iron oxide), filtered through women's nylon stockings onto the spinning platter! I wonder who filed the expense accounting for the stockings.
I also notice that the Magnetic Disk Heritage Center claims to be restoring a Ramac and has made progress getting one running.
Yes, only experts tend to do serious upgrades, but many novices call the Geek Squad or some such for for repairs. In fact, it's often the novices who keep their ancient machines limping along for years. Laptops break much more easily, and the custom parts you need to fix them tend to be expensive. When was the last time you broke the case on a desktop (don't answer that!)
Last year I picked up an HP Pavilion A1540N running XP Media Center Edition, which is more or less Windows XP SP2. I was very annoyed to find that when I pressed the sleep button all the fans kept spinning. A bit of rummaging around led me to the control panel for Intel's Viiv Feature, which is intended to turn your PC into a 24x7 media control center. Well, call me a Luddite, but backwards me only wanted an economical PC on which to get my work done, and this high power, high noise sleep mode wasn't what I had in mind. Turning off Viiv seems to have solved "the problem". Sleep works fine now, and so does hibernate.
Anyway, the Viiv stuff was my main problem. You wonder just how many new power plants get built when companies ship this stuff enabled-by-default to people who don't need it.
The end is delayed a bit: Vonage wins a stay
on
The End for Vonage?
·
· Score: 1
As CNET and others are reporting, an Federal Appeals Court has issued a ruling allowing Vonage to continue adding new customers, at least until they get to hear further arguments. So, while all this can't be good for Vonage, they are at least allowed to go after new customers for now. Whether that will prove easy in the current climate is a different question.
FWIW, I am a very satisfied Vonage customer and also a moderately satisfied Verizon Wireless customer. Like some other commentators on this list, Verizon's actions in this case make me significantly less likely to renew my contract with them when the time comes. Now if Verizon were using those patents of theirs to offer a better and more economical VOIP service, that would be interesting to me as a customer. Just getting questionnably broad patents and using them to prevent others from providing valuable service does not make me a happy customer.
I think you're suggesting that for certain kinds of optimization it's as important to know about machine architecture and organization, I.e. things like cache associativity and size, relative speed of memory vs. registers vs. cache, etc., as it is to know or optimize the use of particular "assembler" (actually machine) language instructions. Good point. Still, if you want to know how many memory accesses either the presupplied strcat or your own alternative are going to issue, and which addresses they're going to hit, knowing machine language is a big help.
So typical. An average mind responsible for something that everyone used just because it was all that was out there.
Well, I wouldn't be at all surprised that the browser you're using and the operating system it's running on were compiled using optimizers that are the direct descendants of Backus' original FORTRAN compilers. As discussed in my post above, those optimizers were the real point of the FORTRAN project. Remember also that FORTRAN was designed in 1954, when the alternative was assembler or machine language. Backus was ahead of the industry in realizing what high level languages could do, and later ahead of the industry in recognizing that his own FORTRAN was not a good long term design point; as others have noted, he devoted the latter part of his professional career to promoting functional languages. There too, he was years or even decades ahead of, not behind the curve. Did you know John personally? I did, at least a bit. He was neither an average mind nor an average person.
When I was in my early 20s and had been programming only a few years, and John was already a legend and IBM Fellow for his work on FORTRAN, I had the pleasure of meeting him informally a few times. You would have thought our positions and experiences were nearly the same. He was always as engaged and delighted with younger people like me as with other giants of the computer field, some of whom were standing right with us at those get togethers (Jim Gray comes to mind). John was extraordinarily decent, kind, and down-to-earth, and he will be very much missed.
I think some of the wise guys/gals on this list are missing the point of the FORTRAN team's contributions. It wasn't that FORTRAN was the perfect language. To some degree, that wasn't even the goal. Quoting from an an article by Backus (full text is available only to ACM subscribers, unfortunately):
"To this day I believe that our emphasis on object program efficiency rather than on language design was basically correct. I believe that had we failed to produce efficient programs, the widespread use of languages like FORTRAN would have been seriously delayed.".
At the time the FORTRAN work was done, people didn't believe that a compiler could produce code that was fast enough. If you go back to the early references on FORTRAN you'll find that they implemented optimizations that were still considered sophisticated 15 years later. The difference is: the FORTRAN team did it at a time when nobody had done it before. Furthermore, they did it on an IBM 704 that would be too weak (if not too small!) to power a wrist watch today. Its core storage units were tens of cubic feet in size, and each held 4K 36 bit words, or just over 32K bytes in modern terms. Even the "high speed" drum storage units (like a disk, but with no seeking needed) held only 16K of those 36 bit words. On this machine, they built optimizations that were considered sophisticated even decades later, when machines had gotten much bigger and faster. Quoting from that same article:
"It is beyond the scope of this paper to go into the details of the analysis which section 2 [I.e. the optimizer] carried out. It will suffice to say that it produced code of such efficiency that its output would startle the programmers who studied it. It moved code out of loops where that was possible; it took advantage of the differences between rowwise and column-wise scans; it took note of special cases to optimize even the exits from loops. The degree of optimization performed by section 2 in its treatment of indexing, array references, and loops was not equalled again until optimizing compilers began to appear in the middle and late sixties."
The computing field has lost someone very special.
The W3C's technical architecture group (TAG) has published a document exploring the tradeoffs in creating Web content using imperative languages, such as JavaScript, vs. declarative languages such as HTML. See The Rule of Least Power, edited by Tim Berners-Lee and Noah Mendelsohn (yours truly).
From that document:
"There is an important tradeoff between the computational power of a language and the ability to determine what a program in that language is doing...
Good Practice: Use the least powerful language suitable for expressing information, constraints or programs on the World Wide Web." If you're interested, I suggest you read the whole document, which is quite short, and which discusses a number of related issues.
While it's not impossible that Google or other search engines would use some heuristic to extract information from the JavaScript source, actually running the program would involve many complexities, some of which have been mentioned by other commentors. Not the least of these relates to the famous halting problem. As paraphrased for the purposes of the TAG finding:
"The tradeoff for such power is that you typically cannot determine what a program in a Turing-complete language [I.e. such as JavaScript] will do without actually running it. Indeed, you often cannot tell in advance whether such a program will even reach the point of producing useful output. Of course, you can easily tell what a simple program such as print "2+2" will do, but given an arbitrary program you'd likely have to run it, and possibly for a very long time. Conversely, if you capture information in a simple declarative form, anyone can write a program to analyze it in many ways."
If one of the two will give you a chance to learn more than the other, I'd consider that pretty seriously. In the long run, you'll probably have a more successful career and (if you care, a more prosperous career) by taking jobs where you'll work with the brightest most interesting people, and where you'll have the greatest chance to learn about useful technologies, business techniques, or whatever gets you up in the morning.
> Some textbooks gain a reputation for being stunningly good, while others > gain a reputation for being awful. I think that once the dust settles > and wiki-enabled textbooks are recognized as a valid alternative, > we'll end up with the same situation.
Good point.
> I think the worst part of this whole discussion has been the implicit assumption > that 'wikified' means 'zero control over what the book says.'The people > running the project can still decide things like who is allowed > to contribute, what sort of approval is required before a change is accepted, > and what sort of guidelines determine when a book has hit '1.0'.
Indeed. I think it's unfortunate that these folks didn't get further in doing just such reviews of their first book before holding it up as a model for what's possible with wiki-based authoring. I agree that wikis may be a wonderful and exciting new way of writing excellent books. It's just disappointing to see a book with such a serious and obvious error used as an early example of what's possible. I think that with care one can do much better.
"A new initiative spearheaded by a University of Georgia professor aims to produce a library of 1,000 wiki textbooks by tapping the collaborative power of wiki. Inspiration for the project came from a computer science course that wrote its own textbook on XML"
A very cool idea in principle, but if the XML book they've done is typical, they should stop now. Just for grins, I opened to a subject I know quite well, which is XML and Schemas. There we find:
"Entities are basically the objects a Schema is created to represent. As stated before, they have attributes and relationships. We will now go much further into explaining exactly what they are and how to write code for them.
There are two types of Entities: simpleType and complexType. "
Well no. That's about as wrong as you can be. The term "entity" in XML has a rather precisely defined meaning and it has very little to do with simpleTypes or complexTypes.
Entities are a really fundamental concept in XML. While it's no doubt tempting to someone who views the world in entity/relation terms to use "entity" in that sense (which I suspect is what the author had in mind), that's no excuse for writing textbooks that are wrong. Whoever wrote this section obviously didn't have a student's much less a textbook author's grasp of XML details.
As it stands, this example suggests that wikibooks are at risk of producing some strikingly inaccurate teaching materials, and that's very troubling.
Looks like some much for serious fact checking will be needed if books like this are to to more good than harm. Too bad, because the idea of wikibooks does seem very appealing.
Slashdot Mirror
Seriously, insofar as he's doing this to get work done or make some contribution, well OK, but he also crows loudly about running all over the world just for fun. Is this something we want to celebrate?
An anonymous warehouse in Richmond, CA is the new Library at Alexandria. Is this progress? Anyway, kudos to Brewster Kahle for doing something very, very important.
Seriously.
It really depends on the individuals and what you're trying to do, but too many organizations fool themselves into thinking: this virtual team stuff better be cheap and not involve much travel, because I'm counting on it being cheap. For some teams, what you'll gain spending full days in the same place together regularly, including going to meals, etc., will be tremendously more valuable than what you can ever achieve remotely. For others, where everyone is on the same page and easily understands each other and the job's needs, well fine not so much travel is needed, maybe none.
My point is: don't count on not needing contact just because you don't want to budget for it. If you need it, whether to get your actual group planning right, or to build trust, or just to take the measure of who can do what and work with whom, then something big is likely to be lost of you don't arrange for it. BTW: just sending just a manager doesn't always do it either. Sometimes teams need to really spend time with each other.
And yes, the carbon footprint for travel like this is awful. But then again, that's one of the reasons for building a team that's centralized in the first place. You don't have to tradeoff face-to-face contact for travel time, cost, expense and pollution.
This is an important debate, but Neil McAllister's article suffers from a number of problems. For example, it references the recently popular Webkit Comparison Table along with Peter-Paul Koch's claim that there is no “WebKit on Mobile”. The article didn't point out that some people like Alex Russel have dug deeper and have found that the facts don't support PPK's conclusions as strongly as one might think. Yes, if you include lots of older devices, there's quite a divergence in Webkit deployments, but what PPK and Neil McAllister don't say is that compatibility is much better on devices that ship recent versions, it's especially good for core features, and it's improving all the time.
McAllister also implies that the mobile Web is in trouble because "On my BlackBerry, JavaScript performance is abysmal". Using that argument, I can prove that Windows will never be successful, because I could in the early days show you PC's that ran it with abysmal performance. The potential of technologies like Javascript needs to be evaluated using the best implementation you can find; that shows what's possible. He does go on to say: "And even when a handset vendor does improve JavaScript performance, as Apple did with iPhone OS 3.0, it's a relative increase." Aren't they all? "You're still dealing with a poky handheld processor (and in Apple's case, one that developers speculate is too feeble for Flash or Java)." Uh, so now the reason that the HTML and Javascript will fail is that ARM processors are too slow to run Java? What's the connection I'm missing? The fact is, that there are some pretty good AJAX sites for mobile, so we know the ARM processors are good enough to run that Javascript. Try, for example, going to http://www.gmail.com using Safari on your iPhone. Not a usable experience? Even works offline using HTML 5 local storage (not Gears). Also, even if Javascript performance were somehow related to Java performance, I bet the Android folks would like to hear that Java doesn't run right on ARM processors, since the entire upper level infrastructure of Android, including user applications, is built on just that combination (as optimized using the Dalvik VM).
Unfortunately, articles like this can do real damage. Many people who are not expert in these things are struggling to figure out which mobile application development models are going to be workable. I happen to believe that the Mobile Web will, like the desktop embodiment of the Web, grow as disruptive technologies tend to: from something that's a bit shaky at first to the model that dominates? Why? Because unlike Mr. McAllister, I believe that the underlying processors and system technologies are capable of running it, and the value of a model that is fully cross-platform, can support zero install operation (you might want to install a mapping application to find a restaurant, but you almost surely don't want to install the restaurant's application to read menus or get discount coupons), can also scale to support installable applications (Widgets) and offline operation, is compelling. Furthermore, as has been the case for years, the Web has the unique value of allowing you to link to the over 1 trillion Web pages, without jumping out from some proprietary application container to a Web browser. Whether I'm right about the likely success of the mobile Web or not, this whole question deserves a much more careful analysis than McAllister's article provides. Unfortunately, there will be many people who read it and jump to the conclusion that the mobile Web is failing. A shame.
Where is MVC when you need it???
At the server.
Though not primarily about the code or machine structure, the recently published book "Digital Apollo: Human and Machine in Spaceflight" by David A. Mindell (Amazon) has lots of interesting insights into the design decisions and tradeoffs that led to the Apollo software being discussed here.
In particular, it explores debates that might now seem quaint as to whether computers could be programmed to make the decisions necessary to reliably fly and land a spacecraft, and especially, what the right tradeoffs are between direct human control, fully automatic operation, and intermediate modes in which the computers provide the human with higher level abstractions than the raw hardware. Ultimately, for the moon landings, it seems to be this intermediate design point that proved compelling: when Armstrong "overrode" the automatic guidance to choose a landing spot, he was not directly controlling each thruster or the main descent rocket; rather, he was instructing a program to reposition the craft, change speeds, etc., and the computer adjusted the various thrusters and engines appropriately.
There's also a quite good discussion of the famous 1202 errors that almost caused an abort, and of how they related to what was then the very novel and robust architecture of the software created by MIT and the Instrumentation Lab. The book also provides lots of interesting information about scheduling issues (nobody noticed until relatively late in the game that software would be important or difficult), some about hardware architecture (the so-called "ropes" that carried the code in a form that we would think of as ROM today). Overall, a good book for those interested in details.
There are at least two reasons I didn't move to Vista:
I'm willing to give Microsoft the benefit of the doubt and assume that Win7 solves problem #1. Anyone know whether Win7 will support all those perfectly good devices I have that work just fine on Windows/XP, and that I was supposed to throw out when I installed Vista? If the answer is "no", I'm sticking to XP for a long time (or moving to Mac, for which drivers are indeed available).
I'm curious: if you go traveling and neglect to authorize your machine before leaving the US, do the new rules prevent you from authorizing while on the road, or is it just that you can't buy new songs?
If you can't authorize, that's worse, because it means that not only can't you purchase, you can't even listen to what you've already paid for. Furthermore, it suggests that someone who moves long term is at real risk of losing access to their whole library.
I'm sorry you took the question as biased. As a user of Windows systems at home both home and work, I will be delighted to find out that either a) those who've claimed that Vista DRM brings with it a wide variety of disadvantages are wrong and/or 2) that insofar as there are such disadvantages, Win7 addresses them.
Certainly there have been detailed claims of concerns that would affect not just authors of Vista device drivers, but more indirectly, users who would not be able to connect devices that they own (I.e. because the drivers could not be written or deployed), or who would find features (echo cancellation) missing from the drivers they could get. See for example: http://www.cs.auckland.ac.nz/~pgut001/pubs/vista_cost.html I'm not claiming that article is accurate or unbiased. On the contrary, I'm asking: if concerns like this were real with respect to Vista, to what extent are they resolved in Win7. If the answer is: the article is incorrect with respect to Vista, then all the better.
By the way, my reason for not having significant direct experience with using Vista device drivers is that on the several occasions I tried Vista, I ran into so many compatibility and integrity problems that I had to back out to XP. I don't think this is the place to go into what those problems were, but I can detail them if you care.
And no, I haven't had the opportunity to write device drivers for Windows. The last time I wrote device drivers was for Unix systems, and it was quite awhile ago.
Thank you.
Is DRM in Win7 interestingly different from DRM in Vista? My impression is that Vista DRM had many ramifications for things like writing and deploying device drivers, etc.
Exactly as spineboy says. Those are the advantages, especially better coverage, no need to recharge batteries every 2nd or 3rd night. I love being able to get back to people when I'm ready. I use skytel. Phone is only on when I'm ready to actually take calls; pager is on all the time.
Like so many others, this article starts from the false premise that Network Neutrality implies unlimited or unmetered access, and then goes on to point out that such a model wouldn't work.
Network neutrality doesn't mandate unlimited access. It doesn't even mandate high volume access. What it does require is that any limits be expressed in terms of unbiased metrics such as the instantaneous bandwidth provided, the packet rate allowed, the guaranteed latency, etc. Network neutrality does imply that my ISP must not discriminate based on other factors, such as that they've got a financial kickback arrangement with Movies R US.
From a network neutrality point of view, there's nothing wrong with my ISP offering a cheap plan with very strict limits, even as low as 100 MBytes per month or 1 MBit/second, as long as those limits are applied independent of which Web resources I'm connecting to, or which protocols I'm using to do it.
Now, if the protocol I choose, say Bittorrent, takes a higher speed connection to perform well, I'll probably want to pay for a faster connection, but then I should have a choice of using any of the protocols that leverage the better connection, and I should be able to connect at the higher rate to my choice of Internet sites. I've yet to hear why this sort of Network Neutrality is impractical, or why it isn't essential to supporting continued widespread innovation on the Internet.
Indeed. There are a variety of certificate-related hassles with Linksys admin through Firefox 3. Not only do the self-signed certs cause a problem, but it's easy to wind up in a state where Firefox claims that you have a duplicate certificate, and there's no convenient UI for allowing an exception on that. You have to know how to go manage your list of certificates, figure out where the duplicate (listed to Cisco, I think), manually delete it, then try again, then allow for the self-signed certificate exception.
The chances that the typical Linksys owner will succeed in administering it after an upgrade to Firefox 3.0 seem to be near zero. What's worse, few such users need to get to the browser panel more than occasionally. By the time they encounter the error, they might not even associate it with the browser change, and might assume it's a failure in the router.
So, a big mess for router owners.
Many popular Linksys routers are administered by pointing your browser to an https link, typically:
https://192.168.1.1/
The router presents a self-signed cert. These routers were easily administered using early versions of Firefox. Now with Firefox 3 there's lots of confusion, with many users falling back to IE.
Turns out the situation is complicated by the fact that you can easily convince FF3 that you've got duplicate certs; to get past that you've got to do some wizard-level magic to get rid of the dups before you even get to wrestle with allowing the exception for the self-signed cert. After all that, you can indeed use FF3 to administer your router. On good days.
Does using https in this case add to security? In practice, I think the answer is, "yes, to a significant degree." I'd rather have the admin traffic to my router encrypted, even if in principle a hacker with perfect timing could have gotten "in the middle" just as I was accepting the cert.
Anyway, it's another consideration.
There is a Ramac in the lobby of the IBM Almaden Research Center south of San Jose in California. If for any reason you get to go inside the lab, there is also one of the early experimental engineering testbeds in a hallway, with seek mechanisms, platters, etc. This thing was used to determine whether the technology would work. According to a card sitting next to the testbed, the early experimental coating was the same paint that was being used at the time on the Golden Gate Bridge (apparently contains iron oxide), filtered through women's nylon stockings onto the spinning platter! I wonder who filed the expense accounting for the stockings.
I also notice that the Magnetic Disk Heritage Center claims to be restoring a Ramac and has made progress getting one running.
Yes, only experts tend to do serious upgrades, but many novices call the Geek Squad or some such for for repairs. In fact, it's often the novices who keep their ancient machines limping along for years. Laptops break much more easily, and the custom parts you need to fix them tend to be expensive. When was the last time you broke the case on a desktop (don't answer that!)
Last year I picked up an HP Pavilion A1540N running XP Media Center Edition, which is more or less Windows XP SP2. I was very annoyed to find that when I pressed the sleep button all the fans kept spinning. A bit of rummaging around led me to the control panel for Intel's Viiv Feature, which is intended to turn your PC into a 24x7 media control center. Well, call me a Luddite, but backwards me only wanted an economical PC on which to get my work done, and this high power, high noise sleep mode wasn't what I had in mind. Turning off Viiv seems to have solved "the problem". Sleep works fine now, and so does hibernate.
By the way, somewhere back in this thread someone mentioned a problem hibernating Windows machines with lots of resources (e.g. > 1GB Ram). FWIW, I had good luck applying Microsoft Update KB909095. There is also at the bottom of that page an announcement of another fix that specifically claims to be for hibernating with > 1 GB.
Anyway, the Viiv stuff was my main problem. You wonder just how many new power plants get built when companies ship this stuff enabled-by-default to people who don't need it.
As CNET and others are reporting, an Federal Appeals Court has issued a ruling allowing Vonage to continue adding new customers, at least until they get to hear further arguments. So, while all this can't be good for Vonage, they are at least allowed to go after new customers for now. Whether that will prove easy in the current climate is a different question.
FWIW, I am a very satisfied Vonage customer and also a moderately satisfied Verizon Wireless customer. Like some other commentators on this list, Verizon's actions in this case make me significantly less likely to renew my contract with them when the time comes. Now if Verizon were using those patents of theirs to offer a better and more economical VOIP service, that would be interesting to me as a customer. Just getting questionnably broad patents and using them to prevent others from providing valuable service does not make me a happy customer.
I think you're suggesting that for certain kinds of optimization it's as important to know about machine architecture and organization, I.e. things like cache associativity and size, relative speed of memory vs. registers vs. cache, etc., as it is to know or optimize the use of particular "assembler" (actually machine) language instructions. Good point. Still, if you want to know how many memory accesses either the presupplied strcat or your own alternative are going to issue, and which addresses they're going to hit, knowing machine language is a big help.
Well, I wouldn't be at all surprised that the browser you're using and the operating system it's running on were compiled using optimizers that are the direct descendants of Backus' original FORTRAN compilers. As discussed in my post above, those optimizers were the real point of the FORTRAN project. Remember also that FORTRAN was designed in 1954, when the alternative was assembler or machine language. Backus was ahead of the industry in realizing what high level languages could do, and later ahead of the industry in recognizing that his own FORTRAN was not a good long term design point; as others have noted, he devoted the latter part of his professional career to promoting functional languages. There too, he was years or even decades ahead of, not behind the curve. Did you know John personally? I did, at least a bit. He was neither an average mind nor an average person.
When I was in my early 20s and had been programming only a few years, and John was already a legend and IBM Fellow for his work on FORTRAN, I had the pleasure of meeting him informally a few times. You would have thought our positions and experiences were nearly the same. He was always as engaged and delighted with younger people like me as with other giants of the computer field, some of whom were standing right with us at those get togethers (Jim Gray comes to mind). John was extraordinarily decent, kind, and down-to-earth, and he will be very much missed.
"To this day I believe that our emphasis on object program efficiency rather than on language design was basically correct. I believe that had we failed to produce efficient programs, the widespread use of languages like FORTRAN would have been seriously delayed.".I think some of the wise guys/gals on this list are missing the point of the FORTRAN team's contributions. It wasn't that FORTRAN was the perfect language. To some degree, that wasn't even the goal. Quoting from an an article by Backus (full text is available only to ACM subscribers, unfortunately):
"It is beyond the scope of this paper to go into the details of the analysis which section 2 [I.e. the optimizer] carried out. It will suffice to say that it produced code of such efficiency that its output would startle the programmers who studied it. It moved code out of loops where that was possible; it took advantage of the differences between rowwise and column-wise scans; it took note of special cases to optimize even the exits from loops. The degree of optimization performed by section 2 in its treatment of indexing, array references, and loops was not equalled again until optimizing compilers began to appear in the middle and late sixties."At the time the FORTRAN work was done, people didn't believe that a compiler could produce code that was fast enough. If you go back to the early references on FORTRAN you'll find that they implemented optimizations that were still considered sophisticated 15 years later. The difference is: the FORTRAN team did it at a time when nobody had done it before. Furthermore, they did it on an IBM 704 that would be too weak (if not too small!) to power a wrist watch today. Its core storage units were tens of cubic feet in size, and each held 4K 36 bit words, or just over 32K bytes in modern terms. Even the "high speed" drum storage units (like a disk, but with no seeking needed) held only 16K of those 36 bit words. On this machine, they built optimizations that were considered sophisticated even decades later, when machines had gotten much bigger and faster. Quoting from that same article:
The computing field has lost someone very special.
The W3C's technical architecture group (TAG) has published a document exploring the tradeoffs in creating Web content using imperative languages, such as JavaScript, vs. declarative languages such as HTML. See The Rule of Least Power, edited by Tim Berners-Lee and Noah Mendelsohn (yours truly).
From that document:
"There is an important tradeoff between the computational power of a language and the ability to determine what a program in that language is doingWhile it's not impossible that Google or other search engines would use some heuristic to extract information from the JavaScript source, actually running the program would involve many complexities, some of which have been mentioned by other commentors. Not the least of these relates to the famous halting problem. As paraphrased for the purposes of the TAG finding:
"The tradeoff for such power is that you typically cannot determine what a program in a Turing-complete language [I.e. such as JavaScript] will do without actually running it. Indeed, you often cannot tell in advance whether such a program will even reach the point of producing useful output. Of course, you can easily tell what a simple program such as print "2+2" will do, but given an arbitrary program you'd likely have to run it, and possibly for a very long time. Conversely, if you capture information in a simple declarative form, anyone can write a program to analyze it in many ways."If one of the two will give you a chance to learn more than the other, I'd consider that pretty seriously. In the long run, you'll probably have a more successful career and (if you care, a more prosperous career) by taking jobs where you'll work with the brightest most interesting people, and where you'll have the greatest chance to learn about useful technologies, business techniques, or whatever gets you up in the morning.
An Onerous Coward replied to me:
Good point.
Indeed. I think it's unfortunate that these folks didn't get further in doing just such reviews of their first book before holding it up as a model for what's possible with wiki-based authoring. I agree that wikis may be a wonderful and exciting new way of writing excellent books. It's just disappointing to see a book with such a serious and obvious error used as an early example of what's possible. I think that with care one can do much better.
"A new initiative spearheaded by a University of Georgia professor aims to produce a library of 1,000 wiki textbooks by tapping the collaborative power of wiki. Inspiration for the project came from a computer science course that wrote its own textbook on XML"
A very cool idea in principle, but if the XML book they've done is typical, they should stop now. Just for grins, I opened to a subject I know quite well, which is XML and Schemas. There we find:
"Entities are basically the objects a Schema is created to represent. As stated before, they have attributes and relationships. We will now go much further into explaining exactly what they are and how to write code for them.
There are two types of Entities: simpleType and complexType. "
Well no. That's about as wrong as you can be. The term "entity" in XML has a rather precisely defined meaning and it has very little to do with simpleTypes or complexTypes. Entities are a really fundamental concept in XML. While it's no doubt tempting to someone who views the world in entity/relation terms to use "entity" in that sense (which I suspect is what the author had in mind), that's no excuse for writing textbooks that are wrong. Whoever wrote this section obviously didn't have a student's much less a textbook author's grasp of XML details.
As it stands, this example suggests that wikibooks are at risk of producing some strikingly inaccurate teaching materials, and that's very troubling. Looks like some much for serious fact checking will be needed if books like this are to to more good than harm. Too bad, because the idea of wikibooks does seem very appealing.