I've been using computers daily since 1979, and using a standard keyboard at least eight hours a day since 1983. I have always used the mouse as little possible. For the past ten years or so I've used a trackpad for the little mousing I do (mostly the occasional copy (I paste via keyboard) and the times I have to access a web site that can only be used with javascript active (and even there I use the keyboard shortcuts in Mozilla/Firefox as often as not)). Oh, and it's probably worth noting that I use only the *main* keys plus the function keys. I use the keys to the right of the enter key only very occasionally, except for the shift-insert combo.
I have so far (knock on wood) never had more than the occasional pain in my hands, and those pains I have had have gone away within a day or two without treatment and probably had nothing to do with my keyboarding.
I do practice the basic ergonomics (monitor in front so I'm looking very slightly down, legs at ninety, elbows near ninetly and on armrests, forearms supported in front of keyboard so wrists are flat). I've done that since I started keyboarding daily in '83.
So either (a) a lot of RSI suffers don't do basic ergonimics or (b) I'm lucky or (c) (my favorite theory) the mouse is what's killing all you RSI sufferers.
For those who are curiuos, I achieve my minimal mouse usage via the following programs: X windows, ION window manager, vi editor, w3m-image browser with vi keybindings, snownews RSS reader with vi keybindings, and pine mail reader (which I wish had vi keybindings!)
If I had to do graphics work I think I'd get a digitising tablet.
What if general availability of this program and others like it does *not* lead to a decrease in ITunes sales? What if instead it leads to an increase?
Don't dismiss this as impossible. People actually *will* pay for things they think are quality even if they don't have to. If people have confidence money is really going to the artists, I would actually expect the ability to swap files to lead to an *increase* in ITunes sales for quality music.
The key here is that the price is reasonable, unlike CDs. Though it could still stand to come down a little bit more, and could if we could get the RIAA out of the picture.
The main documentation for Zope was made user annotatable using a product called "TalkBack" developed by one of the Zope developers. It worked moderately well, I think. Fewer problems than the PHP community had, I think, probably because the Zope community is smaller and so you get fewer of the clumsy-hack notes. I think if you take the tack of *authorizing* people to comment, then you can avoid that problem to a considerable extent. Also, if you can maintain the schedule of incorporating updates within two or three weeks I bet you could mitigate the rouge comment problem almost completely.
I started to design a system like this at a previous job. Really what you want is something you can customize, because ideally you'd have special request screens for "standard" requests. These would have custom workflow logic, because it might be different for each kind of request ("set up PC for new hire", "wipe disk drives of PC of departing employee").
After looking around, I decided to use roundup. I had two reasons for this choice: the first is that I prefer programming in python, which is what it's written in. The second (but more important) is that it is designed for flexibility. Basically, it's really a framework (database, workflow, web interface, email interface), and on top of that framework is implemented a fairly good bug tracker. But it's pretty easy to build your own application on top of the framework. I started to do so, and only the fact that I left the company when it downsized the unit for which I was writing the code prevented it from getting finished and deployed.
If you don't already know python, it's easy to learn.
Ideally what you will be doing is using the roundup framework to implement your particular business logic. Since roundup isn't perfect, you will of course have to do some non-business-logic code to really get it to do what you want. But the framework is powerful, so depending on your requirements you may not need that much non-business logic.
Speaking as a Zope 3 contributor, though not one who's had time to do much more than follow the mailing lists, here's my take: Guido was a good occasonal contributor to Zope 3, and a useful voice in critiquing design decisions and so on (his unique perspective on the consequences of Python design on Zope design descisions was particularly beneficial). Most of his Zope 3 contributions came in the form of code whose needs originated in or were informed by Zope 3, but which were actually developed under Python Labs. (I could be wrong about this, but that's my impression). I'm guessing we'll see his influence on Zope 3 continue through his Python work.
I don't think I'd even classify his departure as a speed bump in the Zope 3 development process. Maybe the speedometer will drop a few mph, but I'm pretty sure Zope Corp will assign someone to fill in the gap in terms of code production.
Guido is the Python BFDL (Benevolent Dictator For Life). For Zope (and Zope 3 in particular) the corresponding role is filled by Jim Fulton, who is fondly known as the Zope Pope. It's Jim's vision and drive that informs Zope 3 development, and always has been.
So, Zope is alive and well, and I for one wish Guido luck and fun in his new persuits!
Actually, I think there is currently too much emphasis on new features in the commercial software world, so something that makes them less eager to throw in the kitchen sink might be a good thing! I mean, think about some of the upgrade problems you've heard about people having with Microsoft products: user interfaces change, buttons move around, you basically have to learn the idiosyncracies of the new release before you can be productive again. Now imagine that you aren't in control of when that happens! So if software rental happens (unlikely), it would be a feature that enhancements were slow and non-disruptive, and I think that would be a good thing. Bug fixes, on the other hand, would be the biggest benefit.
The best thing about the free software upgrade processes like Debian is that the user is in control of when it happens, but gets the rest of the benefits that software rental would provide, at no charge. We win again:).
Two things I think both Balmer and a lot of the posters here seem to be missing: (1) the market tends to be diverse, so you don't have to have one model throughout and (2) why are we talking about "apps" as if we were going to "rent" monolithic programs constructed along the lines of the word processors and such we install on our computers today?
For the first, I see no reason why Open Source software, homegrown software, COTS software using a buy-once purchase model, and COTS software using a 'rental' model, can't all coexist in the marketplace. I'm expecting Open Source will outcompete COTS to the point where it dissapears, but even if it doesn't, no big deal.
But that doesn't mean that we won't be renting things over the Net when we have the bandwidth. But what we might be renting is very unlikely to look like a traditional application program. I'm expecting it to look much more like a service. I believe we are transitioning from a manufacture based economy to a service based economy. Open Source is part of the transition, and I think it's pretty well accepted that the service-based income model is integral to the expected success of the Open Source model. More than likely, the best services we'll be buying from will be based on Open Source software and fierce but mostly friendly competition between service providers.
So I think Balmer's right that traditional COTS software is going to eventually dissapear. But I'm also pretty sure he's wrong if he thinks that Microsoft renting access to application programs is going to replace it!
I've heard the 70% figure elsewhere, and from personal experience as an ISP would not be at all surprised if it were true. If asked, I would say that we use BSD rather than Linux, even though we have a couple of Linux servers in addition to the BSD servers.
The article actually touched accurately on the reason why, too. One of the strengths of Linux is the rapid pace of innovation and feature addition. This is actually a negative when I'm looking for an OS to run my servers. There, I need a consistent source and a relatively modest change rate, with the priority given to features relevant to the running-servers activity. FreeBSD excells at that.
So at home I'll run FreeBSD on my house server, and Linux on my workstation. As others have said, the two are *complimentary*, with different focuses. And the BSD people should not be upset about the greater press given to Linux, IMO. Linux should have the most press because its strengths will ultimately play well in the consumer market. The BSDs will be found and supported, as appropriate, by those of us with services to run. And of course there will continue to be a lot of cross polination between the two, especially in the application realm.
By the way, I found the mentions of BSDi in the article very interesting in light of the licensing argument. I used to use BSDi exclusively, but the problem with BSDi is that they did exactly what the BSD license allows: they added proprietary code and kept it proprietary. For this reason, while I am maintaining my current BSDi servers for the moment, any new servers are FreeBSD or Linux. So as far as I am concerned, the ability to, shall we say, proprietorize using BSD-license code just gives companies the ability to shoot themselves in the foot. Open Source is the superior business model, whatever license you execute it under.
NB: I suspect that Linux could erode the FreeBSD server market share if some company would craft a distrabution aimed at service providers, characterized by a modest, server focused change rate, and providing reasonably priced support contracts.
There is a huge difference between the producer or sales agent putting a sentence on a product that says "this product conforms to the Open Source Guidelines" and that same producer or sales agent being authorized by OSI to put an "OSI Certified" mark on the product. In the former case, you have only the produer's word that the product is really compliant (and buyer beware applies even if a product costs nothing!). In the latter case, you have OSI's word that the product is compliant.
In a free market (and that is the same meaning of the word free that is used in the term free software by FSF), the value proposition that OSI offers is the reliability of the mark. This is true whether or not they make money off the mark directly, because if they do, they have financial reason to defend the meaning of the mark, and if they don't they are motivated by the same value propositions that motivate the rest of the free software movement: reputation and indirect gain.
It is all very well and good to say we should each do our own research, but as others have pointed out, there is a better way. The power of freedom is that it allows each of us to share with the others the fruits of our labors, to our mutual benefit. In this case, OSI contributes the labor of doing the research to make sure a particular product complies with the Open Source Guidelines, so that we don't each have to indivudially use our valuable time to do that for every product we use.
The OSI mark is only as useful as its consistent reputation. The "Designed for Windows" mark is practically worthless precisely because it tells you nothing you don't already know (and sometimes lies). I think we can be pretty sure that the OSI mark will retain its value, and be of service to the community.
And the beauty of the free market is that if you don't like what OSI stands for, you can set up your own competing certification. And the "customers" get additional information that way, by seeing which products bear which (or both) marks.
In fact, I don't see the "split" between the "free software" folks and the "open source" folks as a bad thing at all. It's just free market competition, from which we have all profited (the controversies have strengthened all sides), and will continue to do so!
OK, things are getting clearer. They seem to be trying to claim ownership of the whois data relating to their own domain registration services, as opposed to the base data held by the registry (which they currently operate). This is not totally unreasonable, and I certainly would prefer that people not harvest my address from NSI's whois and sell it...but what I really want is for that data to be accessible only in a more controlled fashion. I also want the opportunity to review, update, and delete that data (or switch to another registrar with a strong privacy policy), since when I gave it originally I didn't have any choice in the matter...
The base registry information (basically, the name servers for the domain and who the responsible registrar is) is available separately from NSI's whois, on a web page at www.nsiregistry.com. I'm not sure whether I think their consequent hijacking of the rs.internic.net whois gateway that all our whois commands point to by default is good, but at least in the open source community we can fix that problem quickly if we decide to. On the other hand, since NSI is probably not going to be running the registry long term, 'nsiregistry.com' is an odd choice of domain name.
We are a long way from this multiple-registrar stuff working smoothly!! But, in the long run I think it will be better than what we have now. The transition is going to be painful and confusing, though.
So I do a normal, workaday 'whois' query, and today it says at the bottom:
You agree that you will not reproduce, sell, transfer, or modify any of the data presented in response to your search request, or use of any such data for commercial purpose, without the prior express written permission of Network Solutions.
Well, I most certainly do NOT agree! How can my tech support people help our domain customers if we can't make "commercial use" of the informtation returned by a whois query, for gnu's sake? There's noplace *else* to get this info. I just check register.com, and their whois page just queries the NSI database, and that same message shows up at the bottom of the response screen. Which, I'm sure, is why NSI put it there.
NSI has been trying to claim that they have a compilation copyright (or something like that) on the current database. This smells like an attempt to assert that, and I sure hope the stuff hits the fan over this.
Slashdot Mirror
I've been using computers daily since 1979, and using a standard
keyboard at least eight hours a day since 1983. I have always used
the mouse as little possible. For the past ten years or so I've
used a trackpad for the little mousing I do (mostly the occasional
copy (I paste via keyboard) and the times I have to access a web
site that can only be used with javascript active (and even there
I use the keyboard shortcuts in Mozilla/Firefox as often as not)).
Oh, and it's probably worth noting that I use only the *main* keys
plus the function keys. I use the keys to the right of the enter
key only very occasionally, except for the shift-insert combo.
I have so far (knock on wood) never had more than the occasional
pain in my hands, and those pains I have had have gone away within
a day or two without treatment and probably had nothing to do
with my keyboarding.
I do practice the basic ergonomics (monitor in front so I'm looking
very slightly down, legs at ninety, elbows near ninetly and on
armrests, forearms supported in front of keyboard so wrists are
flat). I've done that since I started keyboarding daily in '83.
So either (a) a lot of RSI suffers don't do basic ergonimics
or (b) I'm lucky or (c) (my favorite theory) the mouse is
what's killing all you RSI sufferers.
For those who are curiuos, I achieve my minimal mouse usage via
the following programs: X windows, ION window manager, vi
editor, w3m-image browser with vi keybindings, snownews RSS
reader with vi keybindings, and pine mail reader (which I wish
had vi keybindings!)
If I had to do graphics work I think I'd get a digitising tablet.
What if general availability of this program and others like it
does *not* lead to a decrease in ITunes sales? What if instead it
leads to an increase?
Don't dismiss this as impossible. People actually *will* pay for
things they think are quality even if they don't have to. If people
have confidence money is really going to the artists, I would
actually expect the ability to swap files to lead to an *increase*
in ITunes sales for quality music.
The key here is that the price is reasonable, unlike CDs. Though
it could still stand to come down a little bit more, and could if
we could get the RIAA out of the picture.
The main documentation for Zope was made user annotatable using a
product called "TalkBack" developed by one of the Zope developers.
It worked moderately well, I think. Fewer problems than the PHP
community had, I think, probably because the Zope community is
smaller and so you get fewer of the clumsy-hack notes. I think if
you take the tack of *authorizing* people to comment, then you can
avoid that problem to a considerable extent. Also, if you can
maintain the schedule of incorporating updates within two or three
weeks I bet you could mitigate the rouge comment problem almost
completely.
I started to design a system like this at a previous job. Really
what you want is something you can customize, because ideally you'd
have special request screens for "standard" requests. These would
have custom workflow logic, because it might be different for each
kind of request ("set up PC for new hire", "wipe disk drives of PC
of departing employee").
After looking around, I decided to use roundup.
I had two reasons for this choice: the first is that I prefer
programming in python, which is what it's written in. The second
(but more important) is that it is designed for flexibility.
Basically, it's really a framework (database, workflow, web interface,
email interface), and on top of that framework is implemented a
fairly good bug tracker. But it's pretty easy to build your own
application on top of the framework. I started to do so, and only
the fact that I left the company when it downsized the unit for
which I was writing the code prevented it from getting finished and
deployed.
If you don't already know python, it's easy to learn.
Ideally what you will be doing is using the roundup framework to
implement your particular business logic. Since roundup isn't
perfect, you will of course have to do some non-business-logic code
to really get it to do what you want. But the framework is powerful,
so depending on your requirements you may not need that much
non-business logic.
RDM (bitdancer)
Speaking as a Zope 3 contributor, though not one who's had time to
do much more than follow the mailing lists, here's my take: Guido
was a good occasonal contributor to Zope 3, and a useful voice in
critiquing design decisions and so on (his unique perspective on
the consequences of Python design on Zope design descisions was
particularly beneficial). Most of his Zope 3 contributions came
in the form of code whose needs originated in or were informed by
Zope 3, but which were actually developed under Python Labs. (I
could be wrong about this, but that's my impression). I'm guessing
we'll see his influence on Zope 3 continue through his Python work.
I don't think I'd even classify his departure as a speed bump in
the Zope 3 development process. Maybe the speedometer will drop a
few mph, but I'm pretty sure Zope Corp will assign someone to fill
in the gap in terms of code production.
Guido is the Python BFDL (Benevolent Dictator For Life). For Zope
(and Zope 3 in particular) the corresponding role is filled by Jim
Fulton, who is fondly known as the Zope Pope. It's Jim's vision
and drive that informs Zope 3 development, and always has been.
So, Zope is alive and well, and I for one wish Guido luck
and fun in his new persuits!
--RDM
The best thing about the free software upgrade processes like Debian is that the user is in control of when it happens, but gets the rest of the benefits that software rental would provide, at no charge. We win again :).
--BitDancer
For the first, I see no reason why Open Source software, homegrown software, COTS software using a buy-once purchase model, and COTS software using a 'rental' model, can't all coexist in the marketplace. I'm expecting Open Source will outcompete COTS to the point where it dissapears, but even if it doesn't, no big deal.
But that doesn't mean that we won't be renting things over the Net when we have the bandwidth. But what we might be renting is very unlikely to look like a traditional application program. I'm expecting it to look much more like a service. I believe we are transitioning from a manufacture based economy to a service based economy. Open Source is part of the transition, and I think it's pretty well accepted that the service-based income model is integral to the expected success of the Open Source model. More than likely, the best services we'll be buying from will be based on Open Source software and fierce but mostly friendly competition between service providers.
So I think Balmer's right that traditional COTS software is going to eventually dissapear. But I'm also pretty sure he's wrong if he thinks that Microsoft renting access to application programs is going to replace it!
--BitDancer
The article actually touched accurately on the reason why, too. One of the strengths of Linux is the rapid pace of innovation and feature addition. This is actually a negative when I'm looking for an OS to run my servers. There, I need a consistent source and a relatively modest change rate, with the priority given to features relevant to the running-servers activity. FreeBSD excells at that.
So at home I'll run FreeBSD on my house server, and Linux on my workstation. As others have said, the two are *complimentary*, with different focuses. And the BSD people should not be upset about the greater press given to Linux, IMO. Linux should have the most press because its strengths will ultimately play well in the consumer market. The BSDs will be found and supported, as appropriate, by those of us with services to run. And of course there will continue to be a lot of cross polination between the two, especially in the application realm.
By the way, I found the mentions of BSDi in the article very interesting in light of the licensing argument. I used to use BSDi exclusively, but the problem with BSDi is that they did exactly what the BSD license allows: they added proprietary code and kept it proprietary. For this reason, while I am maintaining my current BSDi servers for the moment, any new servers are FreeBSD or Linux. So as far as I am concerned, the ability to, shall we say, proprietorize using BSD-license code just gives companies the ability to shoot themselves in the foot. Open Source is the superior business model, whatever license you execute it under.
NB: I suspect that Linux could erode the FreeBSD server market share if some company would craft a distrabution aimed at service providers, characterized by a modest, server focused change rate, and providing reasonably priced support contracts.
--BitDancer
In a free market (and that is the same meaning of the word free that is used in the term free software by FSF), the value proposition that OSI offers is the reliability of the mark. This is true whether or not they make money off the mark directly, because if they do, they have financial reason to defend the meaning of the mark, and if they don't they are motivated by the same value propositions that motivate the rest of the free software movement: reputation and indirect gain.
It is all very well and good to say we should each do our own research, but as others have pointed out, there is a better way. The power of freedom is that it allows each of us to share with the others the fruits of our labors, to our mutual benefit. In this case, OSI contributes the labor of doing the research to make sure a particular product complies with the Open Source Guidelines, so that we don't each have to indivudially use our valuable time to do that for every product we use.
The OSI mark is only as useful as its consistent reputation. The "Designed for Windows" mark is practically worthless precisely because it tells you nothing you don't already know (and sometimes lies). I think we can be pretty sure that the OSI mark will retain its value, and be of service to the community.
And the beauty of the free market is that if you don't like what OSI stands for, you can set up your own competing certification. And the "customers" get additional information that way, by seeing which products bear which (or both) marks.
In fact, I don't see the "split" between the "free software" folks and the "open source" folks as a bad thing at all. It's just free market competition, from which we have all profited (the controversies have strengthened all sides), and will continue to do so!
--BitDancer
The base registry information (basically, the name servers for the domain and who the responsible registrar is) is available separately from NSI's whois, on a web page at www.nsiregistry.com. I'm not sure whether I think their consequent hijacking of the rs.internic.net whois gateway that all our whois commands point to by default is good, but at least in the open source community we can fix that problem quickly if we decide to. On the other hand, since NSI is probably not going to be running the registry long term, 'nsiregistry.com' is an odd choice of domain name.
We are a long way from this multiple-registrar stuff working smoothly!! But, in the long run I think it will be better than what we have now. The transition is going to be painful and confusing, though.
--BitDancer
So I do a normal, workaday 'whois' query, and today it says at the bottom:
Well, I most certainly do NOT agree! How can my tech support people help our domain customers if we can't make "commercial use" of the informtation returned by a whois query, for gnu's sake? There's noplace *else* to get this info. I just check register.com, and their whois page just queries the NSI database, and that same message shows up at the bottom of the response screen. Which, I'm sure, is why NSI put it there.
NSI has been trying to claim that they have a compilation copyright (or something like that) on the current database. This smells like an attempt to assert that, and I sure hope the stuff hits the fan over this.
This is intolerable.
--Bitdancer