If the problem is un-costed negative externalities, it seems that the sanest way to fix the problem is to assign prices to the externalities through some sort of political body. I suppose you could do it yourself through viligantism, by assigning a "price" to negative externalities via sabotage or extortion, but that doesn't seem superior.
Most tree farms are on purely private, unregulated land. If it become uneconomical to continue them as tree farms, they'd probably be clear-cut and turned into non-tree farms.
The number of trees saved will probably be around zero, since newsprint's wood source is almost exclusively tree farms. If demand for wood from tree farms decreased, they'd probably be cut down and turned to some other use, like farms of the non-tree variety.
The other environmental effects are trickier to sort out. Paper, as you point out, uses lots of nasty chemicals. But then so does manufacturing electronics, and mining the various metals that go into electronics manufacturing. Disposing of electronics, even when they're recycled (usually in China) is a rather nasty business, too.
It's possible, of course, that Microsoft does hold patents that cover portions of NTFS, which haven't yet been identified as doing so. But the NTFS-3g people at least claim that "no NTFS patent is known in any country".
They want people to use gmail, which is of course the reason they offer it in the first place. They make a significant profit off it, and would lose money if they drove away users.
Unethical, yes, but that's policed, to the extent that it is, by professional communities among themselves. If someone proves an important new theorem, and I claim to prove the same theorem the same way the next month, no reputable math journal would publish my plagiarized paper. But if I put a PDF online, I wouldn't be committing a crime, either.
"When you factor in our short-term trillion dollar deficit and the long-term budgetary crisis that will happen in the next couple decades", even quibbling about money spent on a space MMO is retarded, since it will save approximately 0% of the money you need to come up with to solve that problem.
It's like saying, given how behind we are on our mortgage payments, we really need to use less salt in our cooking, because maybe that $0.92 could go towards the mortgage instead.
Some areas have large surpluses, others have large deficits. One area I'm familiar with with a deficit is anything to do with data analysis, due to the huge piles of data companies like Google and Facebook are building up that they don't do nearly as much with as they could. If you can convince a company that you're both technically competent when it comes to data mining, machine learning, etc., and have knowledge in some area that relates to something to do with it (marketing/customer stuff, artificial intelligence, even just information visualization), there are plenty of jobs.
Actually, in general, the best bet seems to be to have two useful skill areas that intersect in some reasonable way; really cuts down the competition as compared to going up against people in one area or the other in isolation.
One of the selling points of Unix has always been the ability to have multiple user accounts with security policies that prevent them from interacting badly. The problem, of course, is that security holes are relatively frequent. In particular, local security holes, i.e. exploits in any code that ever runs setuid, are quite frequent. That they're so frequent that people don't trust OS security at all, to the point of running separate apps in separate virtual machines, seems like a pretty conclusive determination that OS security policies have failed.
I can't help but think that one alternate route that would've ended up more efficient would be to give in and write more core software using some variety of language not vulnerable to quite as many buffer overflows and stack-smashing attacks. Doesn't have to be some big paradigm switch like using Ocaml; a C-with-some-safety dialect like Cyclone would be fine. Besides inertia, one of the main arguments against was that it adds overhead compared to straight C. But the fact that people are willing to accept a much larger amount of overhead via virtual machines to get more solid guarantees of security that the OS is frankly failing to provide is some indication that the overhead-for-security tradeoff is something people really do want.
There are some advantages to using virtual machines regardless, such as ability to migrate apps separately. But we're using them here in some cases where multiple users on the same OS really would have been the best setup, except for the fact that we don't trust Linux to be free of local-root exploits.
I mostly do that in other languages, too
on
BASH 4.0 Released
·
· Score: 1
Maybe it's a weird way to go about it, but when I write my shell-script-like Perl scripts, I start them out similarly by just building on commands I've already typed, wrapped in system(). Slightly heavier-weight syntax, but not by much, and allows me to use all the rest of Perl, which makes some things easier.
It does provide a portability route if I want one: I can convert all the system("mv whatever") calls to use the proper Perl OS-abstraction libraries. But you don't have to start out with those.
I do find having moderate lightweight programmability in a shell to be useful, for writing one-off things on the command line: things like doing some operation on file_X for X=01 to 99. But for anything more significant, I find myself always writing a Perl script or something.
I know precisely zero people who use OS X as a Unix, though. Many of them were indeed classic Mac users, and most of the rest still use the classic-Mac all-GUI workflow, which is still the one Apple mostly promotes, especially on the desktop.
Maybe that's the issue you had a problem with, but the judge can only really rule on the issue the plaintiffs brought up. Their case did not allege "users getting a POS that wouldn't give them the minimum acceptable user experience". Instead, the case alleged "unjust enrichment" on the part of Microsoft, which requires showing that Microsoft made more money via the allegedly misleading behavior than they would have otherwise.
If they just mailed $X with no solicitation, then sure. But it looks like this was an agreed compensation payment, with the check written for the wrong amount.
Similarly, if I mailed Safeway a $74 check without them soliciting it, they'd be in their rights to cash and keep it. But if I accidentally wrote them a $74 check on a $47 grocery bill during checkout, I'd be within my rights to go with the receipt and ask for the accidental $27 overpayment back.
Generally you do have an obligation to return someone else's property that accidentally came into your possession. You'd be guilty of theft if you knowingly kept it despite knowing that it came into your possession by accident; if you had reason to believe it was legitimately yours, you could plead not guilty to theft, but would probably still have to return it if a court determined it wasn't rightfully yours (i.e. not paid as part of a legitimate contract, or given as a gift). In this case if the employees had signed paperwork specifying a particular amount of money, and they got a larger amount, they would have trouble arguing that they believed it to be anything but an accidental overpayment. I guess you could try arguing that it was a legitimate gift from Microsoft, but I doubt that would succeed.
I've found sort of the opposite in academia
on
Linked In Or Out?
·
· Score: 1
It could be the dynamics of academia versus industry, but I've found Facebook a lot more useful to me professionally. It does have, as you mention, a lot of the fluff and blending of work/personal life. But for the same reason it also more consistently gets updated, and points to unplanned collaboration opportunities.
Most of my colleagues' LinkedIn pages, if they exist at all, are basically like a business card: bare listing of contact info, and maybe employment history. They don't tend to keep them very up to date, either, or remember to ever log in. Many do log in regularly to Facebook, though, because it's part of their social lives. So they'll tend to do things like join groups indicating their current interests, and update their statuses with a mix of irrelevant-to-me personal life things ("X is picking up the kids from trombone lessons") and relevant-to-me things ("X just saw an interesting talk from Y at Conference On Foo"). For the people who use Twitter, that also gives me kind of similar information.
I can see how LinkedIn would be more useful if I ever did more formal hiring, consultant searching, or job application, though.
From an author-making-money perspective, e-books are pretty similar to printed books, because people still buy them on places like Amazon. For a variety of reasons, they haven't developed the same way as newspapers, where the online edition is free. It's easier to grab them free off torrent sites, of course, but I'm not sure that alone will kill the book industry, especially as it seems to be less widespread than unauthorized music copying. The fact that ebook readers like the Kindle make it much easier to buy books from Amazon than load them from some downloaded source will probably only strengthen that.
The most successful recent example in terms of subscribers is probably The Economist newsmagazine, which has had about a 5x increase in subscribers over the past decade.
At the very least, using a C-like language with safety, like Cyclone, would be a reasonable performance/safety tradeoff for a lot of users compared to the current tradeoffs (which leave quite a bit to be desired). I'm guessing the main stumbling block would be reimplementation overhead (Linux already exists in C, has a lot of code, and is a fairly quickly moving target) and lack of interest on the part of kernel hackers (who have little interest in using non-C languages), rather than performance of the resulting system.
Linux threads were relatively heavyweight in early implementations, just about as much so as processes; the current implementation is much lighter weight. So some books still floating around contain that info, since it used to be true.
A sort of separate issue is that, for a variety of reasons, most Linux distros on x86 ship with a default 8MB pthread stack size, which is fairly high--- spawning a mere 50 threads gets you a nice 400MB of control stacks. You can set the stacksize smaller with pthread_attr_setstacksize, and the unused parts of those stacks can mostly live harmlessly in non-resident virtual memory, but it still makes threads seem heavier weight than they ought to seem.
Re: the distribution method, it's mostly that distributing disk images that users have to mount and then manually drag things out of is a bit primitive. Windows typically has.exe or.msi installers that do that part for you. The OS X approach is so unintuitive to most users that many apps distributed as a.dmg have resorted to including symlinks to where you're supposed to drag the thing (usually the Application folder) within the.dmg itself, along with a bit "DRAG THIS HERE" arrow. If that kind of hack isn't a marker of broken design, I don't know what is.
I agree that Windows has some flaws due to lack of dependency management also; it'd be ideal if you could just say "hey this depends on python >= 2.5, make sure that's installed", without the user having to intervene, or every app including its own version of the runtime (I must have 12 copies of Java installed, which is kind of ridiculous). But at least it doesn't pretend to come with things but then fail to keep them managed reasonably: you can depend on Windows not coming with a specially ancient Microsoft Python, so if you want to have a non-bundled option, you can just tell your users, "go download the Python installer from python.org, run it first, then run our installer". On OS X, you can't even do that, because OS X comes with python but doesn't keep it updated, so you have to explain to your users how to install a second copy of python, in a different path, and then point your app to that one.
Windows worked perfectly fine, because it goes the other route, and lets users just run installers for anything they want (oh, and it has installers, not.dmg bullshit); only OS X presented problems. OS X can't decide if it wants users to install and upgrade things, or it wants that to be managed centrally, so you have a mish-mash of both. OS X-installed Python, of one version, user-installed Python, at a different path, of a different version. Neither Windows nor Linux require you to mess with crap like that.
This was a voluntary program in which students brought their own laptops, some of which were OS X. In general, the Linux and Windows laptops presented no problems; the OS X laptops presented difficulties due to lack of a standard user-friendly installation process.
OS X is easier to operate, and is set up to work well with Apple hardware. Those are nice features, and the reason I have an OS X laptop. But it surely isn't easy to administer. It's indeed quite terrible, since there's no package management to speak of.
Ever tried to walk through a classroom of mac-using high-school students how to get pygame installed and working on their OS? Including the proper version of python if their OS X has an old version, PyObjC, and so on? On Debian or Ubuntu, this requires double-clicking "python-pygame" in Synaptic, and all dependencies/upgrades/paths/etc. are handled automatically. In OS X it's a giant pile of manual bullshit.
And god help you if you have to resort to some mish-mash of.dmg installers, fink, and macports.
Slashdot Mirror
If the problem is un-costed negative externalities, it seems that the sanest way to fix the problem is to assign prices to the externalities through some sort of political body. I suppose you could do it yourself through viligantism, by assigning a "price" to negative externalities via sabotage or extortion, but that doesn't seem superior.
Most tree farms are on purely private, unregulated land. If it become uneconomical to continue them as tree farms, they'd probably be clear-cut and turned into non-tree farms.
The number of trees saved will probably be around zero, since newsprint's wood source is almost exclusively tree farms. If demand for wood from tree farms decreased, they'd probably be cut down and turned to some other use, like farms of the non-tree variety.
The other environmental effects are trickier to sort out. Paper, as you point out, uses lots of nasty chemicals. But then so does manufacturing electronics, and mining the various metals that go into electronics manufacturing. Disposing of electronics, even when they're recycled (usually in China) is a rather nasty business, too.
It's possible, of course, that Microsoft does hold patents that cover portions of NTFS, which haven't yet been identified as doing so. But the NTFS-3g people at least claim that "no NTFS patent is known in any country".
They want people to use gmail, which is of course the reason they offer it in the first place. They make a significant profit off it, and would lose money if they drove away users.
Unethical, yes, but that's policed, to the extent that it is, by professional communities among themselves. If someone proves an important new theorem, and I claim to prove the same theorem the same way the next month, no reputable math journal would publish my plagiarized paper. But if I put a PDF online, I wouldn't be committing a crime, either.
"When you factor in our short-term trillion dollar deficit and the long-term budgetary crisis that will happen in the next couple decades", even quibbling about money spent on a space MMO is retarded, since it will save approximately 0% of the money you need to come up with to solve that problem.
It's like saying, given how behind we are on our mortgage payments, we really need to use less salt in our cooking, because maybe that $0.92 could go towards the mortgage instead.
Some areas have large surpluses, others have large deficits. One area I'm familiar with with a deficit is anything to do with data analysis, due to the huge piles of data companies like Google and Facebook are building up that they don't do nearly as much with as they could. If you can convince a company that you're both technically competent when it comes to data mining, machine learning, etc., and have knowledge in some area that relates to something to do with it (marketing/customer stuff, artificial intelligence, even just information visualization), there are plenty of jobs.
Actually, in general, the best bet seems to be to have two useful skill areas that intersect in some reasonable way; really cuts down the competition as compared to going up against people in one area or the other in isolation.
One of the selling points of Unix has always been the ability to have multiple user accounts with security policies that prevent them from interacting badly. The problem, of course, is that security holes are relatively frequent. In particular, local security holes, i.e. exploits in any code that ever runs setuid, are quite frequent. That they're so frequent that people don't trust OS security at all, to the point of running separate apps in separate virtual machines, seems like a pretty conclusive determination that OS security policies have failed.
I can't help but think that one alternate route that would've ended up more efficient would be to give in and write more core software using some variety of language not vulnerable to quite as many buffer overflows and stack-smashing attacks. Doesn't have to be some big paradigm switch like using Ocaml; a C-with-some-safety dialect like Cyclone would be fine. Besides inertia, one of the main arguments against was that it adds overhead compared to straight C. But the fact that people are willing to accept a much larger amount of overhead via virtual machines to get more solid guarantees of security that the OS is frankly failing to provide is some indication that the overhead-for-security tradeoff is something people really do want.
There are some advantages to using virtual machines regardless, such as ability to migrate apps separately. But we're using them here in some cases where multiple users on the same OS really would have been the best setup, except for the fact that we don't trust Linux to be free of local-root exploits.
Maybe it's a weird way to go about it, but when I write my shell-script-like Perl scripts, I start them out similarly by just building on commands I've already typed, wrapped in system(). Slightly heavier-weight syntax, but not by much, and allows me to use all the rest of Perl, which makes some things easier.
It does provide a portability route if I want one: I can convert all the system("mv whatever") calls to use the proper Perl OS-abstraction libraries. But you don't have to start out with those.
I do find having moderate lightweight programmability in a shell to be useful, for writing one-off things on the command line: things like doing some operation on file_X for X=01 to 99. But for anything more significant, I find myself always writing a Perl script or something.
I know precisely zero people who use OS X as a Unix, though. Many of them were indeed classic Mac users, and most of the rest still use the classic-Mac all-GUI workflow, which is still the one Apple mostly promotes, especially on the desktop.
Maybe that's the issue you had a problem with, but the judge can only really rule on the issue the plaintiffs brought up. Their case did not allege "users getting a POS that wouldn't give them the minimum acceptable user experience". Instead, the case alleged "unjust enrichment" on the part of Microsoft, which requires showing that Microsoft made more money via the allegedly misleading behavior than they would have otherwise.
If they just mailed $X with no solicitation, then sure. But it looks like this was an agreed compensation payment, with the check written for the wrong amount.
Similarly, if I mailed Safeway a $74 check without them soliciting it, they'd be in their rights to cash and keep it. But if I accidentally wrote them a $74 check on a $47 grocery bill during checkout, I'd be within my rights to go with the receipt and ask for the accidental $27 overpayment back.
Generally you do have an obligation to return someone else's property that accidentally came into your possession. You'd be guilty of theft if you knowingly kept it despite knowing that it came into your possession by accident; if you had reason to believe it was legitimately yours, you could plead not guilty to theft, but would probably still have to return it if a court determined it wasn't rightfully yours (i.e. not paid as part of a legitimate contract, or given as a gift). In this case if the employees had signed paperwork specifying a particular amount of money, and they got a larger amount, they would have trouble arguing that they believed it to be anything but an accidental overpayment. I guess you could try arguing that it was a legitimate gift from Microsoft, but I doubt that would succeed.
It could be the dynamics of academia versus industry, but I've found Facebook a lot more useful to me professionally. It does have, as you mention, a lot of the fluff and blending of work/personal life. But for the same reason it also more consistently gets updated, and points to unplanned collaboration opportunities.
Most of my colleagues' LinkedIn pages, if they exist at all, are basically like a business card: bare listing of contact info, and maybe employment history. They don't tend to keep them very up to date, either, or remember to ever log in. Many do log in regularly to Facebook, though, because it's part of their social lives. So they'll tend to do things like join groups indicating their current interests, and update their statuses with a mix of irrelevant-to-me personal life things ("X is picking up the kids from trombone lessons") and relevant-to-me things ("X just saw an interesting talk from Y at Conference On Foo"). For the people who use Twitter, that also gives me kind of similar information.
I can see how LinkedIn would be more useful if I ever did more formal hiring, consultant searching, or job application, though.
From an author-making-money perspective, e-books are pretty similar to printed books, because people still buy them on places like Amazon. For a variety of reasons, they haven't developed the same way as newspapers, where the online edition is free. It's easier to grab them free off torrent sites, of course, but I'm not sure that alone will kill the book industry, especially as it seems to be less widespread than unauthorized music copying. The fact that ebook readers like the Kindle make it much easier to buy books from Amazon than load them from some downloaded source will probably only strengthen that.
The most successful recent example in terms of subscribers is probably The Economist newsmagazine, which has had about a 5x increase in subscribers over the past decade.
At the very least, using a C-like language with safety, like Cyclone, would be a reasonable performance/safety tradeoff for a lot of users compared to the current tradeoffs (which leave quite a bit to be desired). I'm guessing the main stumbling block would be reimplementation overhead (Linux already exists in C, has a lot of code, and is a fairly quickly moving target) and lack of interest on the part of kernel hackers (who have little interest in using non-C languages), rather than performance of the resulting system.
Linux threads were relatively heavyweight in early implementations, just about as much so as processes; the current implementation is much lighter weight. So some books still floating around contain that info, since it used to be true.
A sort of separate issue is that, for a variety of reasons, most Linux distros on x86 ship with a default 8MB pthread stack size, which is fairly high--- spawning a mere 50 threads gets you a nice 400MB of control stacks. You can set the stacksize smaller with pthread_attr_setstacksize, and the unused parts of those stacks can mostly live harmlessly in non-resident virtual memory, but it still makes threads seem heavier weight than they ought to seem.
Re: the distribution method, it's mostly that distributing disk images that users have to mount and then manually drag things out of is a bit primitive. Windows typically has .exe or .msi installers that do that part for you. The OS X approach is so unintuitive to most users that many apps distributed as a .dmg have resorted to including symlinks to where you're supposed to drag the thing (usually the Application folder) within the .dmg itself, along with a bit "DRAG THIS HERE" arrow. If that kind of hack isn't a marker of broken design, I don't know what is.
I agree that Windows has some flaws due to lack of dependency management also; it'd be ideal if you could just say "hey this depends on python >= 2.5, make sure that's installed", without the user having to intervene, or every app including its own version of the runtime (I must have 12 copies of Java installed, which is kind of ridiculous). But at least it doesn't pretend to come with things but then fail to keep them managed reasonably: you can depend on Windows not coming with a specially ancient Microsoft Python, so if you want to have a non-bundled option, you can just tell your users, "go download the Python installer from python.org, run it first, then run our installer". On OS X, you can't even do that, because OS X comes with python but doesn't keep it updated, so you have to explain to your users how to install a second copy of python, in a different path, and then point your app to that one.
Windows worked perfectly fine, because it goes the other route, and lets users just run installers for anything they want (oh, and it has installers, not .dmg bullshit); only OS X presented problems. OS X can't decide if it wants users to install and upgrade things, or it wants that to be managed centrally, so you have a mish-mash of both. OS X-installed Python, of one version, user-installed Python, at a different path, of a different version. Neither Windows nor Linux require you to mess with crap like that.
This was a voluntary program in which students brought their own laptops, some of which were OS X. In general, the Linux and Windows laptops presented no problems; the OS X laptops presented difficulties due to lack of a standard user-friendly installation process.
OS X displaced the classic Mac OS in majority desktop usage sometime around 2002, so about 7 years out of a 25-year history.
OS X is easier to operate, and is set up to work well with Apple hardware. Those are nice features, and the reason I have an OS X laptop. But it surely isn't easy to administer. It's indeed quite terrible, since there's no package management to speak of.
Ever tried to walk through a classroom of mac-using high-school students how to get pygame installed and working on their OS? Including the proper version of python if their OS X has an old version, PyObjC, and so on? On Debian or Ubuntu, this requires double-clicking "python-pygame" in Synaptic, and all dependencies/upgrades/paths/etc. are handled automatically. In OS X it's a giant pile of manual bullshit.
And god help you if you have to resort to some mish-mash of .dmg installers, fink, and macports.