You appear to be asking for the impossible. If Linux is to be successful, it will have to change to fit the pressures of the real world, nomatter how flawed the real world is. You appear to be asking for the real world to change its ways to fit Linux. Such an arrogant attitude will only cause Linux's downfall.
The Linux community needs to ask "Why is Microsoft so successful?" and then try to emulate those aspects of Microsofts business strategies that do so.
I suppose that 20 years ago, you would have been spouting nonsense about asking why IBM was so successful and suggesting that companies like Microsoft attempt to do business the way they did because asking the real world to change was too arrogant an attitude.
However, the fact of the matter is that the "real world" did change its practices to match the way that Microsoft expected them to do business and they did so because some companies perceived that it was to their advantage to change and those that did not had trouble competing until they, too, adopted those changes.
Lest you think that was the only time that business practices fundamentally changed as a result of changes in computing technology, the "real world" had changed it's practices about 20 years before that when computers were first introduced to business on a large scale. When the elder Mr. Watson predicted a total world market of a handful of computers, that prediction was based on the assumption that the "real world" would not make changes to the way they did business. It didn't work out that way, now, did it?
Change happens. The "Linux Community" isn't asking anything of the real world. Instead, it's suggesting that, with some changes to the way they think of computing, people in the real world can get more from their information resources than they do by using an older model. This is what the younger Mr. Watson did with IBM in the 50's and ISV's like Lotus and Microsoft did in the 80's and, historically, it isn't a bad thing to suggest. If, of course, what you're suggesting is truly a better way of doing business.
Adam Smith may have talked about great fundamental truths of economics, but it's tough to see how Wealth of Nations says that Linux needs to have a big company doing telephone tech support in order to continue to exist.
Also, it seems to me that Linuxes are typically less willing to try and figure things out their own durn selves than Windowses. In MS desktop OS's once you install your nic driver it goes and FINDS
the darn DNS and gateway and all that shit, which yes I should know but why the hell should I have
to type it in? If Windows can find all that stuff Linux should be able to.
If you're going to complain, you'll have to do better than that.
You seem to believe that Microsoft Products can automatically determine what network they're running in, the DNS servers, the gateway, and so forth, but it isn't true. In order for a windows client to autoconfigure, you need to have a DHCP (Dynamic Host Control Protocol) server on the network. Linux networking drivers can use DHCP, too, and have been able to do that for a couple of years.
snol also wrote:
I'm afraid of the word "compile". I know, I know, you can't get away from it when you have software that has to be compatible between different distros. Probably it's all very easy; now go and convince your mother of that and I'll eat my words. Seriously, maybe APT is as good as everyone says it is; I'm just talking from the experience of four aborted installs.
While there is no reason to be afraid of compiling software, there also isn't any reason to compile software, not with any of the current distributions. I don't usually compile any of the bits of my system, and compiling isn't part of the basic installation process of any Linux distribution or commercial application of which I am aware. (FreeBSD is a different matter, but FreeBSD takes a whole different approach to things and it's not all that hard to type "make install".)
I can do nothing but sympathise with you on your failed installs, but maybe my sympathy is worth something. It usually takes me a couple of days to figure out the installation procedure for a new operating system whether it be Windows NT, FreeBSD, or yet another Linux distribution. While they all ask pretty much the same questions, the wording and context is different enough that the consequences of the choice may not be immediately apparent. I usually treat an install like a particularly easy-to-solve adventure game. If I don't get all the way through it the first time, I can figure out what choices to make different the second time. Or the third. Or...
snol also wrote:
I want things that I need to know about to jump out at me - I don't want to dig through unfamiliar
directories via the command prompt. I want a folder called "Control Panels." Maybe I'm just choosing the wrong distros or something.
Speaking as someone who has done his share of front-line Internet tech support, many people find the Windows "control panel" to be the height of confusing software. I'm glad you've learned to navigate it, but you did have to learn. It didn't "jump out at you" the first time. (Well, maybe it did, but that was unlikely. For most Windows Users, the Control Panel is definitely unfamiliar territory.)
Under Unix-like systems, most everything configuration-wise is under/etc. If looking at that is "digging through unfamiliar directories via the command prompt" then you need to become as familiar with it as you do with your Control Panel. Either that, or familiarize yourself with the mechanisms that you're given for easily manipulating those files. I wouldn't know what they are because I don't want to climb that particular learning curve (not after having climbed the much steeper one to learn about the whole/etc tree) but they're there and many people like them.
Of course, another option to take is the one you took: You can simply not run Linux until you've got a more compelling reason to make the effort. However, Linux and Windows are always going to be different, so those people who define "easy to use" as "works just like Windows" will forever complain about how hard Linux is to setup and use even though, for someone unfamiliar with either, the effort is actually comparable and has been for some time.
Because a company, such as Microsoft can take your work, modify it, not contribute anything back. That's called stealing.
No, that's called the consequences of giving your work away. Accepting the consequence of one's actions is what adults do. In actual fact, however, that situation is highly unlikely to occur in practice. Consider this:
Suppose there's some software that accomplshes some useful purpose and is under active development. For the sake of argument, assume that said software is available under the BSD license which doesn't have a redistribution provision, like the GPL does. Now, suppose that a company modifies the software and then releases it as its own proprietary software. What happens?
Well, since the software is under active development, the company didn't get the source. Instead, it got a snapshot of the source. Presumably, future versions of the freely-available software have various defects fixed and useful features added. In order to stay competitive with newer versions of the free software, the company has to choose between continuously porting the free software, releasing their changes back to the maintainers, or giving up on using the free software.
The cheapest route is to release their changes back to the guys who maintain the free software so that those changes can be automatically included with all new versions. In the case of an ASP, where most of what the company does to add value for its customers has to do with business practices rather than the software itself, you don't even lose revenue by releasing your changes.
To a company that picked either of the other two approaches, I would be tempted to say that if you're going to be doing all the work needed to keep up with the free development, you can have the credit, too, as you'll likely have to work at least as hard as the maintainers of the free version.
For what it's worth, (which is, I admit, not much,) I oppose the proposed new GPL because it tries to solve a problem through a legal document that market forces would solve just as well. Messrs Perens and Stallman are all upset about what should be a non issue.
I routinely upgrade all of the computers that I have running Woody every few days. I first noticed this afternoon when, as a test of a new network card install (replacing an RTL-8139 with a 3Com-SOHO because the RTL-8139 drivers appear to be defective) I did a refresh and, lo and behold, there it was.
However, it would never have occured to me to submit it as news to/.. I mean, other than die-hard deb-heads, such as myself, who cares, and if you're a die-hard deb-head, then you already knew about it.
So how do those people that claim that Microsoft uses lots of undocumented APIs in their applications explain this, then?
Well, since a large part of the WINE effort consists is finding out just what those undocumented API's are, I'm not sure what you need explained. If the Office apps used only documented API calls, they would have been running long ago.
The HURD is really pushing the envelope for "piece of software least likely to ever do anything". It's been in development now for donkey's years and yet it is still only in a state where the only people that can actually set it up and program it are the half a dozen people who actually code for it.
As it happens, I got Debian GNU/Hurd up and running just yesterday. It took about two hours, counting the time it took to install Debian GNU/Linux and the time it took to download the installation.DEB files over a 115K ISDN line.
Of course, I can't actually do anything with it because the kernel is only about 1/3 done and there are essentially no applications available for it. Perhaps if the FSF decided to put their efforts into the Hurd instead of yet another major version of GCC, GNU EMACS, and the GNU LIBC, they would be able to actually finish it to the point where Linux was at kernel V0.10, the version I first used. Some additional stability would be nice, too.
I think I'll reformat the disk and see if I can't get OpenBSD on it.
AC also wrote:
Sorry, but the HURD is nothing more than another piece of Stallmann ego-stroking designed to get back at Linux for not being called GNU/Linux (or "Lignux" or other abominations Stalmann wanted). Just because it isn't ideologically sound enough he's pushing the idea of a new kernel, something which we really don't need.
Ummm, that's not factually accurate. I don't know if the code for the Hurd (the name for the collection of services running under Mach) antedates the arrival of the Linux kernel or not, but the project as a whole has been going on since the early 80's and the overall design of the system has been frozen for at least that long. In other words, the Hurd was not created in response to the success of Linux. It couldn't possibly have been.
However, I do share your doubts as to whether or not they're ever going to finish. They definitely bit off more than they could chew with the Hurd.
I dont give a flying fuck about online music, I dont give a flying fuck about politics, the cuecat, freshmeat, anime, starwars or lego. This site blows harder than it ever has
Well, what topics do you like, and on what online forum do you discuss them? If we're all crying for decent topics to discuss, perhaps you'd like to let us in on your secret.
While you're at it, why did you hang around this long? What makes a site like this interesting is the selection of topics. Complaining about it tends to make the powers that be try to please everyone who complains. Trying to please everyone leads to the sort of corporate least-common-denominator pap that nobody likes.
So, in order to engage in conversation that you like, you need to engage in conversation that you like and ignore the rest. That helps the rest of us, who don't mind discussing the topics that you dislike so intensely.
Would you charger per bit.... per byte?
Would you charge for useage or perhaps throttle back those who used too much bandwidth?
Being in the ISP business, I have a slightly different perspsective on the matter, although I intend to read the full paper, once I get a chance.
The reason that we've never offered a metered service, even though a few people have asked for one in order to reduce their bills, is because we've never considered the work needed to keep track of users usage for billing purposes to be worth the effort.
Two answer your question, there are two broad schemes used. The first is the peak bandwidth scheme (used by those who sell "burstable bandwidth") where you pay for the peak data rate you use usually with some averaging and time dependance. (In the most recent deal proposed to me it wasn't clear to me what the penalties were for exceeding the base rate.)
The second is to simply charge by the bit, possibly with a certain amount provided at the base rate. For example, for 1.5 MB DSL service, you might be given, say, 50 gig per month (which corresponds to a utilization of about 10% of your line's capacity) at the base rate (maybe $10 per month for the bandwidth only.) plus, say, $1 per gig after that. I wouldn't meter outbound traffic at all. There's no point. I also wouldn't meter the traffic from your premise to my equipment, so you can check your mail as often as you'd like or load the Web page that shows your current month's usage without fear that that will put you over your quota.
I'd suspect that even heavy-duty Web surfers and email addicts would have trouble getting anywhere near the base rate, and I'd offer fixed-rate service (maybe $20 per month) for the Napster users and guys who browse the binaries newsgroups.
In my opinion, the key to customer acceptance of this mechanism is twofold. First, you need to offer a fixed rate for those people who want it. As the article points out, many people will pay substantially higher for a fixed-rate service than a variable-rate. Second, you have to make it easy for people to know what their usage rate is.
One reason why people who have cell phones will pay extra for a large flat-rate plan instead of choosing a metered rate plan which might actually cost them less money is uncertainty in their usage. When starting out, most people don't have any idea how much they're going to use their phone. Once they now, then it isn't worth the bother to make the change. Take away that ignorance any fewer people will make that choice. Make it easier to switch and people will.
I will tell you that although I worked out this scheme in some detail, it's not likely to be put in place. That's because the largest part of the cost of providing the service doesn't have anything to do with the upstream bandwidth, which is all this scheme meters.
The $0 software investment represents probably less than 1% of the long term cost of the server. Unless you're talking about a server for the local Girl Scout troop, the software cost is completely irrelevant to the decision.
Actually, a $0 software investment represents exactly zero percent of the long term cost of the server. I'm sure they explained to you how to calculate a percentage of something somewhere in school.
AC also said
And no, companies don't want to hire College dropout Linux zealots to admin their servers. So don't even try to claim Linux servers are cheaper to admin.
You mean they would rather hire college dropout NT zealots, such as yourself, instead? How come the only zealots we read about here on Slashdot are Linux zealots? Probably because the ones doing the writing about Linux zealots are MS zealots with an axe to grind trying to make all Linux users all look like MS-bashing freaks.
How juvenile.
If the $25,000 described as the expense of the software is 1% of the TCO for the system, then the system must have a TCO of $2,500,000. If the lifetime of the system (the only major variable that I don't have here) is 2 years (as would be implied by setting the total cost of software at 2 years because you'll have to pay $25,000 every couple of years if you buy a Microsoft solution) then it's highly unlikely that the bulk of the TCO is administration. At $200,000/year (the cost of a full-time employee with overhead and whatnot that we used at (big company name deleted)) that means that you could pay 6 full-time staff to just to administer that system.
That's too many people. A good, stable system would require two part-time administrators (a primary and a backup, typically, and there won't be all that much administration to do if everything is working properly) so you've still got to account for at least $1,700,000 of your estimated total cost of ownership. I know it eats electricity and A/C and backup tapes, but nearly two megabucks worth over two years?
So, your figures don't add up unless there are other conditions required. I've seen safety-critical systems cost that much, but I've not seen anything that suggests that anything you are talking about is anything other than a heavily-used Web server. Care to add some details so we can determine what the TCO of the competing solutions really is?
Oh, and anyone that thinks a company is going to ignore a $25,000 expenditure simply because it's small WRT the total cost of a project is living in some kind of fantasy world.
The LAST THING the Open Source community needs right now is a major player dropping support for anything.
There are three things that might happen to "the Open Source community" as a result of this.
Nothing.
RedHat loses some mindshare among "the community"
SPARC loses some market share among "the community"
These are listed in my estimate of decreasing likelihood. Most of the people who would care about RedHat dropping a marginal platform use some other distribution or operating system (which is why it's a marginal platform) and most of the people who run SPARCs are probably not running Linux.
In no case does anyone outside of "the Open Source community" even notice that this has happened.
I'm sorry, but I just can't see this particular decision damaging Linux's reputation with the people who don't already use it. I believe that this is definitely a teapot-sized tempest.
Maybe this is more of an application for ipv6's anycast/moble adresses crap?
A packet sent to an anycast address goes to only one of the members. I think that this would be pretty much useless for mass file transfers.
The point behind multicast is to reduce the load on the server by ensuring that it only has to send any given packet once no matter how many receivers there are. That makes it a marvelous method for reducing the peak server load caused by high-demand events like the release of new distributions of Linux. To be sure, there is a lot of work involved in making sure that the packets all get to every destination in order and intact, but in the multicast protocols discussed so far, the bulk of the additional work takes place at the receiver's end and, therefore, does not constitute a performance bottleneck. Think of it as a distributed client for file transfers.
I consider the suggestion to make use of a multicast network (not necessarily the MBONE) to distribute software of general interest to be extremely interesting whether it uses "Class-D" addresses or IPv6.
Hi, I'm the author of the parent post. I can't discuss the NP-19 here, but it will suffice to say that anyone else working at NASA will know what I'm referring to.
If you're not allowed to talk about the NP-19, then you're in violation of federal law mentioning it by name in a public place. Either that, or you're a troll.
I'd have to guess troll. After all, what would someone who, say, builds hardware for training ISS crew or someone who maintains part of JSC's ethernet (which is what the two guys I know who work at NASA do) be able to tell me about some super-secret project? "anyone else working at NASA", indeed.
First of all, I don't appreciate being labeled a troll because I dissed Debian, but I'll bite. Now, I haven't tried 2.2 - we're still running 2.1 - it could be better. But I just don't understand the Debian philosophy of "the more we can fit in, the better it is". Maybe I'm just too much of an old timer to jive with these package things - I don't understand why I should learn yet another package format when source tarballs, gcc, and foo-program --version manage a system perfectly.
You didn't get labelled a troll because you dissed Debian. You got labelled a troll because the person who labelled you a troll couldn't believe you couldn't figure out how to skip over the system type selection simply by saying "I don't want to do this" at the right time. Sure, it may not be obvious what you're telling it to do the first time, but the second time you should remember what it means. Don't be offended just because he's giving you the benefit of the doubt.
The way you deal with the Debian philosophy is to realize that you have control over what you install. Just because Potato comes on three CD's (plus source) doesn't mean that you need to install all three CD's worth of crap. Install nothing at first, and then go back and carefully select what you want. You'll need to learn how to use the slash and backslash keys in dselect and how to search packages for file names at www.debian.org, but it's all in your hands. You have all the control you can handle and maybe then some.
As for being too much of an "old-timer", well, I started using Linux in April of 1992. I've got a boot disk (5.25" floppy) around here that's labelled as "Linux V0.11 Patched" where I had patched the serial drivers to do RTS/CTS handshaking so I could call in to work using the Datarace modem they provided me. (I wrote the patch in the Denver City Hotel, Denver City, TX while I was out looking at the SWEPI CO2 injection project in that part of the world. Ahhh, those were the days!) I go back to when you could neither read nor write MS-DOS disks and you needed shoelace to boot from a hard disk, which was something I never bothered with. You don't get much more of an old-timer than me.
For my own part, I try to avoid installing stuff that isn't packaged because then I become responsible for its maintenance. When I use a packaged distribution, the distribution's maintainers have the responsibility for keeping track of things. Yes, you can install the latest stuff from tarballs now, but are you going to keep on top of what all the latest stuff is until the end of time? That gets to be work and you'd better not skip any steps or you'll wind up with something whose installation requires more of a porting effort than anything else.
Case in point: I have a server that started life as a Slackware-based computer in 1995. Along the way, I've upgraded a lot of the software, and written a chunk of custom software, but a lot of the software never gave me any trouble, so I didn't mess with it. Why should I, when there's a lot of other stuff that needs doing?
Now, I need to install bind 8.2.2p5 because the version that I have seems to have difficulty with AAAA records. Easy, right? You just get the source, unpack it, maybe run./configure, and then type "make" right? Right. Except "make all" causes the compile to go for a while and then stop because one of the source files can't include sys/mbuf.h. None of my computers has a "sys/mbuf.h" file. It must be confused about my operating system.
Let's see. I thought I followed the directions. Let's do it again. Grrr! I'd chuck it all, but this is the primary name server for all the zones we serve and moving it is a can of worms I don't even pretend to want to contemplate.
Think this'll never happen to you? Well, maybe it won't. You might stay on top of things better than I have. However, I've come to appreciate the convenience of an upgradeable distribution in my old age. You may be able to keep track of such things, but I don't have to. Oh, and the command "named --version" doesn't do anything useful that I could see. Just FYI.
The small cell size of ATM is clearly intended for voice traffic rather than data. The interesting thing is that the benefits that ATM is supposed to reap are due to a fixed cell size rather than a small cell size. That means that someone could invent an ATM standard for data traffic with a decent (~2kbytes or so) cell size and it should have the same benefits that are claimed for the current ATM hardware.
I don't have any idea how you do, say, IPv6 over ATM. PPP, maybe?
Fibre Channel is good if you need some of the features like several servers sharing one array or joined arrays in differnet buildings. Otherwise, you can match it for performance and far beat it for cost using old fashioned SCSI.
You know, SCSI can be used to share a disk array among multiple computers. You just have to set the device ID of the interface in all but one of the computers to something other than the default.
However, I wasn't aware that the FC tax was that high compared to the SCSI tax.
decaym also wrote:
I fear that if we don't see some major good developments in the Fibre Channel arena soon, it could end up going the way of ATM.
ATM is not all that unpopular. It's the technology of choice for 0-CIR WAN services with a peak data rate greater than 1.5Mbps. I don't think that fibre channel is all that unpopular, either. In the latest issue of RTC magazine, they talk about using fibre channel for general interfacing to embedded systems because of its low cost, compared to other embedded interfacing methods, and high performance. I think I lean toward agreeing with the opinion I read in SysAdmin, which was that SANs are not yet very important to computing, but they're going to be.
On the other hand, the device in question is designed to fill a different need than that filled by a SAN.
If rackspace can cost $1000/U/month, then don't ya think it would be a good idea to find a better site for the boxen ?
Multiple OC-12s are rather expensave arn't they:-) Seriously that figure is 3 to 4 years old, and for a high bandwidth location with forced air cooling and 3 day battery backup. I don't know what current figues are, I would expect them to be much lower in many places.
My original point was merely that some places are really really expensave, and paying an extra $3500 to save 2U of rack space has a payback time mesured in months (two in this case).
FWIW, yesterday I got a quote from Firstworld for colo service. They're opening a new facility here in Houston, down the street from the Level-3 guys.
Anyway, they want about a grand a month for a 42-U rack with a 12-month contract. Plus bandwidth. (They're charging about the going rate for bandwidth. Of course, you don't have to pay for the local loop, so you can realize a bunch of savings there.) 14- and 21-U racks are also available from them for about 1/3 and 1/2 as much.
Telco colo space is a lot more expensive. I've heard tales of guys paying $100K just to apply for a few units worth of rack space in a SWBell facility.
As for getting in to the business of being a colo provider, well, it's good work if you can swing it. The racks themselves (actually, they use cabinets with locks on them) are fairly inexpensive. However, in addition to the bandwidth requirements (which, on a bit-per-bit basis, don't cost near as much as you might think) you've got to provide power and air conditioning as well as physical site security. You also have to have a fairly substantial building as the key to success in that business is to get lots of customers to each buy their little slice of bandwidth. In CA, you've got to be earthquake resistant, here on the coast, you've got to be hurricane resistant. It takes some money to get started.
While this article is a work of fiction, it speaks of a reality that I have been scared of for some time - no local storage - all storage mus tbe "rented" from a service provider - I'm Scared.
IF---
Amazon is allowed to keep their patent on the "One Click" ordering system.
If Amazon keeps their "One Click" patent, then it expires in 2024 and, it can never be patented again. Y'all have to lose your unreasoning fear of the patent system. It doesn't take ideas out of play forever or even for a particularly long time, even though it may seem forever for you guys still in high school. Fear is not warranted, although some wariness may be.
If Amazon can't hit their profitability target (which I would say is likely, that's why they won't tell anybody what that target is) then they'll likely wind up going under or trying to defend that patent in court. If they go under, their creditors will likely wind up with the patent, which means it'll likely stand until 2024 as nobody is going to want to take on pockets that deep. If they try to defend the patent, many or all of the claims will likely be thrown out due to prior art or obviousness.
Remember that getting a patent is one thing, defending it is another. A patent has no real meaning until it's defended in court. Few, if any, of these software patents that you all are so afraid of ever result in infringement claims and so nobody really knows if the patents on some of the more obvious inventions will stand if challenged. My guess is that they won't.
I'm currently in a couple of conversations on Usenet about the use of alternative programming languages (in other words, "other than C") in business. The claim has been made that the use of certain programming languages can improve programmer productivity by two or three times or even more. I find those claims difficult to swallow.
One main reason I find those claims difficult to swallow is the same reason I have difficulty accepting the supposed benefits of outsourcing: The benefits derived in either case are a reduction in the amount of coding effort, but an awful lot of the effort involved in producing programs goes toward understanding the problem and creating an approach to solve the problem efficiently. That effort cannot be affected by any reduction of the coding cost.
For local programmers, much of the process is left unwritten. For example, the last job I did for my first real employer had this as a specification: "Implement submersible pump control on the gas-flow computer", but it is unrealistic to expect overseas programmers to work from a specification that vague. To make the change to the gas-flow computer, I had to spend an awful lot of time talking to people to find out how it needed to be implemented to work with the SCADA systems that the new firmware was intended to work with. Fortunately, all my experts were nearby and I could schedule meetings for all interested parties to discuss the approaches I could take. Once I understood the problem, the coding went fairly quickly.
It doesn't matter how smart those overseas programmers are and how good they are at writing code that matches the specification if the specification is incomplete or inaccurate. That means that the successful outsourcing project will have lots of extra effort spent on the specification. Additionally, it is necessary to work out management procedures that enable the contractee to determine whether or not the deliverables are what they actually want before it's too late, which just about requires control
while the coders are doing their coding. That's difficult enough when the programmers are in a different building. It's nearly impossible when they're on a different continent.
Finally, I leave you with this thought: Outsourcing may free the programmers from the need to actually write the program, but that just leaves them with the task of writing all the documentation and we all know how much programmers prefer writing documentation to writing programs, right?
For starters, there's one key element missing from the open source movement...since no one owns the software, no one is accountable. I doubt seriously that the mainstream corporate world is going to embrace something for which there is no accountability.
The standard reaction to this objection is: There is no accountability with proprietary software, so why are you requiring it of free software? The reason that it is the standard reaction is because it is so true. The saying "no one ever got fired for buying Microsoft" (which, of course, used to have "IBM" where the "Microsoft" is) just illustrates the point that most companies aren't even going to hold their own employees responsible for bad decisions as long as they're the right bad decisions. If that's the case, why should those businesses hold their vendors responsible for those same bad decisions?
Furthermore, what are the consequences for those vendors? No large software vendor cares what a single customer thinks about their product because, no matter how big the customer is, it represents only a tiny amount of revenue. Whine about W2K all you want, but if you're a Microsoft shop, you'll buy it in the end because it's what Microsoft has to sell you.
symbolic also wrote:
Here's something else to ponder...open source is the way it is now because of the way things are now. Microsoft is the big bad enemy, and Linux is the underdog. Who is to say that the dynamics of open source won't change dramatically if this balance shifts? Right now, open source is a cause. If it hits the mainstream, I posit that it will join the endless clatter of every other mundane process, and since the open source "cause" is no longer an issue, another will have to be identified to take its place.
I haven't checked, but I'd wager that there's at least one person who has written a comment to this article that goes something like "software is just a tool, people should use what makes sense instead of insisting on free software". The problem with that statement is that it implies that everyone using free software is using it despite the fact that it offers less value. Free software users are, from this perspective, cutting of their noses to spite their faces. You repeat that slander here.
However, my view is that software is just a tool and that everyone needs to choose what makes sense for them and I choose to use Linux as my operating system. This choice is not made because free software is some sort of cause celebre, but because it works well in the applications that I have and you can't beat the price, even if you factor in the cost of self-support. I simply don't have the resources to support two operating systems.
In fact, and to more directly address your point, in Support is Not the Issue that the shift to free software is the result of fundamental economic forces similar to those that brought the ISV's to their predominant place in computing. Even if Microsoft goes away completely, free software needs no antagonist to continue to be the best solution for a wide variety of circumstances.
If you read The Mythical Man-Month (which was inspired by the OS/360 debacle) Fred Brooks describes the "second project syndrome" and lists the operating systems that the OS/360 team had worked on before writing OS/360. Too bad my copy's at the house.
Finding the first operating system is a tough job because of the earliest history of computers. Initially, everybody wrote to the "bare metal", the way some embedded systems still do today, but people quickly collected common routines into code libraries that they could reuse. Those code libraries eventually became operating systems and higher-level programming languages.
The problem, of course, is that there is no sharp dividing line between a code library with common conventions for calling the routines within and a primitive operating system. That means that there is a certain arbitrariness about any such selection.
Somehow bad data was entered into the database. A zero was entered into some record by the system admin, says the article.
This caused the application to crash with a divide-by-zero error because of a lack of assertions on input parameters in the application.
The key point is that this was an application failure, it was not an OS failure.
What is surprising is the number of people who claim to be intelligent but cannot understand the distinction.
Do you include yourself in this list?
While it is true that a typo killed the application, the application killed, not just the computer it was running on, but all of the computers needed to run the entire ship.
Now, is that an application error or a system error? Who knows? I wouldn't think that an error in a single application would be able to take out an entire LAN, or even the computer on which it was running without some help from the underlying operating system.
That is why I am dissatisfied with the explanation that the error was an application error and the implication that it would have happened under any operating system.
I'm very curious. How could a piece of software NOT ship with a default password? But I agree. If you install a piece of software and leave all built in admin accounts blank, you'd better have a good excuse on your resume.
Well, two ways that leap to mind are: Passwords that default to some invalid string like "x" in the shadow password file and passwords that the installation program forces you to change. Oh, and of course you could always just disable remote access until it is explicitly set up and have one of the things needed to set up remote access be creating the remote access account. That isn't exactly what you asked for, even though "no default accounts" implies "no default passwords", but it is the way that the Debian PostgreSQL maintainers and, I am lead to believe by other posts, the MySQL people enhance security for their systems.
I actually prefer the first, myself. Yes, the account is set up and ready to go. No, you can't actually use it until you set the password to a valid string. Of course, there is a bit of a support burden as people who don't read the manual try to puzzle out why it doesn't work, but at least you don't have the situation described in the vulnerability where people who didn't read the manual get it to work in a severely compromised way.
mrfiddlehead wrote:
Perhaps, but it's their code, and if they don't want to share it that's their perogative, no?
Well, there are two responses to this. The first is to point out that the whole idea behind copyright is to protect the author's ability to profit from his work in order to encourage him to produce for the good of society. (BTW, the justification for following this rule is that it generally works well. People tend to produce if they can profit from the production.) It is not the purpose of copyright law to prevent people from obtaining copies of a protected work. Therefore, if the author no longer benefits financially from the work, then it is not clear that copyrights are supposed to be used to exercise the prerogative you describe.
The other argument is that the longer the copyright period extends, the less likely it is for people to care about whether or not a copyright is being violated. People who pirate Tommy Dorsey recordings using Napster aren't the reason behind the RIAA's lawsuit, but they make up a goodly chunk of the user base. That means that not sharing older works simply, well, doesn't work. As long as one copy exists in the world, it can be duplicated and, after 28 years or even 14, who really cares? If the copying isn't stopped, then the concept of easement comes into play and copying becomes legal.
It is clear, to me at least, that the copyright system is out of whack. The length of copyright protection is vastly longer than most works need. However, I do not favor fixed-term copyright protection. Instead, I suggest requiring substantial fees to renew copyrights after a fairly short period of free protection. That way, those whose works are still commercially profitable enough to cover the fees can still profit from their work, but the other stuff just doesn't worry about it.
Oh, and while I'm thinking about it, Spider Robinson wrote a story a while back that kind of covers the debate we're holding today. It's called "Melancholy Elephants" which was printed in a collection of the same name. With all the IP-related news recently, it's not been far from my mind.
Slashdot Mirror
I suppose that 20 years ago, you would have been spouting nonsense about asking why IBM was so successful and suggesting that companies like Microsoft attempt to do business the way they did because asking the real world to change was too arrogant an attitude.
However, the fact of the matter is that the "real world" did change its practices to match the way that Microsoft expected them to do business and they did so because some companies perceived that it was to their advantage to change and those that did not had trouble competing until they, too, adopted those changes.
Lest you think that was the only time that business practices fundamentally changed as a result of changes in computing technology, the "real world" had changed it's practices about 20 years before that when computers were first introduced to business on a large scale. When the elder Mr. Watson predicted a total world market of a handful of computers, that prediction was based on the assumption that the "real world" would not make changes to the way they did business. It didn't work out that way, now, did it?
Change happens. The "Linux Community" isn't asking anything of the real world. Instead, it's suggesting that, with some changes to the way they think of computing, people in the real world can get more from their information resources than they do by using an older model. This is what the younger Mr. Watson did with IBM in the 50's and ISV's like Lotus and Microsoft did in the 80's and, historically, it isn't a bad thing to suggest. If, of course, what you're suggesting is truly a better way of doing business.
Adam Smith may have talked about great fundamental truths of economics, but it's tough to see how Wealth of Nations says that Linux needs to have a big company doing telephone tech support in order to continue to exist.
If you're going to complain, you'll have to do better than that.
You seem to believe that Microsoft Products can automatically determine what network they're running in, the DNS servers, the gateway, and so forth, but it isn't true. In order for a windows client to autoconfigure, you need to have a DHCP (Dynamic Host Control Protocol) server on the network. Linux networking drivers can use DHCP, too, and have been able to do that for a couple of years.
snol also wrote:
While there is no reason to be afraid of compiling software, there also isn't any reason to compile software, not with any of the current distributions. I don't usually compile any of the bits of my system, and compiling isn't part of the basic installation process of any Linux distribution or commercial application of which I am aware. (FreeBSD is a different matter, but FreeBSD takes a whole different approach to things and it's not all that hard to type "make install".)
I can do nothing but sympathise with you on your failed installs, but maybe my sympathy is worth something. It usually takes me a couple of days to figure out the installation procedure for a new operating system whether it be Windows NT, FreeBSD, or yet another Linux distribution. While they all ask pretty much the same questions, the wording and context is different enough that the consequences of the choice may not be immediately apparent. I usually treat an install like a particularly easy-to-solve adventure game. If I don't get all the way through it the first time, I can figure out what choices to make different the second time. Or the third. Or...
snol also wrote:
Speaking as someone who has done his share of front-line Internet tech support, many people find the Windows "control panel" to be the height of confusing software. I'm glad you've learned to navigate it, but you did have to learn. It didn't "jump out at you" the first time. (Well, maybe it did, but that was unlikely. For most Windows Users, the Control Panel is definitely unfamiliar territory.)
Under Unix-like systems, most everything configuration-wise is under /etc. If looking at that is "digging through unfamiliar directories via the command prompt" then you need to become as familiar with it as you do with your Control Panel. Either that, or familiarize yourself with the mechanisms that you're given for easily manipulating those files. I wouldn't know what they are because I don't want to climb that particular learning curve (not after having climbed the much steeper one to learn about the whole /etc tree) but they're there and many people like them.
Of course, another option to take is the one you took: You can simply not run Linux until you've got a more compelling reason to make the effort. However, Linux and Windows are always going to be different, so those people who define "easy to use" as "works just like Windows" will forever complain about how hard Linux is to setup and use even though, for someone unfamiliar with either, the effort is actually comparable and has been for some time.
No, that's called the consequences of giving your work away. Accepting the consequence of one's actions is what adults do. In actual fact, however, that situation is highly unlikely to occur in practice. Consider this:
Suppose there's some software that accomplshes some useful purpose and is under active development. For the sake of argument, assume that said software is available under the BSD license which doesn't have a redistribution provision, like the GPL does. Now, suppose that a company modifies the software and then releases it as its own proprietary software. What happens?
Well, since the software is under active development, the company didn't get the source. Instead, it got a snapshot of the source. Presumably, future versions of the freely-available software have various defects fixed and useful features added. In order to stay competitive with newer versions of the free software, the company has to choose between continuously porting the free software, releasing their changes back to the maintainers, or giving up on using the free software.
The cheapest route is to release their changes back to the guys who maintain the free software so that those changes can be automatically included with all new versions. In the case of an ASP, where most of what the company does to add value for its customers has to do with business practices rather than the software itself, you don't even lose revenue by releasing your changes.
To a company that picked either of the other two approaches, I would be tempted to say that if you're going to be doing all the work needed to keep up with the free development, you can have the credit, too, as you'll likely have to work at least as hard as the maintainers of the free version.
For what it's worth, (which is, I admit, not much,) I oppose the proposed new GPL because it tries to solve a problem through a legal document that market forces would solve just as well. Messrs Perens and Stallman are all upset about what should be a non issue.
However, it would never have occured to me to submit it as news to /.. I mean, other than die-hard deb-heads, such as myself, who cares, and if you're a die-hard deb-head, then you already knew about it.
Well, since a large part of the WINE effort consists is finding out just what those undocumented API's are, I'm not sure what you need explained. If the Office apps used only documented API calls, they would have been running long ago.
As it happens, I got Debian GNU/Hurd up and running just yesterday. It took about two hours, counting the time it took to install Debian GNU/Linux and the time it took to download the installation .DEB files over a 115K ISDN line.
Of course, I can't actually do anything with it because the kernel is only about 1/3 done and there are essentially no applications available for it. Perhaps if the FSF decided to put their efforts into the Hurd instead of yet another major version of GCC, GNU EMACS, and the GNU LIBC, they would be able to actually finish it to the point where Linux was at kernel V0.10, the version I first used. Some additional stability would be nice, too.
I think I'll reformat the disk and see if I can't get OpenBSD on it.
AC also wrote:
Ummm, that's not factually accurate. I don't know if the code for the Hurd (the name for the collection of services running under Mach) antedates the arrival of the Linux kernel or not, but the project as a whole has been going on since the early 80's and the overall design of the system has been frozen for at least that long. In other words, the Hurd was not created in response to the success of Linux. It couldn't possibly have been.
However, I do share your doubts as to whether or not they're ever going to finish. They definitely bit off more than they could chew with the Hurd.
Well, what topics do you like, and on what online forum do you discuss them? If we're all crying for decent topics to discuss, perhaps you'd like to let us in on your secret.
While you're at it, why did you hang around this long? What makes a site like this interesting is the selection of topics. Complaining about it tends to make the powers that be try to please everyone who complains. Trying to please everyone leads to the sort of corporate least-common-denominator pap that nobody likes.
So, in order to engage in conversation that you like, you need to engage in conversation that you like and ignore the rest. That helps the rest of us, who don't mind discussing the topics that you dislike so intensely.
Form a union? Like, perhaps, the Texas ISP Association? The same TISPA that David Robertson, the source quoted in the story, is president of?
Nah, that'd never work.
Being in the ISP business, I have a slightly different perspsective on the matter, although I intend to read the full paper, once I get a chance.
The reason that we've never offered a metered service, even though a few people have asked for one in order to reduce their bills, is because we've never considered the work needed to keep track of users usage for billing purposes to be worth the effort.
Two answer your question, there are two broad schemes used. The first is the peak bandwidth scheme (used by those who sell "burstable bandwidth") where you pay for the peak data rate you use usually with some averaging and time dependance. (In the most recent deal proposed to me it wasn't clear to me what the penalties were for exceeding the base rate.)
The second is to simply charge by the bit, possibly with a certain amount provided at the base rate. For example, for 1.5 MB DSL service, you might be given, say, 50 gig per month (which corresponds to a utilization of about 10% of your line's capacity) at the base rate (maybe $10 per month for the bandwidth only.) plus, say, $1 per gig after that. I wouldn't meter outbound traffic at all. There's no point. I also wouldn't meter the traffic from your premise to my equipment, so you can check your mail as often as you'd like or load the Web page that shows your current month's usage without fear that that will put you over your quota.
I'd suspect that even heavy-duty Web surfers and email addicts would have trouble getting anywhere near the base rate, and I'd offer fixed-rate service (maybe $20 per month) for the Napster users and guys who browse the binaries newsgroups.
In my opinion, the key to customer acceptance of this mechanism is twofold. First, you need to offer a fixed rate for those people who want it. As the article points out, many people will pay substantially higher for a fixed-rate service than a variable-rate. Second, you have to make it easy for people to know what their usage rate is.
One reason why people who have cell phones will pay extra for a large flat-rate plan instead of choosing a metered rate plan which might actually cost them less money is uncertainty in their usage. When starting out, most people don't have any idea how much they're going to use their phone. Once they now, then it isn't worth the bother to make the change. Take away that ignorance any fewer people will make that choice. Make it easier to switch and people will.
I will tell you that although I worked out this scheme in some detail, it's not likely to be put in place. That's because the largest part of the cost of providing the service doesn't have anything to do with the upstream bandwidth, which is all this scheme meters.
Actually, a $0 software investment represents exactly zero percent of the long term cost of the server. I'm sure they explained to you how to calculate a percentage of something somewhere in school.
AC also said
You mean they would rather hire college dropout NT zealots, such as yourself, instead? How come the only zealots we read about here on Slashdot are Linux zealots? Probably because the ones doing the writing about Linux zealots are MS zealots with an axe to grind trying to make all Linux users all look like MS-bashing freaks.
How juvenile.
If the $25,000 described as the expense of the software is 1% of the TCO for the system, then the system must have a TCO of $2,500,000. If the lifetime of the system (the only major variable that I don't have here) is 2 years (as would be implied by setting the total cost of software at 2 years because you'll have to pay $25,000 every couple of years if you buy a Microsoft solution) then it's highly unlikely that the bulk of the TCO is administration. At $200,000/year (the cost of a full-time employee with overhead and whatnot that we used at (big company name deleted)) that means that you could pay 6 full-time staff to just to administer that system.
That's too many people. A good, stable system would require two part-time administrators (a primary and a backup, typically, and there won't be all that much administration to do if everything is working properly) so you've still got to account for at least $1,700,000 of your estimated total cost of ownership. I know it eats electricity and A/C and backup tapes, but nearly two megabucks worth over two years?
So, your figures don't add up unless there are other conditions required. I've seen safety-critical systems cost that much, but I've not seen anything that suggests that anything you are talking about is anything other than a heavily-used Web server. Care to add some details so we can determine what the TCO of the competing solutions really is?
Oh, and anyone that thinks a company is going to ignore a $25,000 expenditure simply because it's small WRT the total cost of a project is living in some kind of fantasy world.
Maybe so, but if I could get Linux for my Ascend (DAMMIT!) Max-4000's, I'd probably switch.
There are three things that might happen to "the Open Source community" as a result of this.
These are listed in my estimate of decreasing likelihood. Most of the people who would care about RedHat dropping a marginal platform use some other distribution or operating system (which is why it's a marginal platform) and most of the people who run SPARCs are probably not running Linux.
In no case does anyone outside of "the Open Source community" even notice that this has happened. I'm sorry, but I just can't see this particular decision damaging Linux's reputation with the people who don't already use it. I believe that this is definitely a teapot-sized tempest.
A packet sent to an anycast address goes to only one of the members. I think that this would be pretty much useless for mass file transfers.
The point behind multicast is to reduce the load on the server by ensuring that it only has to send any given packet once no matter how many receivers there are. That makes it a marvelous method for reducing the peak server load caused by high-demand events like the release of new distributions of Linux. To be sure, there is a lot of work involved in making sure that the packets all get to every destination in order and intact, but in the multicast protocols discussed so far, the bulk of the additional work takes place at the receiver's end and, therefore, does not constitute a performance bottleneck. Think of it as a distributed client for file transfers.
I consider the suggestion to make use of a multicast network (not necessarily the MBONE) to distribute software of general interest to be extremely interesting whether it uses "Class-D" addresses or IPv6.
If you're not allowed to talk about the NP-19, then you're in violation of federal law mentioning it by name in a public place. Either that, or you're a troll.
I'd have to guess troll. After all, what would someone who, say, builds hardware for training ISS crew or someone who maintains part of JSC's ethernet (which is what the two guys I know who work at NASA do) be able to tell me about some super-secret project? "anyone else working at NASA", indeed.
You didn't get labelled a troll because you dissed Debian. You got labelled a troll because the person who labelled you a troll couldn't believe you couldn't figure out how to skip over the system type selection simply by saying "I don't want to do this" at the right time. Sure, it may not be obvious what you're telling it to do the first time, but the second time you should remember what it means. Don't be offended just because he's giving you the benefit of the doubt.
The way you deal with the Debian philosophy is to realize that you have control over what you install. Just because Potato comes on three CD's (plus source) doesn't mean that you need to install all three CD's worth of crap. Install nothing at first, and then go back and carefully select what you want. You'll need to learn how to use the slash and backslash keys in dselect and how to search packages for file names at www.debian.org, but it's all in your hands. You have all the control you can handle and maybe then some.
As for being too much of an "old-timer", well, I started using Linux in April of 1992. I've got a boot disk (5.25" floppy) around here that's labelled as "Linux V0.11 Patched" where I had patched the serial drivers to do RTS/CTS handshaking so I could call in to work using the Datarace modem they provided me. (I wrote the patch in the Denver City Hotel, Denver City, TX while I was out looking at the SWEPI CO2 injection project in that part of the world. Ahhh, those were the days!) I go back to when you could neither read nor write MS-DOS disks and you needed shoelace to boot from a hard disk, which was something I never bothered with. You don't get much more of an old-timer than me.
For my own part, I try to avoid installing stuff that isn't packaged because then I become responsible for its maintenance. When I use a packaged distribution, the distribution's maintainers have the responsibility for keeping track of things. Yes, you can install the latest stuff from tarballs now, but are you going to keep on top of what all the latest stuff is until the end of time? That gets to be work and you'd better not skip any steps or you'll wind up with something whose installation requires more of a porting effort than anything else.
Case in point: I have a server that started life as a Slackware-based computer in 1995. Along the way, I've upgraded a lot of the software, and written a chunk of custom software, but a lot of the software never gave me any trouble, so I didn't mess with it. Why should I, when there's a lot of other stuff that needs doing?
Now, I need to install bind 8.2.2p5 because the version that I have seems to have difficulty with AAAA records. Easy, right? You just get the source, unpack it, maybe run ./configure, and then type "make" right? Right. Except "make all" causes the compile to go for a while and then stop because one of the source files can't include sys/mbuf.h. None of my computers has a "sys/mbuf.h" file. It must be confused about my operating system.
Let's see. I thought I followed the directions. Let's do it again. Grrr! I'd chuck it all, but this is the primary name server for all the zones we serve and moving it is a can of worms I don't even pretend to want to contemplate.
Think this'll never happen to you? Well, maybe it won't. You might stay on top of things better than I have. However, I've come to appreciate the convenience of an upgradeable distribution in my old age. You may be able to keep track of such things, but I don't have to. Oh, and the command "named --version" doesn't do anything useful that I could see. Just FYI.
I don't have any idea how you do, say, IPv6 over ATM. PPP, maybe?
You know, SCSI can be used to share a disk array among multiple computers. You just have to set the device ID of the interface in all but one of the computers to something other than the default. However, I wasn't aware that the FC tax was that high compared to the SCSI tax.
decaym also wrote:
ATM is not all that unpopular. It's the technology of choice for 0-CIR WAN services with a peak data rate greater than 1.5Mbps. I don't think that fibre channel is all that unpopular, either. In the latest issue of RTC magazine, they talk about using fibre channel for general interfacing to embedded systems because of its low cost, compared to other embedded interfacing methods, and high performance. I think I lean toward agreeing with the opinion I read in SysAdmin, which was that SANs are not yet very important to computing, but they're going to be.
On the other hand, the device in question is designed to fill a different need than that filled by a SAN.
Anyway, they want about a grand a month for a 42-U rack with a 12-month contract. Plus bandwidth. (They're charging about the going rate for bandwidth. Of course, you don't have to pay for the local loop, so you can realize a bunch of savings there.) 14- and 21-U racks are also available from them for about 1/3 and 1/2 as much.
Telco colo space is a lot more expensive. I've heard tales of guys paying $100K just to apply for a few units worth of rack space in a SWBell facility.
As for getting in to the business of being a colo provider, well, it's good work if you can swing it. The racks themselves (actually, they use cabinets with locks on them) are fairly inexpensive. However, in addition to the bandwidth requirements (which, on a bit-per-bit basis, don't cost near as much as you might think) you've got to provide power and air conditioning as well as physical site security. You also have to have a fairly substantial building as the key to success in that business is to get lots of customers to each buy their little slice of bandwidth. In CA, you've got to be earthquake resistant, here on the coast, you've got to be hurricane resistant. It takes some money to get started.
If Amazon can't hit their profitability target (which I would say is likely, that's why they won't tell anybody what that target is) then they'll likely wind up going under or trying to defend that patent in court. If they go under, their creditors will likely wind up with the patent, which means it'll likely stand until 2024 as nobody is going to want to take on pockets that deep. If they try to defend the patent, many or all of the claims will likely be thrown out due to prior art or obviousness.
Remember that getting a patent is one thing, defending it is another. A patent has no real meaning until it's defended in court. Few, if any, of these software patents that you all are so afraid of ever result in infringement claims and so nobody really knows if the patents on some of the more obvious inventions will stand if challenged. My guess is that they won't.
One main reason I find those claims difficult to swallow is the same reason I have difficulty accepting the supposed benefits of outsourcing: The benefits derived in either case are a reduction in the amount of coding effort, but an awful lot of the effort involved in producing programs goes toward understanding the problem and creating an approach to solve the problem efficiently. That effort cannot be affected by any reduction of the coding cost.
For local programmers, much of the process is left unwritten. For example, the last job I did for my first real employer had this as a specification: "Implement submersible pump control on the gas-flow computer", but it is unrealistic to expect overseas programmers to work from a specification that vague. To make the change to the gas-flow computer, I had to spend an awful lot of time talking to people to find out how it needed to be implemented to work with the SCADA systems that the new firmware was intended to work with. Fortunately, all my experts were nearby and I could schedule meetings for all interested parties to discuss the approaches I could take. Once I understood the problem, the coding went fairly quickly.
It doesn't matter how smart those overseas programmers are and how good they are at writing code that matches the specification if the specification is incomplete or inaccurate. That means that the successful outsourcing project will have lots of extra effort spent on the specification. Additionally, it is necessary to work out management procedures that enable the contractee to determine whether or not the deliverables are what they actually want before it's too late, which just about requires control while the coders are doing their coding. That's difficult enough when the programmers are in a different building. It's nearly impossible when they're on a different continent.
Finally, I leave you with this thought: Outsourcing may free the programmers from the need to actually write the program, but that just leaves them with the task of writing all the documentation and we all know how much programmers prefer writing documentation to writing programs, right?
The standard reaction to this objection is: There is no accountability with proprietary software, so why are you requiring it of free software? The reason that it is the standard reaction is because it is so true. The saying "no one ever got fired for buying Microsoft" (which, of course, used to have "IBM" where the "Microsoft" is) just illustrates the point that most companies aren't even going to hold their own employees responsible for bad decisions as long as they're the right bad decisions. If that's the case, why should those businesses hold their vendors responsible for those same bad decisions?
Furthermore, what are the consequences for those vendors? No large software vendor cares what a single customer thinks about their product because, no matter how big the customer is, it represents only a tiny amount of revenue. Whine about W2K all you want, but if you're a Microsoft shop, you'll buy it in the end because it's what Microsoft has to sell you.
symbolic also wrote:
I haven't checked, but I'd wager that there's at least one person who has written a comment to this article that goes something like "software is just a tool, people should use what makes sense instead of insisting on free software". The problem with that statement is that it implies that everyone using free software is using it despite the fact that it offers less value. Free software users are, from this perspective, cutting of their noses to spite their faces. You repeat that slander here.
However, my view is that software is just a tool and that everyone needs to choose what makes sense for them and I choose to use Linux as my operating system. This choice is not made because free software is some sort of cause celebre, but because it works well in the applications that I have and you can't beat the price, even if you factor in the cost of self-support. I simply don't have the resources to support two operating systems.
In fact, and to more directly address your point, in Support is Not the Issue that the shift to free software is the result of fundamental economic forces similar to those that brought the ISV's to their predominant place in computing. Even if Microsoft goes away completely, free software needs no antagonist to continue to be the best solution for a wide variety of circumstances.
Finding the first operating system is a tough job because of the earliest history of computers. Initially, everybody wrote to the "bare metal", the way some embedded systems still do today, but people quickly collected common routines into code libraries that they could reuse. Those code libraries eventually became operating systems and higher-level programming languages.
The problem, of course, is that there is no sharp dividing line between a code library with common conventions for calling the routines within and a primitive operating system. That means that there is a certain arbitrariness about any such selection.
sheldon wrote:
Do you include yourself in this list?
While it is true that a typo killed the application, the application killed, not just the computer it was running on, but all of the computers needed to run the entire ship.
Now, is that an application error or a system error? Who knows? I wouldn't think that an error in a single application would be able to take out an entire LAN, or even the computer on which it was running without some help from the underlying operating system.
That is why I am dissatisfied with the explanation that the error was an application error and the implication that it would have happened under any operating system.
Well, two ways that leap to mind are: Passwords that default to some invalid string like "x" in the shadow password file and passwords that the installation program forces you to change. Oh, and of course you could always just disable remote access until it is explicitly set up and have one of the things needed to set up remote access be creating the remote access account. That isn't exactly what you asked for, even though "no default accounts" implies "no default passwords", but it is the way that the Debian PostgreSQL maintainers and, I am lead to believe by other posts, the MySQL people enhance security for their systems.
I actually prefer the first, myself. Yes, the account is set up and ready to go. No, you can't actually use it until you set the password to a valid string. Of course, there is a bit of a support burden as people who don't read the manual try to puzzle out why it doesn't work, but at least you don't have the situation described in the vulnerability where people who didn't read the manual get it to work in a severely compromised way.
Perhaps, but it's their code, and if they don't want to share it that's their perogative, no?
Well, there are two responses to this. The first is to point out that the whole idea behind copyright is to protect the author's ability to profit from his work in order to encourage him to produce for the good of society. (BTW, the justification for following this rule is that it generally works well. People tend to produce if they can profit from the production.) It is not the purpose of copyright law to prevent people from obtaining copies of a protected work. Therefore, if the author no longer benefits financially from the work, then it is not clear that copyrights are supposed to be used to exercise the prerogative you describe.
The other argument is that the longer the copyright period extends, the less likely it is for people to care about whether or not a copyright is being violated. People who pirate Tommy Dorsey recordings using Napster aren't the reason behind the RIAA's lawsuit, but they make up a goodly chunk of the user base. That means that not sharing older works simply, well, doesn't work. As long as one copy exists in the world, it can be duplicated and, after 28 years or even 14, who really cares? If the copying isn't stopped, then the concept of easement comes into play and copying becomes legal.
It is clear, to me at least, that the copyright system is out of whack. The length of copyright protection is vastly longer than most works need. However, I do not favor fixed-term copyright protection. Instead, I suggest requiring substantial fees to renew copyrights after a fairly short period of free protection. That way, those whose works are still commercially profitable enough to cover the fees can still profit from their work, but the other stuff just doesn't worry about it.
Oh, and while I'm thinking about it, Spider Robinson wrote a story a while back that kind of covers the debate we're holding today. It's called "Melancholy Elephants" which was printed in a collection of the same name. With all the IP-related news recently, it's not been far from my mind.