A hammer is obvious to use because it has one extremely specific and very simple purpose. We already have plenty of tech devices like that, like digital thermometers, watches, etc. But for anything informational that is more complicated than those things, the ability for the device to be "as obvious as a hammer" is going to become impossible.
That would be that the source code was from its Unix, or that Linux used trade secrets from SCO and that IBM was behind all of this. The issue was never whether Linux is a Unix clone for practical purposes.
That's not at all related to the analogy I drew. The point is simply that there are plenty of systems that we have developed that have become more or less static because they continue to fulfill the needs of the users of the system. In other words, if it ain't broke, don't fix it. Why add colors and other weird things when text will suffice? Nothing has yet come along that can compete with plain text for writing programs. It is flexible, simple to parse by both humans and computers and works everywhere (across different software, different architectures, even on paper or spoken aloud).
I'd rather they put their efforts towards making Ubuntu suck less. Once it actually works and does things people needs, then they can start marketing it for preloading.
Who cares about some silly certification? Linux is for all intents and purposes a Unix and always has been. To call it anything else just because of a certification that nobody but certain government organizations cares about is, at the very least, annoyingly pedantic. It's in the same category as the rantings of those who say "but Linux is just the kernel!"
I'm sure that's it. It's not that Windows runs all the software that people actually use, or that it runs correctly on the computer they buy, or that devices they buy will work with it instead of requiring installation of special programs from God knows where that may or may not work depending on your kernel version, etc. There's plenty of shit on the Windows platform, but at least people who aren't programmers can get work done.
The idea behind patents is that you will release the knowledge behind your product or design to the public ("patent", being the opposite of "latent" means something along the lines of "out in the open") in exchange for a temporary monopoly during which time you can recoup the costs of development. Taking the risk of developing a new technology is thus incentivized because you can be assured that your product won't be ripped off and sold for cheap, preventing you from making any profit (or just breaking even) off of what could have been a potentially expensive period of R&D beforehand. That's why it makes sense to have patents.
It doesn't make sense to patent trivial things, or have patents that take a long time to expire. These squash innovation because they prevent *others* from using new technologies to make even newer technologies. There has to be a balance between slowing innovation slightly and making sure that innovation is not a huge risk.
Linux distros could solve a lot of the dependency problems by simply allowing multiple versions of the same package to be installed side-by-side and including a much larger set of libraries in the default install, which 3rd parties could depend on. Distros might include several different version of glibc, qt, whatever and then app vendors can assume that unless they are using a very old version, their app can install on any distro and just work without requiring a bunch of dependencies to be newly installed as well.
The percent chance of rain problem isn't a problem on your end. The weather folks never define it clearly for the public, so it is really just meaningless. So far as I know, at the NWS, the percent chance is a combination of the amount of forecast area (land) that will expect to see the given precipitation and the forecaster confidence. There are some other guidelines that go into picking any of the 10 categories (0%, 10%, 20%, etc.). In the end, I find it to be meaningless, and instead rely on forecast discussions and model output to determine the nature of the storm and from there extrapolate what "100% chance of rain this afternoon" really means (it might mean 20 minutes of rain for everybody as a thin band of thunderstorm passes through, or it might mean lighter rain all afternoon, or it might mean a lot of showers, but actually no guarantees that any particular location will get rain).
You also have to distinguish between the local weather faces, many of whom don't even have a meteorological degree, and folks at the National Weather Service or AccuWeather or other companies that employ professionals.
The precision problem is a big one. Where I'm from, if there is a winter storm, my area is frequently on the boundary between rain, wintry mix and snow. Determining where the lines between those precipitation types will fall is very difficult and they always get it wrong...not because they suck, but because you can't really know until the stuff is falling out of the sky. No production model has resolution anywhere near on the level of, say, a small city, so there is a lot of estimation and looking at analog storms, etc. Now, of course, from a larger perspective, they do a pretty good job. If the rain/snow line is off by a few miles or tens of miles, it's really not a big deal compared to the size of the storm. But if you live where it was supposed to snow and you get rain, or vice versa, it's a pretty big deal to you and, for all it matters to you, the weathermen failed miserably.
One of the problems I see is that it's not acceptable for weathermen to express uncertainty, or alternate possibilities. They have to make a call, one call. And if they do try, people just misinterpret what they are saying. The reality is that a forecast is actually probabilistic. Any number of scenarios can play out, and a few of them are very likely, and hopefully one of them is considerably more likely than the others. But even if it seems to be a straightforward forecast, no forecast is ever 100% likely. Perhaps the solution, then, is to try to alter communication with the public so that the probabilistic nature of forecasting can be effectively communicated and people can know what to expect (where "know what to expect" means that they expect more than one possible outcome and aware of what the likelihoods for the various outcomes are). Grand task, I know, for the lay population who has enough trouble with a single, non-probabilistic forecast.
What the heck are you talking about? I don't know of any serious x86-based OS that uses anything other than the ring-0/ring-3 split, with most drivers in ring-0. Linux, especially, is fond of this. Windows Vista and especially Windows 7 have moved more driver stuff into userspace, such as graphics drivers.
Of course, the real question is whether putting drivers in ring-1 is really that much of a benefit. The drivers still need access to the hardware, which means they still need special privileges to do that. They still need to be able to handle interrupts, also requiring special privileges. And accessing hardware and interrupts means that system stability can be compromised by the driver...even if it were running ring-3 doing the same stuff. Take a look at the X drivers, which have been almost entirely in userspace, and yet have still managed to cause lock-ups, crashes and instability. Putting drivers in ring-3 is not, ipso facto, a panacea for system stability.
People have to get work done. And unlike in the political sphere, the benefits of software freedom are meager at best and also don't have a strong philosophical basis supporting them. What rights are being violated by not having open source code? What liberties are really being given to everyday users by having source code they can look at and modify? The answer to both those questions is somewhere between "none" and "those of minimal importance" or "only important to a very small subset of the population". Given that OSS has, on the whole, failed to produce good software and has had nearly two decades to do it, I'd say that focusing on freedom and other BS is just going to dig the grave further.
It's not really a pain in the ass. You never access members outside of a class, it's always through properties. So if you see assignment to what looks like a member, it's going to be a property (unless you really do have people writing classes public members). Also, Intellisense will make it clear which is which, so it's really not hard to check at all. I guess if you aren't using Visual Studio it might be more problematic, but then again, if your project isn't using Visual Studio, you probably don't have code written by idiots.
This is a very edge case. And furthermore, properties are nothing more than syntactically compact getters and setters. So as a getter and setter can do weird behavior (such as silently not actually getting or setting), so can properties, but nothing further. If you aren't an asshole, you won't write properties that do strange behavior like what you described above.
And it's not really full operator overloading. It can only modify the assignment operator and in exactly the same ways that getters and setters effectively do. No surprises if you have the slightest clue what a property is.
Strawman because I'm not even saying that you should either use email all the time or use social networking sites all the time. It's not that social networking sites should be rigid, but there's a point past which they simply aren't going to fulfill every need either. If you really require that only certain people see certain things in a very controlled fashion, then use a tool that's better for that. Social networking sites are about putting information out there, not controlling it. They provide privacy settings within reason so that it's not a complete free-for-all. But if that's not enough, then by all means use a mechanism that's actually designed for privacy. Social networking sites are not designed for privacy, they are designed to do open social networking. If you don't want to do that, don't use the site, or limit what you put on the site to things you are comfortable sharing in that fashion. Simple as that. Not black and white at all.
Then use email. It's really easy and you can control exactly who gets to see what.
Don't go on a site whose explicit purpose is to share lots of stuff with lots of people and complain that you can't use it for something completely different. As always in the computer world: use the right tool for the job. If you don't want to use Facebook as a social networking site, then don't use it and use something like email or a personal website that is more appropriate.
Did you really do that? Did you really think that when the article said "Linux needs more documentation" it was referring to the kernel? Regardless of whatever Stallman and a few other fringe folks want us to believe, when someone says "Linux" they mean a distribution, a complete OS plus basic apps, equivalent to a Windows or Mac OS X install. Pretending that they actually meant something else is annoyingly pedantic and will soon be wrong to boot.
Slashdot Mirror
Not anymore it doesn't.
A hammer is obvious to use because it has one extremely specific and very simple purpose. We already have plenty of tech devices like that, like digital thermometers, watches, etc. But for anything informational that is more complicated than those things, the ability for the device to be "as obvious as a hammer" is going to become impossible.
In the US, we have BJs and Dick's Sporting Goods and people are usually fine with those as well.
I'm not sure how you read that from what I said. It was clearly about copyright violation and IP issues, even if they were unfounded.
Of course, I also find it laughable that you would use the SCO case to prove any type of point other than that SCO was out of its mind.
That would be that the source code was from its Unix, or that Linux used trade secrets from SCO and that IBM was behind all of this. The issue was never whether Linux is a Unix clone for practical purposes.
That's not at all related to the analogy I drew. The point is simply that there are plenty of systems that we have developed that have become more or less static because they continue to fulfill the needs of the users of the system. In other words, if it ain't broke, don't fix it. Why add colors and other weird things when text will suffice? Nothing has yet come along that can compete with plain text for writing programs. It is flexible, simple to parse by both humans and computers and works everywhere (across different software, different architectures, even on paper or spoken aloud).
I'd rather they put their efforts towards making Ubuntu suck less. Once it actually works and does things people needs, then they can start marketing it for preloading.
Who cares about some silly certification? Linux is for all intents and purposes a Unix and always has been. To call it anything else just because of a certification that nobody but certain government organizations cares about is, at the very least, annoyingly pedantic. It's in the same category as the rantings of those who say "but Linux is just the kernel!"
Neither has writing English or speaking, but I daresay that's a problem. Sometimes, things just work and there's no need to go changing them.
I'm sure that's it. It's not that Windows runs all the software that people actually use, or that it runs correctly on the computer they buy, or that devices they buy will work with it instead of requiring installation of special programs from God knows where that may or may not work depending on your kernel version, etc. There's plenty of shit on the Windows platform, but at least people who aren't programmers can get work done.
I did said Google searches and everything turned up just fine. Perhaps you aren't being censored, but rather your internet connection sucks?
I hope you were being sarcastic, because Red Hat gives a huge amount back.
The idea behind patents is that you will release the knowledge behind your product or design to the public ("patent", being the opposite of "latent" means something along the lines of "out in the open") in exchange for a temporary monopoly during which time you can recoup the costs of development. Taking the risk of developing a new technology is thus incentivized because you can be assured that your product won't be ripped off and sold for cheap, preventing you from making any profit (or just breaking even) off of what could have been a potentially expensive period of R&D beforehand. That's why it makes sense to have patents.
It doesn't make sense to patent trivial things, or have patents that take a long time to expire. These squash innovation because they prevent *others* from using new technologies to make even newer technologies. There has to be a balance between slowing innovation slightly and making sure that innovation is not a huge risk.
Linux distros could solve a lot of the dependency problems by simply allowing multiple versions of the same package to be installed side-by-side and including a much larger set of libraries in the default install, which 3rd parties could depend on. Distros might include several different version of glibc, qt, whatever and then app vendors can assume that unless they are using a very old version, their app can install on any distro and just work without requiring a bunch of dependencies to be newly installed as well.
The percent chance of rain problem isn't a problem on your end. The weather folks never define it clearly for the public, so it is really just meaningless. So far as I know, at the NWS, the percent chance is a combination of the amount of forecast area (land) that will expect to see the given precipitation and the forecaster confidence. There are some other guidelines that go into picking any of the 10 categories (0%, 10%, 20%, etc.). In the end, I find it to be meaningless, and instead rely on forecast discussions and model output to determine the nature of the storm and from there extrapolate what "100% chance of rain this afternoon" really means (it might mean 20 minutes of rain for everybody as a thin band of thunderstorm passes through, or it might mean lighter rain all afternoon, or it might mean a lot of showers, but actually no guarantees that any particular location will get rain).
You also have to distinguish between the local weather faces, many of whom don't even have a meteorological degree, and folks at the National Weather Service or AccuWeather or other companies that employ professionals.
The precision problem is a big one. Where I'm from, if there is a winter storm, my area is frequently on the boundary between rain, wintry mix and snow. Determining where the lines between those precipitation types will fall is very difficult and they always get it wrong...not because they suck, but because you can't really know until the stuff is falling out of the sky. No production model has resolution anywhere near on the level of, say, a small city, so there is a lot of estimation and looking at analog storms, etc. Now, of course, from a larger perspective, they do a pretty good job. If the rain/snow line is off by a few miles or tens of miles, it's really not a big deal compared to the size of the storm. But if you live where it was supposed to snow and you get rain, or vice versa, it's a pretty big deal to you and, for all it matters to you, the weathermen failed miserably.
One of the problems I see is that it's not acceptable for weathermen to express uncertainty, or alternate possibilities. They have to make a call, one call. And if they do try, people just misinterpret what they are saying. The reality is that a forecast is actually probabilistic. Any number of scenarios can play out, and a few of them are very likely, and hopefully one of them is considerably more likely than the others. But even if it seems to be a straightforward forecast, no forecast is ever 100% likely. Perhaps the solution, then, is to try to alter communication with the public so that the probabilistic nature of forecasting can be effectively communicated and people can know what to expect (where "know what to expect" means that they expect more than one possible outcome and aware of what the likelihoods for the various outcomes are). Grand task, I know, for the lay population who has enough trouble with a single, non-probabilistic forecast.
They typically do really well, actually. People just remember the abject failures and overgeneralize.
What the heck are you talking about? I don't know of any serious x86-based OS that uses anything other than the ring-0/ring-3 split, with most drivers in ring-0. Linux, especially, is fond of this. Windows Vista and especially Windows 7 have moved more driver stuff into userspace, such as graphics drivers.
Of course, the real question is whether putting drivers in ring-1 is really that much of a benefit. The drivers still need access to the hardware, which means they still need special privileges to do that. They still need to be able to handle interrupts, also requiring special privileges. And accessing hardware and interrupts means that system stability can be compromised by the driver...even if it were running ring-3 doing the same stuff. Take a look at the X drivers, which have been almost entirely in userspace, and yet have still managed to cause lock-ups, crashes and instability. Putting drivers in ring-3 is not, ipso facto, a panacea for system stability.
People have to get work done. And unlike in the political sphere, the benefits of software freedom are meager at best and also don't have a strong philosophical basis supporting them. What rights are being violated by not having open source code? What liberties are really being given to everyday users by having source code they can look at and modify? The answer to both those questions is somewhere between "none" and "those of minimal importance" or "only important to a very small subset of the population". Given that OSS has, on the whole, failed to produce good software and has had nearly two decades to do it, I'd say that focusing on freedom and other BS is just going to dig the grave further.
It's not really a pain in the ass. You never access members outside of a class, it's always through properties. So if you see assignment to what looks like a member, it's going to be a property (unless you really do have people writing classes public members). Also, Intellisense will make it clear which is which, so it's really not hard to check at all. I guess if you aren't using Visual Studio it might be more problematic, but then again, if your project isn't using Visual Studio, you probably don't have code written by idiots.
This is a very edge case. And furthermore, properties are nothing more than syntactically compact getters and setters. So as a getter and setter can do weird behavior (such as silently not actually getting or setting), so can properties, but nothing further. If you aren't an asshole, you won't write properties that do strange behavior like what you described above. And it's not really full operator overloading. It can only modify the assignment operator and in exactly the same ways that getters and setters effectively do. No surprises if you have the slightest clue what a property is.
It can. You can send stuff via messages to a select set of people.
Strawman because I'm not even saying that you should either use email all the time or use social networking sites all the time. It's not that social networking sites should be rigid, but there's a point past which they simply aren't going to fulfill every need either. If you really require that only certain people see certain things in a very controlled fashion, then use a tool that's better for that. Social networking sites are about putting information out there, not controlling it. They provide privacy settings within reason so that it's not a complete free-for-all. But if that's not enough, then by all means use a mechanism that's actually designed for privacy. Social networking sites are not designed for privacy, they are designed to do open social networking. If you don't want to do that, don't use the site, or limit what you put on the site to things you are comfortable sharing in that fashion. Simple as that. Not black and white at all.
Then use email. It's really easy and you can control exactly who gets to see what. Don't go on a site whose explicit purpose is to share lots of stuff with lots of people and complain that you can't use it for something completely different. As always in the computer world: use the right tool for the job. If you don't want to use Facebook as a social networking site, then don't use it and use something like email or a personal website that is more appropriate.
Did you really do that? Did you really think that when the article said "Linux needs more documentation" it was referring to the kernel? Regardless of whatever Stallman and a few other fringe folks want us to believe, when someone says "Linux" they mean a distribution, a complete OS plus basic apps, equivalent to a Windows or Mac OS X install. Pretending that they actually meant something else is annoyingly pedantic and will soon be wrong to boot.