Speaking as someone who was at Wineshopper.com during its fiery demise...
I thought the concept of the company was great, and there were definitely some good people. But the business plan turned out to have nothing in common with reality. Perhaps they might have made it if they'd appeared three years earlier and the money faucet had stayed open long enough for them to find their footing.
6. But this is still a major obstacle to mass deployment. The only good alternative to bundled binary drivers for consumer hardware is to have a strict standard for auto-building a bundled driver from source, and this would require too much inter-distro and inter-desktop cooperation to ever work.
These are two separate issues. I certainly do favor open sourcing drivers wherever possible, but that's no reason to create binary incompatibilities within a "stable" kernel series. It's hard enough keeping the growing pool of drivers up to date without randomly breaking them for no good reason. A semi-stable (obviously you'd have to allow changes within a development series) ABI would make development and deployment of drivers easier, while not hurting the real arguments for open-sourcing those drivers.
I'm reminded of the political situation surrounding transit in the San Francisco area. The bicycle and mass transit lobbies have it in their heads that anything that hurts car drivers must therefore be good for everyone else. So with the support of the city council they've managed to make a bad traffic situation even worse while failing to provide halfway decent public transportation or safe routes for bicyclists.
At my first IT job, I had a department head who preached the idea that users are customers. The results were frequently disastrous, but he didn't care because he didn't have to do any of the hands-on work.
While the sysadmin-user relationship does bear some resemblance to that between service providers and customers, it is definitely not the same thing. You're providing a service, but you're not doing it in exchange for money (at least not from the people receiving the service). And you're both answerable to management. This sometimes results in situations where you have to deny the users what they want so that you can give them what the company needs them to have.
Of course, to do it right you need to have an IT department that gets to know the company's business and works well with other groups. Non-technical (or semi-technical) employees will frequently come up with unreasonable, impractical demands, but they can also be very understanding about being denied if they believe that the decision was made for good reasons. That's why it's very important for IT not to focus purely on minimizing their own workload.
Sysadmins and users working together in harmony...
Not meaning to bash Microsoft (I'm undecided on whether this school thing is a good idea), but you're citing examples of Gates' personal/foundation giving. In that sphere, I think he has done some marvelous, selfless work. Incidentally, I also respect his father's efforts to retain and reform the estate tax. In their private lives, the Gates family is clearly motivated by concerns beyond their own benefit.
Quite to the contrary: organizations composed primarily of non-IT people are the ones that most appreciate machines that "just work". You run into problems when every workgroup gets its own little IT "expert". Of course, if you run Windows, every workgroup needs its own little IT "expert" because machines constantly screw up, lock up, freeze, and do other weird things.
To a degree that's true. Non-IT people certainly don't want to be bothered with learning the details of the systems they work with. What they do want, however, is for IT to be very flexible in responding to requests. A tightly controlled environment is resistant to change, and that sometimes leads to conflict with the users.
Now, I think we agree that centralized management and rigorous change control can seriously reduce the workload on IT. But sometimes exceptions have to be made in order to support business needs. An IT department that clings too tightly to abstract principles tends to forget that its reason for existing is to enable other employees to get their work done.
Huh? Why would professional Linux developers screw up management? In fact, UNIX developers, just like other users, traditionally also appreciate not having to bother with system management, and on UNIX machines, they don't have to. Again, it's only on Windows where every developer needs to become a system manager to make sure their machines have just the right combinations of tools, patches, IDEs, libraries, etc., and get reinstalled every few weeks.
No user like to fix things when they break. But most of them want to be able change things to suit their preferences (thus leading them to break stuff). Most Linux developers are power users, and thus resistant to letting someone else control their workstations. They are, at least, fairly understanding about the need for strict management of the server environment.
It seems that we are in rough agreement as to how IT should control servers. And while I recognize the ideal of total workstation control that you endorse, I don't feel that it is practical (or even desirable) to force every employee of a company to work on the equivalent of a dumb terminal. The pure glass house model may make life easier and more lucrative for IT, but everyone else rebelled against it a long time ago.
Yes, the way a well-run IT department should operate. Microsoft shops have been trying to achieve that sort of operation for years, largely unsuccessfully and at enormous cost.
Well, that's fine as a general ideal to work towards, but compromises will always have to be made in an organization that isn't entirely composed of IT people. Hell, just adding a few Linux developers to the mix is enough to screw up any tightly controlled management scheme.
And your point is what? That because many people don't know how to run an efficient IT infrastructure, everybody else should screw up in the same way?
You're certainly free to interpret my words that way.
That only works if the workstations are tightly controlled, secured and integrated into the server environment. In a real-world organization with large numbers of loosely-coupled desktops and laptops, such a scheme is really painful to maintain. And probably very insecure. At least SMB doesn't put too much trust in the client.
Re:again not quite there
on
Kroupware Komplete
·
· Score: 3, Informative
Building such a connector is clearly a monumental task. I oversaw a test deployment of Bynari Insight Connector a while ago, and I was disturbed to see how kludged together it was. Not only was it a major pain in the ass to configure on a given workstation, but the end product clearly behaved differently than regular Outlook. Needless to say, the project was a non-starter.
I've been meaning to check out Samsung Contact to see if their Outlook integration is any better. It doesn't seem like anyone in the open source world is going to do what it takes to enable such interoperability.
Back when I supported FreeBSD regularly, I remember wishing that Perl were set up as a port/package. Easier to maintain and upgrade separately that way. In general, I was not pleased that the core OS was a monolithic entity that was inconvenient to patch in the field.
I do recall that some people were working on a binary update system for the core distribution, but I don't know whether that went anywhere.
If a software package doesn't come in RPM form, then I usually end up having to build and test my own RPM spec for it. My homegrown software deployment and auditing system (based off cfengine) depends on package information to determine when to install or upgrade a piece of software.
I do have a couple of pieces of software (RT, in particular) that don't easily lend themselves to binary packaging. In those cases I have to document the exact manual build procedure in case I ever have to recreate the machine. That's considerably more work than saying "install everything you're supposed to be running".
Without copyright, you could distribute currently-GPL binaries without source. That would provide an edge if your business was in supporting or customizing said software.
I think what he meant was that soccer players don't carry around as much of the jock mentality because they're not worshipped as gods.
That said, I do think that the barriers to entry are higher for football than for soccer. More equipment is required, the game is more complicated, and the physical requirements are greater. I don't deny that many soccer players are great athletes, but their basic body types tend to bear some resemblance to normal humans. In my youth I was actually reasonably good at soccer, but no amount of training would have given me the size and speed needed to be competitive in football.
Basketball has the same sort of exclusivity, which is probably why it shares the spotlight with football in the U.S. Soccer happens to translate very poorly to television, but I think another factor is that any group of regular citizens can have more fun walking over to the park and playing the game themselves. We're not as fast or as skilled as the professionals, but we're basically doing the same thing. When we watch football and basketball on television, we see the players perform feats that we can't even begin to approximate on our own.
Of course, I am completely unable to come up with an explanation for why people watch baseball on TV.
My statement is truth though, it takes no courage or introspection to beleive what man can say (evolution of man), it takes courage to believe in God and instrospection to understand a higher power.
I would argue the opposite. If God (in something approaching the Christian form) exists, then it takes a lot of the burden off of us as individuals. It's a lot harder to deal with life's helping of moral dillemas when you don't have a higher authority telling you what to do. And if believing in God requires courage, then we're a pretty brave species, because we seem rather inclined to buy into religion.
Of course, whichever way you may swing on that issue, it doesn't necessarily follow that the path which requires more courage is the better one. It would take a lot of courage for me to walk into a police station and try to shoot all of the cops before one of them drops me.
As for your other point, I do agree that most biblical stories have some basis on historical fact. It makes perfect sense that wars, political upheavals and natural disasters were turned into legends. But it also makes sense that our primitive ancestors were inclined to attribute supernatural causes to otherwise mundane events. The tendency to sensationalize events is nothing new to humanity, though CNN and Fox have certainly upped the ante.
Sadly, it does matter. If you choose MS Office, then you gain compatibility with a much wider range of add-on packages. You also reduce training costs, as it is far more likely that an incoming employee will be familiar with MS Office than any of its competitors.
And while I do encourage people to use neutral formats for inter-company exchanges, one would hardly be "insane" to e-mail someone a.DOC file. The odds are overwhelming that the recipient will be able to read it, and you can just deal with the exceptions when they come up (e.g., you notice that the recipient is rms@windowzsucks.com). When I make a phone call within the U.S., I generally don't make preparations for speaking in any language other than English.
your point is completely valid. computer users have gone from brilliant and innovativly clever to lazy end users. Why is this? Microsoft. This is both good and bad, as it generated a wider market for the PC yet lowered the level of knowledge needed to near null.
That's because there are now ten times as many computer users. It used to be that power users were the only users, because computers were expensive and obscure. Now they've become cheap and easy enough to be useful for just about anyone.
One big concern I have about the future of Linux on the desktop is that there is an enormous amount of change associated with very minor improvements in capabilities. I've used Linux as my primary desktop OS for five years, and I have made a living working with Unix-ish operating systems for most of that time. Yet I still spend a lot of time keeping up with the evolution of the kernel, the distributions, XFree86, KDE, GNOME, Mozilla, OperOffice and dozens of other applications that are mostly playing catch-up with Microsoft. I don't mind doing this because it helps keep my skills up to date and because I have a personal interest in seeing Linux gain marketshare. One can hardly expect a non-techie to put forth that effort, however, when he can just stick with a familiar Windows environment that already does everything he needs it to do.
True, but the source-centric nature of Linux's kernel driver model is going to make it difficult for vendors to ship precompiled drivers with their hardware. And I hardly imagine Windows compatibility is going to be a problem for many peripherals in a few years.
Okay, sorry about misreading your original comment. I suppose we're largely in agreement, except that I would point out that employers do have to consider the preferences of their employees to some degree. If using Linux is going to annoy users so much that it hurts their productivity (as would be the case for most business environments right now), then the conversion is not economically feasible. There should be, however, a point in the forseeable future where users *think* they won't be able to work with Linux but will actually accept it once they are pushed into it by management.
So we're counting on sysadmins to force their users into the conversion even when the value proposition isn't there? I want to see Linux succeed on the desktop as much as anyone, but I'm not about to screw over my employer like that.
In my opinion, there is a small subset of corporate desktop environments where Linux would be a good idea right now. But I think it's actually being held back by memory of the big Linux hype (from both journalists and zealots) a couple of years back. Lots of people gave it a shot back then and decided it wasn't good enough for them. Now, even though things have improved, they may not be giving it a fair shot.
I kind of like Quorn, but each patty has something like five pounds of salt in it (I exaggerate, but not by much). And the patties are so small that you really need two to make a meal. Not something I would recommend to people with high blood pressure.
And the mycoprotein used to produce Quorn is related to mushrooms in the same way that athlete's foot fungus is related to mushrooms. I personally have no problem with the concept of synthetic food, but you'd be hard-pressed to pass the stuff off as a "natural" product.
I think normal people do care about bugginess in general, but they don't care about the specific details. Consider that, while the core of a Linux distribution is typically very stable, one will still typically find flakiness with X, the desktop environment or the applications themselves. I am aware that the operating system has not crashed when X locks up, but what difference does that make when restarting X kills all of my desktkop apps? Many open-source apps are less stable than their proprietary cousins, and UI inconsistencies can be just as bad as instability to a normal user.
While I agree that Linux does provide a more reliable foundation than Windows (though 2000 comes close), that simply will not matter to consumers until the entire open-source computing experience is brought up to the same standard.
Basically true, but this new MS shell aims to be more than the current crop of Unix shells. Direct access to.NET objects should make it an incredibly powerful tool. You could theoretically add such capabilities to a Unix shell if a unified object model existed on Unix platforms, but how would you get everyone to agree on such a standard?
Shell pipes and redirection are certainly very useful (due to a quirk in my current project, I have to make extensive use of them in my code), but a stream of text is not a substitute for a real API. I actually think the MS approach will ultimately be the best one for producing quality tools for both the GUI and CLI. Most Unix GUI admin tools suffer as a result of being simple graphical wrappers around existing command-line tools.
I think zsh has similar capabilities. But the point of a reflection API is that you don't have to implement a totally new completion method for every type of command you want to expand. Diversity can lead to innovation, but at some point people need to agree on how things work (e.g., TCP/IP).
Slashdot Mirror
Speaking as someone who was at Wineshopper.com during its fiery demise...
I thought the concept of the company was great, and there were definitely some good people. But the business plan turned out to have nothing in common with reality. Perhaps they might have made it if they'd appeared three years earlier and the money faucet had stayed open long enough for them to find their footing.
6. But this is still a major obstacle to mass deployment. The only good alternative to bundled binary drivers for consumer hardware is to have a strict standard for auto-building a bundled driver from source, and this would require too much inter-distro and inter-desktop cooperation to ever work.
These are two separate issues. I certainly do favor open sourcing drivers wherever possible, but that's no reason to create binary incompatibilities within a "stable" kernel series. It's hard enough keeping the growing pool of drivers up to date without randomly breaking them for no good reason. A semi-stable (obviously you'd have to allow changes within a development series) ABI would make development and deployment of drivers easier, while not hurting the real arguments for open-sourcing those drivers.
I'm reminded of the political situation surrounding transit in the San Francisco area. The bicycle and mass transit lobbies have it in their heads that anything that hurts car drivers must therefore be good for everyone else. So with the support of the city council they've managed to make a bad traffic situation even worse while failing to provide halfway decent public transportation or safe routes for bicyclists.
At my first IT job, I had a department head who preached the idea that users are customers. The results were frequently disastrous, but he didn't care because he didn't have to do any of the hands-on work.
While the sysadmin-user relationship does bear some resemblance to that between service providers and customers, it is definitely not the same thing. You're providing a service, but you're not doing it in exchange for money (at least not from the people receiving the service). And you're both answerable to management. This sometimes results in situations where you have to deny the users what they want so that you can give them what the company needs them to have.
Of course, to do it right you need to have an IT department that gets to know the company's business and works well with other groups. Non-technical (or semi-technical) employees will frequently come up with unreasonable, impractical demands, but they can also be very understanding about being denied if they believe that the decision was made for good reasons. That's why it's very important for IT not to focus purely on minimizing their own workload.
Sysadmins and users working together in harmony...
Not meaning to bash Microsoft (I'm undecided on whether this school thing is a good idea), but you're citing examples of Gates' personal/foundation giving. In that sphere, I think he has done some marvelous, selfless work. Incidentally, I also respect his father's efforts to retain and reform the estate tax. In their private lives, the Gates family is clearly motivated by concerns beyond their own benefit.
Ballmer, on the other hand...
To a degree that's true. Non-IT people certainly don't want to be bothered with learning the details of the systems they work with. What they do want, however, is for IT to be very flexible in responding to requests. A tightly controlled environment is resistant to change, and that sometimes leads to conflict with the users.
Now, I think we agree that centralized management and rigorous change control can seriously reduce the workload on IT. But sometimes exceptions have to be made in order to support business needs. An IT department that clings too tightly to abstract principles tends to forget that its reason for existing is to enable other employees to get their work done.
Huh? Why would professional Linux developers screw up management? In fact, UNIX developers, just like other users, traditionally also appreciate not having to bother with system management, and on UNIX machines, they don't have to. Again, it's only on Windows where every developer needs to become a system manager to make sure their machines have just the right combinations of tools, patches, IDEs, libraries, etc., and get reinstalled every few weeks.
No user like to fix things when they break. But most of them want to be able change things to suit their preferences (thus leading them to break stuff). Most Linux developers are power users, and thus resistant to letting someone else control their workstations. They are, at least, fairly understanding about the need for strict management of the server environment.
It seems that we are in rough agreement as to how IT should control servers. And while I recognize the ideal of total workstation control that you endorse, I don't feel that it is practical (or even desirable) to force every employee of a company to work on the equivalent of a dumb terminal. The pure glass house model may make life easier and more lucrative for IT, but everyone else rebelled against it a long time ago.
Well, that's fine as a general ideal to work towards, but compromises will always have to be made in an organization that isn't entirely composed of IT people. Hell, just adding a few Linux developers to the mix is enough to screw up any tightly controlled management scheme.
And your point is what? That because many people don't know how to run an efficient IT infrastructure, everybody else should screw up in the same way?
You're certainly free to interpret my words that way.
That only works if the workstations are tightly controlled, secured and integrated into the server environment. In a real-world organization with large numbers of loosely-coupled desktops and laptops, such a scheme is really painful to maintain. And probably very insecure. At least SMB doesn't put too much trust in the client.
Building such a connector is clearly a monumental task. I oversaw a test deployment of Bynari Insight Connector a while ago, and I was disturbed to see how kludged together it was. Not only was it a major pain in the ass to configure on a given workstation, but the end product clearly behaved differently than regular Outlook. Needless to say, the project was a non-starter.
I've been meaning to check out Samsung Contact to see if their Outlook integration is any better. It doesn't seem like anyone in the open source world is going to do what it takes to enable such interoperability.
Back when I supported FreeBSD regularly, I remember wishing that Perl were set up as a port/package. Easier to maintain and upgrade separately that way. In general, I was not pleased that the core OS was a monolithic entity that was inconvenient to patch in the field.
I do recall that some people were working on a binary update system for the core distribution, but I don't know whether that went anywhere.
If a software package doesn't come in RPM form, then I usually end up having to build and test my own RPM spec for it. My homegrown software deployment and auditing system (based off cfengine) depends on package information to determine when to install or upgrade a piece of software.
I do have a couple of pieces of software (RT, in particular) that don't easily lend themselves to binary packaging. In those cases I have to document the exact manual build procedure in case I ever have to recreate the machine. That's considerably more work than saying "install everything you're supposed to be running".
Ah, yes. The Amphicane Corps.
Without copyright, you could distribute currently-GPL binaries without source. That would provide an edge if your business was in supporting or customizing said software.
I think what he meant was that soccer players don't carry around as much of the jock mentality because they're not worshipped as gods.
That said, I do think that the barriers to entry are higher for football than for soccer. More equipment is required, the game is more complicated, and the physical requirements are greater. I don't deny that many soccer players are great athletes, but their basic body types tend to bear some resemblance to normal humans. In my youth I was actually reasonably good at soccer, but no amount of training would have given me the size and speed needed to be competitive in football.
Basketball has the same sort of exclusivity, which is probably why it shares the spotlight with football in the U.S. Soccer happens to translate very poorly to television, but I think another factor is that any group of regular citizens can have more fun walking over to the park and playing the game themselves. We're not as fast or as skilled as the professionals, but we're basically doing the same thing. When we watch football and basketball on television, we see the players perform feats that we can't even begin to approximate on our own.
Of course, I am completely unable to come up with an explanation for why people watch baseball on TV.
My statement is truth though, it takes no courage or introspection to beleive what man can say (evolution of man), it takes courage to believe in God and instrospection to understand a higher power.
I would argue the opposite. If God (in something approaching the Christian form) exists, then it takes a lot of the burden off of us as individuals. It's a lot harder to deal with life's helping of moral dillemas when you don't have a higher authority telling you what to do. And if believing in God requires courage, then we're a pretty brave species, because we seem rather inclined to buy into religion.
Of course, whichever way you may swing on that issue, it doesn't necessarily follow that the path which requires more courage is the better one. It would take a lot of courage for me to walk into a police station and try to shoot all of the cops before one of them drops me.
As for your other point, I do agree that most biblical stories have some basis on historical fact. It makes perfect sense that wars, political upheavals and natural disasters were turned into legends. But it also makes sense that our primitive ancestors were inclined to attribute supernatural causes to otherwise mundane events. The tendency to sensationalize events is nothing new to humanity, though CNN and Fox have certainly upped the ante.
Only if you "don't bathe regularly", or "scare little children".
Sadly, it does matter. If you choose MS Office, then you gain compatibility with a much wider range of add-on packages. You also reduce training costs, as it is far more likely that an incoming employee will be familiar with MS Office than any of its competitors.
.DOC file. The odds are overwhelming that the recipient will be able to read it, and you can just deal with the exceptions when they come up (e.g., you notice that the recipient is rms@windowzsucks.com). When I make a phone call within the U.S., I generally don't make preparations for speaking in any language other than English.
And while I do encourage people to use neutral formats for inter-company exchanges, one would hardly be "insane" to e-mail someone a
That's because there are now ten times as many computer users. It used to be that power users were the only users, because computers were expensive and obscure. Now they've become cheap and easy enough to be useful for just about anyone.
One big concern I have about the future of Linux on the desktop is that there is an enormous amount of change associated with very minor improvements in capabilities. I've used Linux as my primary desktop OS for five years, and I have made a living working with Unix-ish operating systems for most of that time. Yet I still spend a lot of time keeping up with the evolution of the kernel, the distributions, XFree86, KDE, GNOME, Mozilla, OperOffice and dozens of other applications that are mostly playing catch-up with Microsoft. I don't mind doing this because it helps keep my skills up to date and because I have a personal interest in seeing Linux gain marketshare. One can hardly expect a non-techie to put forth that effort, however, when he can just stick with a familiar Windows environment that already does everything he needs it to do.
True, but the source-centric nature of Linux's kernel driver model is going to make it difficult for vendors to ship precompiled drivers with their hardware. And I hardly imagine Windows compatibility is going to be a problem for many peripherals in a few years.
Okay, sorry about misreading your original comment. I suppose we're largely in agreement, except that I would point out that employers do have to consider the preferences of their employees to some degree. If using Linux is going to annoy users so much that it hurts their productivity (as would be the case for most business environments right now), then the conversion is not economically feasible. There should be, however, a point in the forseeable future where users *think* they won't be able to work with Linux but will actually accept it once they are pushed into it by management.
So we're counting on sysadmins to force their users into the conversion even when the value proposition isn't there? I want to see Linux succeed on the desktop as much as anyone, but I'm not about to screw over my employer like that.
In my opinion, there is a small subset of corporate desktop environments where Linux would be a good idea right now. But I think it's actually being held back by memory of the big Linux hype (from both journalists and zealots) a couple of years back. Lots of people gave it a shot back then and decided it wasn't good enough for them. Now, even though things have improved, they may not be giving it a fair shot.
I kind of like Quorn, but each patty has something like five pounds of salt in it (I exaggerate, but not by much). And the patties are so small that you really need two to make a meal. Not something I would recommend to people with high blood pressure.
And the mycoprotein used to produce Quorn is related to mushrooms in the same way that athlete's foot fungus is related to mushrooms. I personally have no problem with the concept of synthetic food, but you'd be hard-pressed to pass the stuff off as a "natural" product.
I think normal people do care about bugginess in general, but they don't care about the specific details. Consider that, while the core of a Linux distribution is typically very stable, one will still typically find flakiness with X, the desktop environment or the applications themselves. I am aware that the operating system has not crashed when X locks up, but what difference does that make when restarting X kills all of my desktkop apps? Many open-source apps are less stable than their proprietary cousins, and UI inconsistencies can be just as bad as instability to a normal user.
While I agree that Linux does provide a more reliable foundation than Windows (though 2000 comes close), that simply will not matter to consumers until the entire open-source computing experience is brought up to the same standard.
Shell pipes and redirection are certainly very useful (due to a quirk in my current project, I have to make extensive use of them in my code), but a stream of text is not a substitute for a real API. I actually think the MS approach will ultimately be the best one for producing quality tools for both the GUI and CLI. Most Unix GUI admin tools suffer as a result of being simple graphical wrappers around existing command-line tools.
I think zsh has similar capabilities. But the point of a reflection API is that you don't have to implement a totally new completion method for every type of command you want to expand. Diversity can lead to innovation, but at some point people need to agree on how things work (e.g., TCP/IP).