I appreciate that high bandwidth is becoming available at a pretty good clip; I enjoy a 3Mbps connection from Comcast right now. But I question whether they have what it takes to deliver a sustained 3Mbps for two hours now. I'm working at home today, browsing my employer's internal Wiki through a VPN connection, and it's great. OTOH, my connection dropped about an hour ago, and it took me 5-10 minutes to notice because the connection was idle while I read downloaded content.
10Mbps for $100/month sounds achievable for bursty usage like web browsing, but a) way more screen-hours (orders of magnitude?) are spent watching television than web browsing; and b) the throughput per screen requirements are way higher.
Scale that connection up to 10-15MBps per television set, at an average of 1-1.5 sets per household active during primetime, and I think Comcast's infrastructure in my town would melt. (Figuratively.) I am not an expert on network infrastructure, but I think a lot of hardware and fiber is called for before it can happen, and when the cost of that gets folded into my cable bill, Netflix is going to look pretty good.
Given his position (as opposed to his actual track record), I would expect better ideas from Bill.
Yeah, video on demand is here, but IMHO, it's a step down. I'm using Comcast's service; the choice is limited, and the interface is clumsy (few features, not very responsive.
To me, the math is simple: local storage will always have an advantage over real-time transmission from a central repository, especially as the demand on bandwidth grows. The notion of the network delivering increasingly high-quality content in real time to every possible endpoint is absurd; the cost of the infrastructure to support the bandwidth will be prohibitive.
Which is not to say that Blockbuster and/or Netflix are the last words in media delivery.
Here's my proposal: blend DVR's with near-real-time delivery. Very little media has to be delivered in real time: sporting events, breaking news, maybe (God help us) those final climactic moments on reality shows. Almost everything else could be moved to a subscription model.
Watch "Star Trek" or "24"? Subscribe to the series, and new episodes are delivered to and stored on your set-top as they become available; maybe you get a discount if you're willing to receive the content some time after it's initially available. That's pretty much what I do with my DVR now; I rarely watch a show in real-time, even if I choose to watch it the same day it's broadcast.
Want to watch a movie? Is it such an inconvenience to decide that you're going to want to see a movie this weekend, and queue it up slightly in advance? For those willing to plan ahead, the content providers can balance the load (think Bit Torrent with DRM [sorry]) and preserve bandwidth. The latency doesn't even have to be the total download time; we can already start to view content (streaming media or DVR'd television) before the transmission is complete.
For the really impulsive, the system can be designed to (try to) meet your needs immediately, but genuine "on demand" consumption of a lot of bandwidth is likely to come at additional cost.
It's really the end of the network model (i.e., it would be possible to subscribe to a TV series (or a movie, or a concert, etc.) directly from the producer, without suffering the whims of network schedulers), but that handwriting has been on the wall for a while now.
Oh, getting back on topic: there is a place in all this for those silver discs (or their 2014 equivalent) to save stuff we really care about and free up the hard drive space (or its 2014 equivalent) inside the DVR (or its 2014 equivalent).
Bill has never been one to think outside the box, but I think his box is getting smaller lately...
They did not use the sun's gravitational pull; they used the gravity fields of Venus (twice), Earth, and Jupiter to overcome the sun's gravitational pull.
The "risk" of a Columbia/Challenger type accident - breaking apart from a launch vehicle failure or atmospheric stresses - had nothing to do with the slingshot trajectory, and the RTG was packaged against that contingency. The risk of the slingshot maneuver around earth leading to an accident was infinitesimal.
As the linked article discusses at greater length, the wisdom of the plan was disputed by some, but calling it "very dangerous" is getting close to tin foil hat territory.
Although somebody has pointed out that they did qualify it as the closest approach during the 4-year planned mission, note that Galileo survived 6 years beyond its 2-year planned orbital mission, and sent back data even as they intentionally crashed it into Jupiter to keep if from possibly contaminating one of Jupiter's moons in the future. I wouldn't be surprised if a similar fate is in store for Cassini-Huygens: both a significantly extended mission, followed by a controlled "disposal" when its usefulness has been wrung dry.
IIRC, the first NASA rockets were invented by the German scientist who invented rockets, so, it's just happening again decades later.
As already noted, von Braun did build the V-2 for Germany and later the Saturn V (and others) for NASA, but he did not "invent" rockets.
More appropriately to your point, the Atlas and Titan rockets used for the Mercury and Gemini manned programs, respectively, were originally designed to be ICBMs. IIRC, there was some initial discomfort about using ICBM's for the space program; the Redstone rocket (used for the Mercury suborbital missions) was designed from the ground up (so to speak) for the space program, and suffered from early reliability problems (before they put men in them). Those problems contributed to overcoming the objections to using the military platforms.
IIRC HP has had rendezvous support in their printers for a while now.
Yes, and at the risk of ruining a perfectly good karma, I will point out that after trying and failing for half an hour to print a web-based document from my Linux machine on my employer's network printers, I put my PowerBook on the net and started the print job in less than 30 seconds via Rendezvous discovery.
But the really cool thing is that the HP printers on the net show up in Safari's Bookmark bar Rendezvous menu, providing HTML interfaces for printer status and settings.
There's a difference between not trusting an ex-frat boy alone in a room and a responsible software developer in a room. Treating everyone on a team the same just breeds discontent. If people work well alone and can be trusted to do so, don't make them waste their time in meetings.
The best team of developers I ever managed still warranted the advice to "beware of a guy in a room." Especially because these guys (they all happened to be guys) were so good, it was possible for any one of them to produce something arguably good and valuable, but which couldn't be used because the cost of incorporating it (in terms of integration and testing) would threaten the schedule. And it would be far more demoralizing to tell someone we couldn't or wouldn't deploy their cool work than it would be to point out ahead of time that it would have to wait for a better time.
I didn't waste their time in meetings. I dropped by every couple of days and chatted about what they were doing, and describe how other (relevant) parts of the project were coming along and how all of it was going to pull together. More often than not, their very professionalism would cause them to adjust their efforts and do something differently than they might have if I left them alone for a couple of weeks.
Yes, NASA accomplished great things back in the 1960s, but that doesn't excuse them from the horrific behavior that they've demonstrated since then.
To the (limited) extent that I agree that NASA's current operations are "horrific", it has been my ongoing observation for over 20 years that NASA has done no worse than industry, education, or art over the same period.
I was first struck by this thought as the investigation into the Challenger disaster unfolded. The transcripts of the conversations at Morton Thiokol (sp?) and NASA could have been transcripts of software release meetings I had recently attended, with different jargon. The long slide that brought us to Columbia has also been reflected in my experiences in writing, shipping, and using software.
The technology is wonderful, but on a computer today I need more RAM than I had disk space in the 1980's to run a word processor. The problem is not technology; it's the value system. The primary problem is pointy-headed bosses, but the rest of us are enablers.
I could go on about education, politics, the arts, etc., but the post would be too long.
The reason I limit my agreement with the parent point of view is because I do believe that, overall, things are much better in both fields. But they aren't nearly as good as they could or should be, and the point of my post is that we can all do better at what we do, and it would be more constructive to seek inspiration from SpaceShipOne and clean up our own acts than to carp at others whose failures simply have higher profiles than our own.
as Joels article pointed out Apple have a much worse track record of backwards compat than Microsoft do
Wait; this is completely contrary to my experience. I worked on Lotus 1-2-3 for Mac, which was targeted at Mac OS 6 & 7 (7 was new when we shipped 1-2-3). 1-2-3 was written in C (actually Symantec's C++ subset) with some inline 68K assembly, and did some grotesque trap patching.
That 1-2-3 68K code runs under OS X on a PowerPC G5. Reliably. I still maintain spreadsheets that I update weekly.
As Joel's article pointed out, Microsoft has engaged in some amazing bend-over-backwards hackery to maintain backward compatibility. This echoes a Wall Street Journal article written about Windows NT development where Dave Cutler bragged about the number of programmers tasked with adding code to make certain "high profile" Windows 3.x apps run under NT.
By contrast, Apple, in the early releases of Mac OS, showed enough foresight to tell developers how to keep their code future-proof, and developers who adhered to those protocols (which were not all that restrictive) wrote apps that still run today, under an entirely new OS on an entirely different CPU.
..I changed my mind several times and decided I agree with the author of the original article.
I do disagree on several points that have been raised, but they don't defeat the final conclusion:
- I do agree that premature optimization has been lethal to many software projects. But I have met as many people who commit PO in HLL's as assembler, so this is not an argument for or against the language.
- The comparisons of startup times and code sizes with the '80s (the 80's! Why, in the 70's we had only... never mind) are amusing, but uninformative; there are a lot more services embedded in the average OS or word processor today. There is a degree of bloat, but the statistics are misleading.
- Hand-crafted assembly code is unlikely to be optimal in light of processor pipelining, multiple execution units, and scheduling. I used to know how many clock cycles each instruction in the PDP-11 instruction set would take to execute for each addressing mode; this information is not nearly so useful for today's processors.
- There are architectural considerations beyond assembly. As early as 1983 a colleague of mine brought a VAX-11/780 (a screamer for its day) to its knees, and came to me complaining bitterly about the processor and/or compiler performance. It turned out that the code in question, which used massive multi-dimensional arrays (in FORTRAN), had compiled into a two-instruction loop (three-operand multiply and an increment/branch), but the code was generating six page faults per iteration! He would not have avoided the problem just by using assembler, but my deeper understanding of the machine led to the identification of the problem.
All that being said, the title of the article is "Why Learning Assembly Language is Still Good." At the end of the day, while I opt to write in Java (or Objective-C, which I'm just picking up), I am better equipped to write good code knowing assembler, and a few other things behind the language and runtime I'm using.
Most Dell desktops are a fair sight quieter than the G5, from what I've seen (and heard).
Well, maybe, but my dual 2GHz G5 is quieter than the Dell Latitude C840 laptop my employer equipped me with. And don't get me started about my fan-less G3 PowerBook...
The statements I partially quoted are not directly attributed to Microsoft (in fact, one is a suggestion by a customer). And even if they were direct quotes from Microsoft, the word "could" carefully qualifies the items as speculation, not promise. Although I have worked for altogether too many software companies who methodically equate "could" with "does".
Well the Americans did, even awarding an anti-Bush movie top merits. It looks like they were finally able to say the things that they've wanted to for a long time now, but were afraid to back home (look at Moore's reception at the Oscars) and used the Cannes Film Festival for that purpose.
This is history in the making. I'm really curious to see what the American public is going to make of this movie and what they will do next.
You think Moore was booed at the Oscars because the people in that crowd disagreed with him? Hardly. It was the equivalent of modding his rant off-topic.
As with any other over-the-top commentary made in the US, the movie will be revered by the extremists on his side, reviled by extremist opponents, and tuned out by thinking people who would rather shed light than heat on a controversial topic.
Many of us have been conditioned to think that both standards and innovation are good things. And the latter is an overused word that Microsoft marketing has forced into the memestream. But really, standards tend to stifle innovation.
So briefly stated, this is likely to be tagged as troll or flamebait, but there's a lot of truth behind this.
It is inarguable that a lot of the best innovation in the history of any industry has been made by people who go outside current standards ("Here's to the crazy ones...") and build something that is the best that they can make it first, and worry about the other considerations later.
[Note that "best" can have many contradictory meanings: best in some narrowly defined performance criteria (fastest, highest, biggest, smallest, etc.), or broad appeal (most general utility, most sell-through), or most efficient, least polluting, cheapest/easiest to manufacture, etc.]
Sometime these evolve into "de facto" standards, and it can be difficult to turn those into "open standards" where there's a level playing field for others beside the first-to-market to gain traction.
As a response, there have been many efforts to develop standards in advance of actual product. In my experience (CAD interchange languages in the 70's and 80's, XForms today), progress on these standards is relatively glacial, and they are often passed over by the industry at large.
I submit that both approaches are good, and that we ought to strive for a healthy tension between them. This argues for moderation by those who cling to the "purity" of their ideals as circumstances change out from under them, and for a willingness to exercise enlightened self-interest and surrender proprietary advantage, vs. rapacious exploitation of current dominance. (We know who we're talking about here...)
To that end, I'd rather see some of the browsers take some risks in advance of accepted standards, at the risk (and expense) of requiring a few willing innovators to perform some extra work ("click here for a non-fizbin version of this site").
Just for a couple of examples, why not re-think where some of later innovations are supported? Can the concept of tabbed browsing by pushed up to the server, so a web designer can deliver a set of related tabs to the client? Could support of the portal/portlet structure be pushed into the client, so that the work of rendering and compositing a page full of portlets can be offloaded from the server, and servlets can execute more autonomously when appropriate?
In the 1960's, yes. Now, no, not really- and your linking to a dictionary doesn't prove it.
How about a link to a description of an architecture from the 70's?;-) The PDP-10 had a programmable byte size; 6-bit bytes were popular for representing strings in those insensitive clod-dish days of dealing with only English.
The way I learned it, a "byte" is the smallest addressable unit of the architecture, and a "word" is (was) typically the size of data that could normally be manipulated in a single operation; this was usually reflected in the size of data (or general purpose) registers and/or the number of data bits fetched in a single cycle, which weren't necessarily the same thing.
The definitions are platform-dependent, and I for one hope that architectures continue to evolve along multiple paths for different purposes, and that the industry does not lock itself down at such a young age.
actually all naval vessles made in the last 60 years are a joke compared to the real battleships of WW-II
I'm not sure I agree, given the changing nature of warfare and weapons, but it reminds me of a tour of a new (Spruance class?) destroyer I was given as a midshipman at the U.S. Naval Academy in the seventies. The tour guide pointed out the limited weaponry and the aluminum superstructure, then enumerated the extensive electronic detection gear, concluding: "that means she can't fight worth a damn, but we'll know exactly who's blowing us out of the water!"
Choice is a good thing. If you don't want a choice of desktops for your operating system I suggest installing Windows or buying a Mac.
Of course, the fundamental problem here is that altogether too many people are doing exactly that.
I don't think the problem is giving users too much choice (although it does bother PHBs), but it's a real issue for a thriving developer community. Microsoft is not hurt by having users scattered all over multiple versions of Windows; their success, IMHO, lies in keeping most of their developers on the reservation by giving them a clear target to develop for. For now.
There's a place for compatible products to accommodate "switchers", but the platform is best served by unique "killer apps."
I'd like to see the original Improv, developed by Lotus for the NeXT platform, revived on Linux. (I'd most like to see it revived on OS X, which is derived from NeXT, but that's another discussion...)
"I bought a piece of software and all I got is something that approximates the value and has its development schedule bent out of shape to force a release, usually at the cost of quality."
Actually, I wrote the software (helped write it, of course) that our corporate masters claimedwas worthy of the price of the subscription. We threw in features that fit into the short-term release cycle, and skipped important fixes and upgrades that didn't fit the schedule. The t-shirt is of course a development team t-shirt, and I don't wear it in the presence of our (former) customers...
...is that you're paying a fixed amount of money per year for a variable amount of product.
If you're paying an annual fee for something on an 18-month update cycle, you're going to have years where you pay the full subscription price for an an idle year.
Or, the vendor is going to feel compelled to deliver something that approximates the value, and bend the development schedule out of shape to force a release, usually at the cost of quality. (Been there, done that, still have the t-shirt.)
So far, I think Apple has done a pretty good job of adding value to each release.
We're talking about a country here that spends "billions" every year working out better ways to kill people. Personally I think space exploration would be a much better way to spend this money.
Hell, we spend billions per year on pet food, on crackpot weight-loss gimmicks, on pornography, and other pointless indulgences each. We don't lack money, we need priorities.
Back when the government gave up on its antitrust suit with IBM (I wonder how many/.ers were around for that? Yikes.), I remember thinking that IBM won because it had enough money to stare down any government, and hating the implications (I had worked almost exclusively on DEC systems for several years, and hated IBM as I now detest Microsoft.)
Well, as Cringley pointed out, things do eventually change. Microsoft will fall, eventually, and probably of its own accord. (Longhorn looks like a good start...)
And an observation that is not a troll, but is likely to get me modded down for the first time anyway: by 1983, I was tired of hearing people say that this was the year that *nix would start to take over. It's taken me many years to become a believer, and I have learned patience along the way.
My view of the book was always that it made idols of the military, only giving the right to vote to the military, etc.
The book may have idolized (sp?) the military, but the vote was granted to anyone who performed Federal service, of which only a small percentage were military. Any civil service job was sufficient, IIRC, and there is a (sarcastic) comment that one could volunteer to be a test subject for medical research if not qualified for anything else.
Slashdot Mirror
10Mbps for $100/month sounds achievable for bursty usage like web browsing, but a) way more screen-hours (orders of magnitude?) are spent watching television than web browsing; and b) the throughput per screen requirements are way higher.
Scale that connection up to 10-15MBps per television set, at an average of 1-1.5 sets per household active during primetime, and I think Comcast's infrastructure in my town would melt. (Figuratively.) I am not an expert on network infrastructure, but I think a lot of hardware and fiber is called for before it can happen, and when the cost of that gets folded into my cable bill, Netflix is going to look pretty good.
Yeah, video on demand is here, but IMHO, it's a step down. I'm using Comcast's service; the choice is limited, and the interface is clumsy (few features, not very responsive.
To me, the math is simple: local storage will always have an advantage over real-time transmission from a central repository, especially as the demand on bandwidth grows. The notion of the network delivering increasingly high-quality content in real time to every possible endpoint is absurd; the cost of the infrastructure to support the bandwidth will be prohibitive.
Which is not to say that Blockbuster and/or Netflix are the last words in media delivery.
Here's my proposal: blend DVR's with near-real-time delivery. Very little media has to be delivered in real time: sporting events, breaking news, maybe (God help us) those final climactic moments on reality shows. Almost everything else could be moved to a subscription model.
Watch "Star Trek" or "24"? Subscribe to the series, and new episodes are delivered to and stored on your set-top as they become available; maybe you get a discount if you're willing to receive the content some time after it's initially available. That's pretty much what I do with my DVR now; I rarely watch a show in real-time, even if I choose to watch it the same day it's broadcast.
Want to watch a movie? Is it such an inconvenience to decide that you're going to want to see a movie this weekend, and queue it up slightly in advance? For those willing to plan ahead, the content providers can balance the load (think Bit Torrent with DRM [sorry]) and preserve bandwidth. The latency doesn't even have to be the total download time; we can already start to view content (streaming media or DVR'd television) before the transmission is complete.
For the really impulsive, the system can be designed to (try to) meet your needs immediately, but genuine "on demand" consumption of a lot of bandwidth is likely to come at additional cost.
It's really the end of the network model (i.e., it would be possible to subscribe to a TV series (or a movie, or a concert, etc.) directly from the producer, without suffering the whims of network schedulers), but that handwriting has been on the wall for a while now.
Oh, getting back on topic: there is a place in all this for those silver discs (or their 2014 equivalent) to save stuff we really care about and free up the hard drive space (or its 2014 equivalent) inside the DVR (or its 2014 equivalent).
Bill has never been one to think outside the box, but I think his box is getting smaller lately...
They did not use the sun's gravitational pull; they used the gravity fields of Venus (twice), Earth, and Jupiter to overcome the sun's gravitational pull.
The "risk" of a Columbia/Challenger type accident - breaking apart from a launch vehicle failure or atmospheric stresses - had nothing to do with the slingshot trajectory, and the RTG was packaged against that contingency. The risk of the slingshot maneuver around earth leading to an accident was infinitesimal.
As the linked article discusses at greater length, the wisdom of the plan was disputed by some, but calling it "very dangerous" is getting close to tin foil hat territory.
Although somebody has pointed out that they did qualify it as the closest approach during the 4-year planned mission, note that Galileo survived 6 years beyond its 2-year planned orbital mission, and sent back data even as they intentionally crashed it into Jupiter to keep if from possibly contaminating one of Jupiter's moons in the future. I wouldn't be surprised if a similar fate is in store for Cassini-Huygens: both a significantly extended mission, followed by a controlled "disposal" when its usefulness has been wrung dry.
As already noted, von Braun did build the V-2 for Germany and later the Saturn V (and others) for NASA, but he did not "invent" rockets.
More appropriately to your point, the Atlas and Titan rockets used for the Mercury and Gemini manned programs, respectively, were originally designed to be ICBMs. IIRC, there was some initial discomfort about using ICBM's for the space program; the Redstone rocket (used for the Mercury suborbital missions) was designed from the ground up (so to speak) for the space program, and suffered from early reliability problems (before they put men in them). Those problems contributed to overcoming the objections to using the military platforms.
Yes, and at the risk of ruining a perfectly good karma, I will point out that after trying and failing for half an hour to print a web-based document from my Linux machine on my employer's network printers, I put my PowerBook on the net and started the print job in less than 30 seconds via Rendezvous discovery.
But the really cool thing is that the HP printers on the net show up in Safari's Bookmark bar Rendezvous menu, providing HTML interfaces for printer status and settings.
The best team of developers I ever managed still warranted the advice to "beware of a guy in a room." Especially because these guys (they all happened to be guys) were so good, it was possible for any one of them to produce something arguably good and valuable, but which couldn't be used because the cost of incorporating it (in terms of integration and testing) would threaten the schedule. And it would be far more demoralizing to tell someone we couldn't or wouldn't deploy their cool work than it would be to point out ahead of time that it would have to wait for a better time.
I didn't waste their time in meetings. I dropped by every couple of days and chatted about what they were doing, and describe how other (relevant) parts of the project were coming along and how all of it was going to pull together. More often than not, their very professionalism would cause them to adjust their efforts and do something differently than they might have if I left them alone for a couple of weeks.
Yes, NASA accomplished great things back in the 1960s, but that doesn't excuse them from the horrific behavior that they've demonstrated since then.
To the (limited) extent that I agree that NASA's current operations are "horrific", it has been my ongoing observation for over 20 years that NASA has done no worse than industry, education, or art over the same period.
I was first struck by this thought as the investigation into the Challenger disaster unfolded. The transcripts of the conversations at Morton Thiokol (sp?) and NASA could have been transcripts of software release meetings I had recently attended, with different jargon. The long slide that brought us to Columbia has also been reflected in my experiences in writing, shipping, and using software.
The technology is wonderful, but on a computer today I need more RAM than I had disk space in the 1980's to run a word processor. The problem is not technology; it's the value system. The primary problem is pointy-headed bosses, but the rest of us are enablers.
I could go on about education, politics, the arts, etc., but the post would be too long.
The reason I limit my agreement with the parent point of view is because I do believe that, overall, things are much better in both fields. But they aren't nearly as good as they could or should be, and the point of my post is that we can all do better at what we do, and it would be more constructive to seek inspiration from SpaceShipOne and clean up our own acts than to carp at others whose failures simply have higher profiles than our own.
Wait; this is completely contrary to my experience. I worked on Lotus 1-2-3 for Mac, which was targeted at Mac OS 6 & 7 (7 was new when we shipped 1-2-3). 1-2-3 was written in C (actually Symantec's C++ subset) with some inline 68K assembly, and did some grotesque trap patching.
That 1-2-3 68K code runs under OS X on a PowerPC G5. Reliably. I still maintain spreadsheets that I update weekly.
As Joel's article pointed out, Microsoft has engaged in some amazing bend-over-backwards hackery to maintain backward compatibility. This echoes a Wall Street Journal article written about Windows NT development where Dave Cutler bragged about the number of programmers tasked with adding code to make certain "high profile" Windows 3.x apps run under NT.
By contrast, Apple, in the early releases of Mac OS, showed enough foresight to tell developers how to keep their code future-proof, and developers who adhered to those protocols (which were not all that restrictive) wrote apps that still run today, under an entirely new OS on an entirely different CPU.
I do disagree on several points that have been raised, but they don't defeat the final conclusion:
- I do agree that premature optimization has been lethal to many software projects. But I have met as many people who commit PO in HLL's as assembler, so this is not an argument for or against the language.
- The comparisons of startup times and code sizes with the '80s (the 80's! Why, in the 70's we had only... never mind) are amusing, but uninformative; there are a lot more services embedded in the average OS or word processor today. There is a degree of bloat, but the statistics are misleading.
- Hand-crafted assembly code is unlikely to be optimal in light of processor pipelining, multiple execution units, and scheduling. I used to know how many clock cycles each instruction in the PDP-11 instruction set would take to execute for each addressing mode; this information is not nearly so useful for today's processors.
- There are architectural considerations beyond assembly. As early as 1983 a colleague of mine brought a VAX-11/780 (a screamer for its day) to its knees, and came to me complaining bitterly about the processor and/or compiler performance. It turned out that the code in question, which used massive multi-dimensional arrays (in FORTRAN), had compiled into a two-instruction loop (three-operand multiply and an increment/branch), but the code was generating six page faults per iteration! He would not have avoided the problem just by using assembler, but my deeper understanding of the machine led to the identification of the problem.
All that being said, the title of the article is "Why Learning Assembly Language is Still Good." At the end of the day, while I opt to write in Java (or Objective-C, which I'm just picking up), I am better equipped to write good code knowing assembler, and a few other things behind the language and runtime I'm using.
Well, maybe, but my dual 2GHz G5 is quieter than the Dell Latitude C840 laptop my employer equipped me with. And don't get me started about my fan-less G3 PowerBook...
The statements I partially quoted are not directly attributed to Microsoft (in fact, one is a suggestion by a customer). And even if they were direct quotes from Microsoft, the word "could" carefully qualifies the items as speculation, not promise. Although I have worked for altogether too many software companies who methodically equate "could" with "does".
Well, I guess it's time for everybody else to abandon this space, because Microsoft has it all covered.
This is history in the making. I'm really curious to see what the American public is going to make of this movie and what they will do next.
You think Moore was booed at the Oscars because the people in that crowd disagreed with him? Hardly. It was the equivalent of modding his rant off-topic.
As with any other over-the-top commentary made in the US, the movie will be revered by the extremists on his side, reviled by extremist opponents, and tuned out by thinking people who would rather shed light than heat on a controversial topic.
This is not censorship; it's moderation.
So briefly stated, this is likely to be tagged as troll or flamebait, but there's a lot of truth behind this.
It is inarguable that a lot of the best innovation in the history of any industry has been made by people who go outside current standards ("Here's to the crazy ones...") and build something that is the best that they can make it first, and worry about the other considerations later.
[Note that "best" can have many contradictory meanings: best in some narrowly defined performance criteria (fastest, highest, biggest, smallest, etc.), or broad appeal (most general utility, most sell-through), or most efficient, least polluting, cheapest/easiest to manufacture, etc.]
Sometime these evolve into "de facto" standards, and it can be difficult to turn those into "open standards" where there's a level playing field for others beside the first-to-market to gain traction.
As a response, there have been many efforts to develop standards in advance of actual product. In my experience (CAD interchange languages in the 70's and 80's, XForms today), progress on these standards is relatively glacial, and they are often passed over by the industry at large.
I submit that both approaches are good, and that we ought to strive for a healthy tension between them. This argues for moderation by those who cling to the "purity" of their ideals as circumstances change out from under them, and for a willingness to exercise enlightened self-interest and surrender proprietary advantage, vs. rapacious exploitation of current dominance. (We know who we're talking about here...)
To that end, I'd rather see some of the browsers take some risks in advance of accepted standards, at the risk (and expense) of requiring a few willing innovators to perform some extra work ("click here for a non-fizbin version of this site").
Just for a couple of examples, why not re-think where some of later innovations are supported? Can the concept of tabbed browsing by pushed up to the server, so a web designer can deliver a set of related tabs to the client? Could support of the portal/portlet structure be pushed into the client, so that the work of rendering and compositing a page full of portlets can be offloaded from the server, and servlets can execute more autonomously when appropriate?
How about a link to a description of an architecture from the 70's? ;-) The PDP-10 had a programmable byte size; 6-bit bytes were popular for representing strings in those insensitive clod-dish days of dealing with only English.
The way I learned it, a "byte" is the smallest addressable unit of the architecture, and a "word" is (was) typically the size of data that could normally be manipulated in a single operation; this was usually reflected in the size of data (or general purpose) registers and/or the number of data bits fetched in a single cycle, which weren't necessarily the same thing.
The definitions are platform-dependent, and I for one hope that architectures continue to evolve along multiple paths for different purposes, and that the industry does not lock itself down at such a young age.
I'm not sure I agree, given the changing nature of warfare and weapons, but it reminds me of a tour of a new (Spruance class?) destroyer I was given as a midshipman at the U.S. Naval Academy in the seventies. The tour guide pointed out the limited weaponry and the aluminum superstructure, then enumerated the extensive electronic detection gear, concluding: "that means she can't fight worth a damn, but we'll know exactly who's blowing us out of the water!"
Of course, the fundamental problem here is that altogether too many people are doing exactly that.
I don't think the problem is giving users too much choice (although it does bother PHBs), but it's a real issue for a thriving developer community. Microsoft is not hurt by having users scattered all over multiple versions of Windows; their success, IMHO, lies in keeping most of their developers on the reservation by giving them a clear target to develop for. For now.
I'd like to see the original Improv, developed by Lotus for the NeXT platform, revived on Linux. (I'd most like to see it revived on OS X, which is derived from NeXT, but that's another discussion...)
So SP2 is going to include a Microsoft add-on that monitors third-party add-on's that monitor the Microsoft OS.
Who said these guys didn't know how to design an OS?
Actually, I wrote the software (helped write it, of course) that our corporate masters claimedwas worthy of the price of the subscription. We threw in features that fit into the short-term release cycle, and skipped important fixes and upgrades that didn't fit the schedule. The t-shirt is of course a development team t-shirt, and I don't wear it in the presence of our (former) customers...
If you're paying an annual fee for something on an 18-month update cycle, you're going to have years where you pay the full subscription price for an an idle year.
Or, the vendor is going to feel compelled to deliver something that approximates the value, and bend the development schedule out of shape to force a release, usually at the cost of quality. (Been there, done that, still have the t-shirt.)
So far, I think Apple has done a pretty good job of adding value to each release.
Hell, we spend billions per year on pet food, on crackpot weight-loss gimmicks, on pornography, and other pointless indulgences each. We don't lack money, we need priorities.
Well, as Cringley pointed out, things do eventually change. Microsoft will fall, eventually, and probably of its own accord. (Longhorn looks like a good start...)
And an observation that is not a troll, but is likely to get me modded down for the first time anyway: by 1983, I was tired of hearing people say that this was the year that *nix would start to take over. It's taken me many years to become a believer, and I have learned patience along the way.
The book may have idolized (sp?) the military, but the vote was granted to anyone who performed Federal service, of which only a small percentage were military. Any civil service job was sufficient, IIRC, and there is a (sarcastic) comment that one could volunteer to be a test subject for medical research if not qualified for anything else.
IMHO, the movie was lame.