Here's the other big if - where's the money in VOIP-over-public-network?
Do you sell the client? That's difficult partly because you need uptake, and partly because there are already numerous voice/IM clients out there.
Do you use it to drive bandwidth sales? Seems likely to work, but only moderately lucractive
Do you scan its content for ad placement? That seems likely to really freak people out and backfire in a big way.
I can see some good money in hardware, support, and bandwith with VOIP, but client software doesn't seem like a winning game for long. Maybe I'm just missing out on the revolution.
To be honest, Google Talk actually seems like a bit of a deflating moment - it's the first product Google's released whose features are already widely present in the market. I haven't downloaded it, and don't really plan to, unless it has some new features to die for.
# -1 : even a relatively small incursion of people into a wilderness has a pretty large impact on wildlife. Plus, while a well is small, a network of roads is not.
# -2 : opening an area to development, however small, almost always leads to more development. Doubly so if there's more oil than people think.
# -3 : The likelihood is miniscule that there will be enough oil to even remotely offset peak oil globally (or in the case of the US, augment put our production anywhere back towards the peak it hit 20 years ago). Oil as a general energy medium is clearly reaching its limit, and we should invest in infrastructure to move to other forms of energy starting now, rather than riding oil out to its bitter end.
But driving for 120 minutes at $8/a gallon is not as comfortable, and looking more and more likely as a 10 year prediction. Whereas if you invest now in the transit system, in 4 years you cut the transit-based commute to 60-70 minutes, and it stays there, and costs cap at some $4.50 each way over the next decade, with cabs and rental cars supplementing the general system. Why do you suppose most people don't own cars in New York?
We have a massive wild reserve of native fauna: it's called the Artic National Wildlife Refuge (ANWR), and its megafauna are why it's an absolutely stupid idea to drill there for a small amount of oil.
Very, very well put. You are spot on with your assessment of transit frequency - people would rather wait 50 minutes or more in their car in gridlock than 25 at a bus stop, and that's hard math to change unless you can get the bus wait down below 10 or 15 minutes.
One more thing you should put in that mix is that the second half of that postwar period saw the rise of a strongly anti-statist party and movement in the US that has absolutely refused to consider government planning, of which transit is a subset. Transit been thrown to the wayside, and sustainable land use has as well - sustainable not just in the environmental sense, but in the sense of building communities that can afford their infrastructure over the long run. For example, look what happens to bedroom communities as their populations and infrastructure age - they don't have the tax base (which requires density of both residents and businesses) to pay for school systems and fixing sewers. So not only are we lacking any decent mass transit, we are also lacking the networks of people, government agencies, and the popular understanding that would allow people to begin to build those systems. Fortunately there has been some revitalization
The same anti-government sentiment and absolute refusal to engage in any coordinated efforts to keep markets sane has hobbled competition in many of the US' important marketplaces, with communications being the obvious leader in backwardness, but the finance (housing bubble), energy (Enronesque deregulation), automotive (fuel efficiency standards that feed the industry's addiction to poorly built SUV's), and airline (pension fund sophistry and slow response to commoditization) industries are doing their respective best to stamp out functional, transparent marketplaces as well.
I agree with you that it'll take a fight to make people think seriously about saner building patterns, but I'm not optimistic about it getting resolved soon, and in the interim I see our standard of living getting hammered by it. One scholar of poverty recently pointed out that while a car is a status symbol in most poor countries, in the suburban and rural US it's a necessity even for lower-income people - you simply cannot hold down a job without a car, and that makes people very vulnerable to rising energy prices. Combine that with our severely weakened support for education and scientific research, and you see some serious potholes in the US' economic road.
yes, the article is a bit buzzy. But the rich internet application thing is obvious. Why do slashbots (including myself) hate webmail? Three words: multiple round trips.
RIA's are what Java was supposed to be years ago - something you could deploy universally via a browser, and would run just enough code locally (e.g. the view part of an MVC system) that the program would feel reponsive, but be able to get data in a more complete and granular way than most current web pages do. For example, we've all seen Javascript by now that can fill a combo box based on another combo box, without refreshing the page. What RIA toolkits do (or at least are headed towards) provide is all that event communication between widgets (and simple widget to server communication) that makes client-side apps comfortable, like having one widget listen for changes in another, or in an attached dataset, and reacting to those changes, rather than the developer having to do all that cascading of events themself. It's not unlike the ALT attribute on an IMG tag example you mention, except that it handles all that client-side plumbing so you don't have to do it.
There are several variations emerging, and DHTML is an attractive one because the infrastructure exists, aside from stupid Javascript incompatibilities in browsers. So an RIA toolkit from IBM could indeed make Firefox a good choice for delivering applications.
I believe this functionality is built into later versions of Word.
Per the site, this produces simpler HTML with Office-specific tags removed. With that done, you could probably use a PERL script, and you might also try writing some Word macros or COM/VBA scripts that clean up the document from within Word.
That's not entirely true. What's required is thoughtful, gradual, and appropriate deregulation. Some markets function best with minimal interference, some very quickly end up with massive failures.
For example, deregulation of the airline industry sped the commoditization of airfare. It was done a little carelessly (hence the lack of preparation for a commoditized market), though not as badly as the energy deregulation debacle in California. Any change in the regulatory landscape always present opportunities - for some businesses more than others. And that's naturally a sticky situation for the government, since it involves handing out favors to particular businesses, even if the ultimate effect is potentially to level the playing field.
This particular regulatory change happens to be disastrous - it's Enron redux. I wouldn't be surprised if we saw the same Enron-style business deceptions to boot. Our telecom industry is already years behind much of the developed world, and this will only worsen that situation. It drives me nuts to watch people prostate themselves in front the altar of "free markets", and watch as we continuously fail to make the investments our country needs to keep moving forward.
Telephone wires fall under "natural monopolies", where the investment and effort of creating a competing version of the thing for sale creates such prohibitive barriers that the market naturally tends toward monopoly. Phones, roads, sewers, power lines are all this type of situation.
Deregulation can potentially improve some of these services (provided it is done in a careful and balanced way) by de-integrating the actual monopoly from the elements sold on top of it. In phones, that would mean that one market is maintaining and selling physical phone lines (this one being a natural monopoly and hence tightly regulated to ensure non-discriminatory access), and another is selling voice and data services on these lines. The dergulation of the voice and data services market is what can help - deregulation of the wires and poles market is a disaster in the offing.
This proposal is the worst of both worlds - the telcos are allowed to keep their monopoly in the wires and poles market, as well as their vertical integration, but are having all markets deregulated. Look for rampant abuse, as well as distinct lack of competion or innovation.
I'll concede that it's open to interpretation. And I agree that an organization can use "performance" to justify a wide variety of disciplinary tactics. But "performance" does set the bar a little higher on both sides, since it requires that people articulate what the employee should be doing and how s/he is failing to meet it, rather than relying on interpretations of interpersonal behavior.
This, however, is a different animal:
But employers can and must be able to terminate employees essentially at will.
I'm of two minds on employment at will. On the one hand, the employer needs the ability to incentivate, discipline, and yes, fire employees when the business requires it. On the other hand, unfettered employment at will allows some companies (I'm not lumping everyone together in this) to hold wages very low or squash any requests for better working conditions by firing anyone who complains. Wal-Mart and the meat-packing industry have reputations for using these kinds of tactics.
If the labor market cleared fully, I would be more in favor of unfettered employment at will, but sadly it often does not. That's why I'm troubled to see the NLRB taking a step back in these cases, rather than issuing clarifying guidance that doesn't particularly fetter the employer, but makes it clear they're willing to intervene when necessary.
There is no inherent right to work, regardless of how important employment might tangentially be to our actual rights.
I guess I'd say that society has an duty to ensure that all people have open opportunities to work, but a worker doesn't have the right to specific employment at a specific organization. I'm not sure if that's agreement or disagreement - but I think it's worth articulating that society does have a responsibility to make it better than catch as catch can for those at the bottom.
We must be reading a different document, because this is simply not correct:
The actual order of the ruling, i.e,, the part of the ruling that took new action, did deal with the uniform issue.
The order is all on page 10 of the ruling, and the Board specifically declined to make any changes to Guardsmark's fraternization rule.
It could have easily required clarification of the rule to prohibit only (to quote the decision):
socializ[ing] with other employees [...] in a manner that affect[s] his job duties.
I'm not questioning your political affiliation or your pro or anti "working man" cred. And I don't think that the complainant, Higgins, was primarily interested in union organizing - I think the Rights at Work people kind of overstate that.
But I do think you're glossing over an NLRB decision giving substantial latitude to employers. I mean honestly, if I'm an IT contractor at a company, should the company really have the right to ask that I not fraternize with employees of that company, on or off duty - provided of course that fraternization has no effect on my work? I really think that's a rather large overreach that the NLRB should have pushed back on.
Whoa, hold on a minute. I agree that it's possible to go overboard with the conspiracy against the working man stuff, but there are numerous elements in this decision that implicitly give the employer more discretion, and simultaneously recuse the NLRB from oversight of them.
The NLRB taking no action is essentially a validation of the rule, as the only changes Guardsmark is ultimately required to make are those stipulated by the NLRB. Therefore the Board's "NO ACTION" as you like to repeat in CAPS allowed the rule to stand as written. And despite the board's reliance on the a previous, more limited rule (that of Lafayette) the rule as written made no reference to in-uniform on out of uniform, so barring another NLRB complaint, Guardsmark is not obliged to enforce it in this way.
The crux of the argument is this:
In our view, it would be an unreasonable stretch for an employee to infer that speaking to others about terms and conditions of employment is a "fraternization" that is condemned by the rule.
That's actually a rather weak interpretation. How the employees interpret "fraternization" depends pretty heavily on how the company presents and enforces that rule, and given that the NLRB has declined to limit the rule's scope, Guardsmark has every incentive to enforce it aggressively. This kind of weak interpretation is essentially an abdication of NLRB to address the issue, which in itself represents a weakening of its protective posture towards workers, especially given that its raison d'etre is to provide workers with a forum for mediation outside of the company.
Its added reasoning:
Moreover, as the judge noted and our dissenting col-league ignores, the Respondent's rule is designed "to provide safeguards so that security will not be compro-mised by interpersonal relationships either between Re-spondent's fellow security guards or between Respon-dent's security guards and clients' employees."
is even weaker, because it accepts unquestioningly a claim that fraternization of any sort (given the wide scope of the rule) contributes to poorer security. There's no particular reason to believe that all kinds of fraternization outside of work weaken security. There's basically no excuse for not narrowing the scope to "at work or in uniform".
While I don't quite agree with hyperbolic view of the Rights at Work people's assessment that:
Such a ban inevitably chills collective action of any sort
because part C of the decision nominally affirms the employees right to organize in or out of uniform, it too relies on very weak, non-intrusive reasoning:
As noted, I find the provision to be sufficiently clear on its face to advise employees that they should not engage in unofficial business while in uniform. This implies that such activities are permissible provided they are not in uniform; and it seems reasonable to presume that em-ployees, without having to be specifically told, would under-stand that removing or covering their uniforms will constitute compliance with this provision.
Again, what employees intrepret is a pretty strong function of what management tells them and what kind of enforcement climate it creates. So if you're expecting them to say "no, people can't organize at work and we won't make any employer allow it", you're not gonna find it. But you are gonna find evidence that the NLRB is not gonna push at all to enforce that right. And that is exactly the prerogative of the Bush administration.
I don't quite agree. There's still a fair bit of writing (or rewriting) apps from desktop-deployed to web-based yet to go, and a browser that provides a good platform to do that can gain or lose market share. It look like the upcoming generation of big webapps will use Flash or Lazslo or some other framework (wasn't LongVista originally supposed to have one of these?) to give a little more functionality to the client side, so a browser that does well supporting that could find itself the center of attention in the corporate world.
Actually, retrofitting windows is rather expensive, and can cause substantial structural problems if not done well. So $8000 to light a few rooms with natural light is not bad in comparison to windows.
Fair enough. I do agree that after a period of intense advance, the OS seems to have settled into a relatively stable period. But part of that was just maturing - most OSes/desktops are now mature enough to handle any application fetching content from any sources from.
The filesystem issue is an interesting one to my mind. It's clear that we all want data storage in the network "cloud": robust, secure, cheap or free, and available everywhere. It's basically FreeNet tweaked to focus on private uses of data rather than anonymous publishing. Maybe I'm looking in the wrong places, but have yet to see any simple version of that released.
Someone else on this thread pointed out that we're waiting for more or less working versions of some big pieces before more innovation can break loose: pieces like very good, very general speech-to-text, or in my filesystem case, a general, accepted trust authentication mechanism. Those pieces are complicated science and/or social organization problems, so it's hard to predict how long it will take to resolve them, but when they are resolved I'd expect to see a lot of big innovation of the type you describe.
I work in a healthcare organization's IT department. We have vendors that go out of business or stop offering products we've come to depend on, but then offer an "upgrade" that will cause us to change our entire workflow. Therefore, we make sure we know our systems intimately so we don't get burned.
I think this can substantially favor open source. As you say, you want to understand the system intimately in-house, both for diagnosing and solving problems quickly, and for being able to adequately deal with discontinuities in vendor relationships. Open source arises exactly that idea, you want to be able to know the software intimately enough that you might need the source, and you definitely can use a manual that explains what the source is doing.
However, you also want to hedge your bets against something that is very difficult to support when an employee leaves or a software upgrade becomes necessary. A support company is basically an institution that knows as much or more than you do about your system, so they can step in and help when you need it. So your best bets are packages that have goood vendor and developer communities, whether open or closed source.
Oh right, I guess I shouldn't have disconnected that Innovation cable from the Linux port.
Innovation is not a discrete process: it happens mostly by luck, and when you happen on something that works. Demanding more innovation from Linux is sort of like saying to Honda, "why didn't you just set out to make a hovercraft instead of jumping in and making the same boring old cars as everyone else?" Honda makes cars because people want to buy cars. Linux developers add to Linux because that's what they or their employers need.
And there's no shortage of nifty new ideas that nobody is quite certain how to use - see, for example the earlier/. post about folding windows. Neat idea - hard to tell if it will be really useful in practice.
Welcome to real life progress - it ain't overnight and it ain't pretty, but it moves.
We don't need to dump tons of resources into it, because the situation will correct itself automatically. From the perspective of biofuel producers, Peak Oil is just a business opportunity.
While I agree with you that the market forces may ultimately help to steer energy use away from oil, there's very little to suggest that there won't be a lot of human suffering and ecological devastation along the way. Markets change a whole lot faster than ecosystems, and repairing damage to ecosystems is doubly difficult because human activity serves as an equivalent to entropy, making it prohibitively difficult to reverse time's arrow. Business opportunities are found by being able to predict an upcoming market landscape, and being lucky enough to get the details right. Since it's also not hard to imagine Peak {Insert Natural Resource Here}, the benefits of learning how to cut that corner are manifold.
This will slow economic growth, of course, but there's not going to be any economic collapse outside of Saudi Arabia and Venezuela.
Again, I think you're being waaayyyy too optimistic. Economies do ultimately adjust to more expensive energy, but in the interim, they can take a beating from the price shocks which occur when supply is very tight. Think about it: if one quarter you're planning for cheap oil and it turns out expensive, you get nailed (happened most major airlines in the US in the past year). On the other hand, let's say you bet on expensive oil, and it turns out cheap - you lose a boatload of money on your hedge, and either your business hurts or you beg the government for a bailout due to "force majeur". The larger the volality, the larger a fraction of your risk energy costs become.
The point is that we can avoid a lot of very ugly situations by thinking proactive, and that means thinking big. We Americans put ourselves at a huge disadvantage to the Chinese and others because of our stubborn insistence on refusing to put even a modicum of trust into the hands of the only entity who can think really, really big - government.
Even things that SHIP WITH WINDOWS are prone to oversight which tells me one thing (and has been second'ed but not necessarily confirmed on/.) -- Microsoft doesn't believe in restricted access in its development model (read: Microsoft employees all have administrative level access).
My impression from my friends at MS was that the situation was actually rather like Linux developers now - you build your own boxen, and then use them to develop. Unlike their Linux-development brethren, however, MS devs have heavy demands to make things work in the existing Windows environment, whatever that entails. And that means they drag around these arrangements requiring Administrator access for decades.
Linux has a number of parallels - installing almost anything beyond a self-contained executable (e.g. security updates for KDE) requires root access, and quite frequently requires messing around with core OS libraries. That's a pretty extensive pathway for security vulnerabilities in itself.
That is a fantastic essay. Just goes to show you that some people's insight is so penetrating that it's relevant for nearly a century.
Absolutely the best of many pithy lines in that essay is:
The Fascist octopus has sung its swan song.
I can't even begin to imagine today's equivalent.
I'd say an important reason for this is that so much of commerce has come to rely on language and writing skills, but there hasn't been a concomitant increase in zeal for learning those skills. If everyone read Orwell's essay and E.B. White's primers on clear writing on a regular basis, the world would be a much more well-spoken place.
Ah yes, the inevitable task-based vs. app. based start menu discussion. I participated in a whole lot of these a couple years back on the KDE usability list, and the same issues were there then.
It's actually rather hard to design a "what would like to do with your computer" applet that deals with the wide variety of things people want to do with their computer. If Start Menu is not the best approach, it's hard to say that another is head and shoulders about it.
Overall, I think you've hit the nail on the head. However, I'd add a couple other pieces I think bear remarking on.
In big projects, open source is, as you allude to, basically about commoditization of components. What makes Linux valuable is not that it's new and different form other Unices, but that for most purposes Unices are all effectively equivalent, and Linux is the one we can get our grubby paws on most easily and cheaply. You just want a server with capacity to do particular things, and don't really care what brand of Unix it runs. Open source is the least-common denominator.
On the other side of the spectrum, there's a fairly large class of non-"core infrastructure" software development where open source is basically standard, and that is science. The notion of "open source" comes out of academia and is built deeply into its working. Yes, science-related programming forms a small fraction of the money moving around in IT, but many of the interesting new computing trends businesses adopt come out of academia, and more and more that research comes accompanied with code.
I expect this to gain increased prominence as new businesses are built off of science. As always, the calculus is about commoditizing something you and your competition both have, so as to compete on other terms. Big pharma keeps it operational systems awful secret, but AFAIK it runs many important product development operations on top of open source software.
Open source also has a natural advantage in the "understanding what the hell's going on" part of the software development process. For anybody who's putting together a system that uses components in a complex way, understanding what's going on is critical to having the component be useful. Having access to the source, documentation aiming towards revealing how something works rather than hiding it, and most importantly, to a community of people who understand know and understand the inner workings of the product, can go an awful long way towards making up for lack of paid technical writers whose business it is to document every feature. The arrangement ain't perfect, but it's very good surprisingly often.
Another thing that your post highlights, but is a bit of a surprise in the real world is how social and communitarian programmers are. In person, they have earned a reputation for being just the opposite, but through their work, they are an astoundingly helpful, social groups. Small miracles...
Anyway, just some more thoughts to add to your insightful ones.
What I can tell you is that at least on the program I work (a major middleware software development for the Army being written by a "major" defense contractor"), the corporate attorneys are scared to death of the GPL.
I'd speculate that's a combination of couple things. One is that earlier versions of the GPL were reputedly a little shaky on the contract-law side of things, so for an attorney managing that scale of legal risk it would be pretty scary to try to work with a contract where you know the legal language is not that clear. The second is that this is a new kind of contract law and as such when your client asks you what might happen if things do wind up in court all you can do is shrug. Does your client have to release all their code, or will it be sufficient to cease distributing and possibly pay damages? Hopefully new versions of the GPL will clarify this, as well some kind of court clarification on the interpretation of the GPL.
I would strike a middle ground between totally needed and not needed.
I recently evaluated SugarCRM for use with andinternal system we are building. The internal system wraps up IP that extends well beyond strict software development, and releasing that system right now could well kill our company (and definitely get me fired). This is exactly why we used Postgres instead of MySQL - Postgres is BSD. On the other hand, anything we did to Sugar would basically be a reasonable candidate for release, because it does not touch our IP. If Sugar were not GPL-ish, I'm not sure we'd get off our duff to release any changes to Sugar. After all, this requires figuring out what the line between releasable and non-releasable is, and the easier position is just not to release.
The point is that there's often a less bright line than the GPL draws. There should be some push to release code that builds on stuff you've drawn from the commons, but not one that demands that everything touched by commons code be released. Frankly, I think the LGPL does a pretty good job there, and I'd like to see that type of license adopted more widely.
It's a nice vision, but it'll never happen. The desktop app market is mature, and beginning the long slide into commodity. The best Google could get out of cross-platform apps would be to reduce MS' margins a bit, and since Google doesn't compete with MS in the desktop software market, this doesn't help them much.
Basically the only big desktop apps left to write are corporate databases and workflows type apps, perhaps a bit of research-driven software like AI, and a few downloadables in the home space. None of those merit going after a Linux desktop.
Google's core business is Internet information distribution, much like a radio station. They have wisely shown very little interest in getting into anything else.
Slashdot Mirror
That's difficult partly because you need uptake, and partly because there are already numerous voice/IM clients out there.
Seems likely to work, but only moderately lucractive
That seems likely to really freak people out and backfire in a big way.
I can see some good money in hardware, support, and bandwith with VOIP, but client software doesn't seem like a winning game for long. Maybe I'm just missing out on the revolution.
To be honest, Google Talk actually seems like a bit of a deflating moment - it's the first product Google's released whose features are already widely present in the market. I haven't downloaded it, and don't really plan to, unless it has some new features to die for.
# -1 : even a relatively small incursion of people into a wilderness has a pretty large impact on wildlife. Plus, while a well is small, a network of roads is not.
# -2 : opening an area to development, however small, almost always leads to more development. Doubly so if there's more oil than people think.
# -3 : The likelihood is miniscule that there will be enough oil to even remotely offset peak oil globally (or in the case of the US, augment put our production anywhere back towards the peak it hit 20 years ago). Oil as a general energy medium is clearly reaching its limit, and we should invest in infrastructure to move to other forms of energy starting now, rather than riding oil out to its bitter end.
But driving for 120 minutes at $8/a gallon is not as comfortable, and looking more and more likely as a 10 year prediction. Whereas if you invest now in the transit system, in 4 years you cut the transit-based commute to 60-70 minutes, and it stays there, and costs cap at some $4.50 each way over the next decade, with cabs and rental cars supplementing the general system. Why do you suppose most people don't own cars in New York?
We have a massive wild reserve of native fauna: it's called the Artic National Wildlife Refuge (ANWR), and its megafauna are why it's an absolutely stupid idea to drill there for a small amount of oil.
Very, very well put. You are spot on with your assessment of transit frequency - people would rather wait 50 minutes or more in their car in gridlock than 25 at a bus stop, and that's hard math to change unless you can get the bus wait down below 10 or 15 minutes.
One more thing you should put in that mix is that the second half of that postwar period saw the rise of a strongly anti-statist party and movement in the US that has absolutely refused to consider government planning, of which transit is a subset. Transit been thrown to the wayside, and sustainable land use has as well - sustainable not just in the environmental sense, but in the sense of building communities that can afford their infrastructure over the long run. For example, look what happens to bedroom communities as their populations and infrastructure age - they don't have the tax base (which requires density of both residents and businesses) to pay for school systems and fixing sewers. So not only are we lacking any decent mass transit, we are also lacking the networks of people, government agencies, and the popular understanding that would allow people to begin to build those systems. Fortunately there has been some revitalization
The same anti-government sentiment and absolute refusal to engage in any coordinated efforts to keep markets sane has hobbled competition in many of the US' important marketplaces, with communications being the obvious leader in backwardness, but the finance (housing bubble), energy (Enronesque deregulation), automotive (fuel efficiency standards that feed the industry's addiction to poorly built SUV's), and airline (pension fund sophistry and slow response to commoditization) industries are doing their respective best to stamp out functional, transparent marketplaces as well.
I agree with you that it'll take a fight to make people think seriously about saner building patterns, but I'm not optimistic about it getting resolved soon, and in the interim I see our standard of living getting hammered by it. One scholar of poverty recently pointed out that while a car is a status symbol in most poor countries, in the suburban and rural US it's a necessity even for lower-income people - you simply cannot hold down a job without a car, and that makes people very vulnerable to rising energy prices. Combine that with our severely weakened support for education and scientific research, and you see some serious potholes in the US' economic road.
yes, the article is a bit buzzy. But the rich internet application thing is obvious. Why do slashbots (including myself) hate webmail? Three words: multiple round trips.
RIA's are what Java was supposed to be years ago - something you could deploy universally via a browser, and would run just enough code locally (e.g. the view part of an MVC system) that the program would feel reponsive, but be able to get data in a more complete and granular way than most current web pages do. For example, we've all seen Javascript by now that can fill a combo box based on another combo box, without refreshing the page. What RIA toolkits do (or at least are headed towards) provide is all that event communication between widgets (and simple widget to server communication) that makes client-side apps comfortable, like having one widget listen for changes in another, or in an attached dataset, and reacting to those changes, rather than the developer having to do all that cascading of events themself. It's not unlike the ALT attribute on an IMG tag example you mention, except that it handles all that client-side plumbing so you don't have to do it.
There are several variations emerging, and DHTML is an attractive one because the infrastructure exists, aside from stupid Javascript incompatibilities in browsers. So an RIA toolkit from IBM could indeed make Firefox a good choice for delivering applications.
If you're using Office 2000, you can find the HTML filter here:
a milyID=209ADBEE-3FBD-482C-83B0-96FB79B74DED&displa ylang=EN
http://www.microsoft.com/downloads/details.aspx?F
I believe this functionality is built into later versions of Word.
Per the site, this produces simpler HTML with Office-specific tags removed. With that done, you could probably use a PERL script, and you might also try writing some Word macros or COM/VBA scripts that clean up the document from within Word.
That's not entirely true. What's required is thoughtful, gradual, and appropriate deregulation. Some markets function best with minimal interference, some very quickly end up with massive failures.
For example, deregulation of the airline industry sped the commoditization of airfare. It was done a little carelessly (hence the lack of preparation for a commoditized market), though not as badly as the energy deregulation debacle in California. Any change in the regulatory landscape always present opportunities - for some businesses more than others. And that's naturally a sticky situation for the government, since it involves handing out favors to particular businesses, even if the ultimate effect is potentially to level the playing field.
This particular regulatory change happens to be disastrous - it's Enron redux. I wouldn't be surprised if we saw the same Enron-style business deceptions to boot. Our telecom industry is already years behind much of the developed world, and this will only worsen that situation. It drives me nuts to watch people prostate themselves in front the altar of "free markets", and watch as we continuously fail to make the investments our country needs to keep moving forward.
Telephone wires fall under "natural monopolies", where the investment and effort of creating a competing version of the thing for sale creates such prohibitive barriers that the market naturally tends toward monopoly. Phones, roads, sewers, power lines are all this type of situation.
Deregulation can potentially improve some of these services (provided it is done in a careful and balanced way) by de-integrating the actual monopoly from the elements sold on top of it. In phones, that would mean that one market is maintaining and selling physical phone lines (this one being a natural monopoly and hence tightly regulated to ensure non-discriminatory access), and another is selling voice and data services on these lines. The dergulation of the voice and data services market is what can help - deregulation of the wires and poles market is a disaster in the offing.
This proposal is the worst of both worlds - the telcos are allowed to keep their monopoly in the wires and poles market, as well as their vertical integration, but are having all markets deregulated. Look for rampant abuse, as well as distinct lack of competion or innovation.
This, however, is a different animal:
I'm of two minds on employment at will. On the one hand, the employer needs the ability to incentivate, discipline, and yes, fire employees when the business requires it. On the other hand, unfettered employment at will allows some companies (I'm not lumping everyone together in this) to hold wages very low or squash any requests for better working conditions by firing anyone who complains. Wal-Mart and the meat-packing industry have reputations for using these kinds of tactics.
If the labor market cleared fully, I would be more in favor of unfettered employment at will, but sadly it often does not. That's why I'm troubled to see the NLRB taking a step back in these cases, rather than issuing clarifying guidance that doesn't particularly fetter the employer, but makes it clear they're willing to intervene when necessary.
I guess I'd say that society has an duty to ensure that all people have open opportunities to work, but a worker doesn't have the right to specific employment at a specific organization. I'm not sure if that's agreement or disagreement - but I think it's worth articulating that society does have a responsibility to make it better than catch as catch can for those at the bottom.
The order is all on page 10 of the ruling, and the Board specifically declined to make any changes to Guardsmark's fraternization rule.
It could have easily required clarification of the rule to prohibit only (to quote the decision):I'm not questioning your political affiliation or your pro or anti "working man" cred. And I don't think that the complainant, Higgins, was primarily interested in union organizing - I think the Rights at Work people kind of overstate that.
But I do think you're glossing over an NLRB decision giving substantial latitude to employers. I mean honestly, if I'm an IT contractor at a company, should the company really have the right to ask that I not fraternize with employees of that company, on or off duty - provided of course that fraternization has no effect on my work? I really think that's a rather large overreach that the NLRB should have pushed back on.
The NLRB taking no action is essentially a validation of the rule, as the only changes Guardsmark is ultimately required to make are those stipulated by the NLRB. Therefore the Board's "NO ACTION" as you like to repeat in CAPS allowed the rule to stand as written. And despite the board's reliance on the a previous, more limited rule (that of Lafayette) the rule as written made no reference to in-uniform on out of uniform, so barring another NLRB complaint, Guardsmark is not obliged to enforce it in this way.
The crux of the argument is this:
That's actually a rather weak interpretation. How the employees interpret "fraternization" depends pretty heavily on how the company presents and enforces that rule, and given that the NLRB has declined to limit the rule's scope, Guardsmark has every incentive to enforce it aggressively. This kind of weak interpretation is essentially an abdication of NLRB to address the issue, which in itself represents a weakening of its protective posture towards workers, especially given that its raison d'etre is to provide workers with a forum for mediation outside of the company.
Its added reasoning: is even weaker, because it accepts unquestioningly a claim that fraternization of any sort (given the wide scope of the rule) contributes to poorer security. There's no particular reason to believe that all kinds of fraternization outside of work weaken security. There's basically no excuse for not narrowing the scope to "at work or in uniform".
While I don't quite agree with hyperbolic view of the Rights at Work people's assessment that: because part C of the decision nominally affirms the employees right to organize in or out of uniform, it too relies on very weak, non-intrusive reasoning:
Again, what employees intrepret is a pretty strong function of what management tells them and what kind of enforcement climate it creates. So if you're expecting them to say "no, people can't organize at work and we won't make any employer allow it", you're not gonna find it. But you are gonna find evidence that the NLRB is not gonna push at all to enforce that right. And that is exactly the prerogative of the Bush administration.
Actually, retrofitting windows is rather expensive, and can cause substantial structural problems if not done well. So $8000 to light a few rooms with natural light is not bad in comparison to windows.
Fair enough. I do agree that after a period of intense advance, the OS seems to have settled into a relatively stable period. But part of that was just maturing - most OSes/desktops are now mature enough to handle any application fetching content from any sources from.
The filesystem issue is an interesting one to my mind. It's clear that we all want data storage in the network "cloud": robust, secure, cheap or free, and available everywhere. It's basically FreeNet tweaked to focus on private uses of data rather than anonymous publishing. Maybe I'm looking in the wrong places, but have yet to see any simple version of that released.
Someone else on this thread pointed out that we're waiting for more or less working versions of some big pieces before more innovation can break loose: pieces like very good, very general speech-to-text, or in my filesystem case, a general, accepted trust authentication mechanism. Those pieces are complicated science and/or social organization problems, so it's hard to predict how long it will take to resolve them, but when they are resolved I'd expect to see a lot of big innovation of the type you describe.
I think this can substantially favor open source. As you say, you want to understand the system intimately in-house, both for diagnosing and solving problems quickly, and for being able to adequately deal with discontinuities in vendor relationships. Open source arises exactly that idea, you want to be able to know the software intimately enough that you might need the source, and you definitely can use a manual that explains what the source is doing.
However, you also want to hedge your bets against something that is very difficult to support when an employee leaves or a software upgrade becomes necessary. A support company is basically an institution that knows as much or more than you do about your system, so they can step in and help when you need it. So your best bets are packages that have goood vendor and developer communities, whether open or closed source.
Oh right, I guess I shouldn't have disconnected that Innovation cable from the Linux port.
/. post about folding windows. Neat idea - hard to tell if it will be really useful in practice.
Innovation is not a discrete process: it happens mostly by luck, and when you happen on something that works. Demanding more innovation from Linux is sort of like saying to Honda, "why didn't you just set out to make a hovercraft instead of jumping in and making the same boring old cars as everyone else?" Honda makes cars because people want to buy cars. Linux developers add to Linux because that's what they or their employers need.
And there's no shortage of nifty new ideas that nobody is quite certain how to use - see, for example the earlier
Welcome to real life progress - it ain't overnight and it ain't pretty, but it moves.
The point is that we can avoid a lot of very ugly situations by thinking proactive, and that means thinking big. We Americans put ourselves at a huge disadvantage to the Chinese and others because of our stubborn insistence on refusing to put even a modicum of trust into the hands of the only entity who can think really, really big - government.
My impression from my friends at MS was that the situation was actually rather like Linux developers now - you build your own boxen, and then use them to develop. Unlike their Linux-development brethren, however, MS devs have heavy demands to make things work in the existing Windows environment, whatever that entails. And that means they drag around these arrangements requiring Administrator access for decades.
Linux has a number of parallels - installing almost anything beyond a self-contained executable (e.g. security updates for KDE) requires root access, and quite frequently requires messing around with core OS libraries. That's a pretty extensive pathway for security vulnerabilities in itself.
Security is hard.
Absolutely the best of many pithy lines in that essay is:I can't even begin to imagine today's equivalent.
I'd say an important reason for this is that so much of commerce has come to rely on language and writing skills, but there hasn't been a concomitant increase in zeal for learning those skills. If everyone read Orwell's essay and E.B. White's primers on clear writing on a regular basis, the world would be a much more well-spoken place.
Ah yes, the inevitable task-based vs. app. based start menu discussion. I participated in a whole lot of these a couple years back on the KDE usability list, and the same issues were there then.
It's actually rather hard to design a "what would like to do with your computer" applet that deals with the wide variety of things people want to do with their computer. If Start Menu is not the best approach, it's hard to say that another is head and shoulders about it.
As others have said, excellent post.
Overall, I think you've hit the nail on the head. However, I'd add a couple other pieces I think bear remarking on.
In big projects, open source is, as you allude to, basically about commoditization of components. What makes Linux valuable is not that it's new and different form other Unices, but that for most purposes Unices are all effectively equivalent, and Linux is the one we can get our grubby paws on most easily and cheaply. You just want a server with capacity to do particular things, and don't really care what brand of Unix it runs. Open source is the least-common denominator.
On the other side of the spectrum, there's a fairly large class of non-"core infrastructure" software development where open source is basically standard, and that is science. The notion of "open source" comes out of academia and is built deeply into its working. Yes, science-related programming forms a small fraction of the money moving around in IT, but many of the interesting new computing trends businesses adopt come out of academia, and more and more that research comes accompanied with code.
I expect this to gain increased prominence as new businesses are built off of science. As always, the calculus is about commoditizing something you and your competition both have, so as to compete on other terms. Big pharma keeps it operational systems awful secret, but AFAIK it runs many important product development operations on top of open source software.
Open source also has a natural advantage in the "understanding what the hell's going on" part of the software development process. For anybody who's putting together a system that uses components in a complex way, understanding what's going on is critical to having the component be useful. Having access to the source, documentation aiming towards revealing how something works rather than hiding it, and most importantly, to a community of people who understand know and understand the inner workings of the product, can go an awful long way towards making up for lack of paid technical writers whose business it is to document every feature. The arrangement ain't perfect, but it's very good surprisingly often.
Another thing that your post highlights, but is a bit of a surprise in the real world is how social and communitarian programmers are. In person, they have earned a reputation for being just the opposite, but through their work, they are an astoundingly helpful, social groups. Small miracles...
Anyway, just some more thoughts to add to your insightful ones.
I would strike a middle ground between totally needed and not needed.
I recently evaluated SugarCRM for use with andinternal system we are building. The internal system wraps up IP that extends well beyond strict software development, and releasing that system right now could well kill our company (and definitely get me fired). This is exactly why we used Postgres instead of MySQL - Postgres is BSD. On the other hand, anything we did to Sugar would basically be a reasonable candidate for release, because it does not touch our IP. If Sugar were not GPL-ish, I'm not sure we'd get off our duff to release any changes to Sugar. After all, this requires figuring out what the line between releasable and non-releasable is, and the easier position is just not to release.
The point is that there's often a less bright line than the GPL draws. There should be some push to release code that builds on stuff you've drawn from the commons, but not one that demands that everything touched by commons code be released. Frankly, I think the LGPL does a pretty good job there, and I'd like to see that type of license adopted more widely.
It's a nice vision, but it'll never happen. The desktop app market is mature, and beginning the long slide into commodity. The best Google could get out of cross-platform apps would be to reduce MS' margins a bit, and since Google doesn't compete with MS in the desktop software market, this doesn't help them much.
Basically the only big desktop apps left to write are corporate databases and workflows type apps, perhaps a bit of research-driven software like AI, and a few downloadables in the home space. None of those merit going after a Linux desktop.
Google's core business is Internet information distribution, much like a radio station. They have wisely shown very little interest in getting into anything else.