Red Hat does not put out beta code an call it production.
Yes, lets just forget Red Hat's inclusion of GCC 2.96. Though I personally don't have evidence backing the grandparent's post, I wouldn't put it past Red Hat given their past history.
I think what you, and really PJ, seem to ignore is that Linux is very open ended (tons more than a Mac, much more than a Windows machine). The fact is, you have a lot of small tools that each their own job well. The result is you, the user, have to realize you can take tools x to z to do some task. There really doesn't *exist* a means, yet, to graphically paradigm all the components necessary together to do the one task, let alone to do it repetitively, with mutations, and with conditions.
Now, to some extent PJ realizes there's no GUI to do the job, so you have to use the command-line, but then she wants to know what tools to do what. That's great, in theory, if everyone keeps wanting to do the same thing (and then someone could just make a hardcoded gui to do the task), but PJ is basically asking computer engineers to do the equivalent of what hardware engineers can't even begin to do (just try to get a single location storing all the various ways you can hook up various physical tools to do some job).
In fact, in an attempt to prevent people from having to learn a billion different tools, whole languages have evolved in an attempt to simplify a lot of tasks while generally giving up a bit of flexibility. But, then you're talking about teaching every single person one or more scripting languages. I'm not against the idea in utter theory, but *none* of it is practical to fulfill the needs of usability. Entire volumes of books could try to guide you how to do task x with a collection of tools, and I'm sure people can buy them up. But, one place for them all to be freely used? For the most part, the job really *is* that of the user to learn the necessary tools and to use them to do some task..or to do it all manually with a few gui tools which were never designed for the job.
The biggest thing that Linux really needs, then, is better descriptions of what tools do and how to use them. For the most part, that just means a better search tool than "apropos". Man pages, generally, are actually pretty good at providing concise details, examples, etc (exception on the monoliths *cough*bash*cough*). To this end, I agree. It'd also be nice to have a who tool to look up famous people, while we're at it. Provide a good gateway for people to learn what tools do what, and then let them read and toy with information from mans until the do the task. And maybe they'll have to learn a scripting language. The important part about usability isn't quick to learn, it's easy to learn. I think man pages, generally, do provide a good framework for that. They're just not a complete one (howtos come to mind).
>>There are no DirecTV thieves. And if there are, then the police should track down the people who stole equipment or other property from DirecTV and make them return it (in addition to facing charges).
>Much to IP pirates' dismay, just like "piracy" and a million other words in English, "theft" has acquired a new definition thanks to usage. Copyright violation is Theft
Too bad that it's not copyright violation. How, you ask? Simple. Imagine a company that buys water from the local city, purifies it, then funnels the water into the local river. Instead of charging for the water itself, they'd charge a monthly fee for little plastic cups. However, some people are bringing their own cups, and the company doesn't like that so it pushes to have laws passed that even though it's using public property and dumping its product on a public space, only people who rent its cups can use the product.
If it was the other way around, and people were making up fake cards to get a drink from a otherwise closed tap, you'd have a point. Then it'd just be fraud.
So, instead of 9999% markup, it's only now 1999%? They're really shaking in their boots.. And security? If Microsoft didn't at least play lipservice, people might just jump ship to Apple (or more lately, other commercial *nixes for servers) even if it were really, really hard. Unless you're a government backed monopoly, you have to worry at least a little about PR just in case someone comes along. I don't think Linux or GNU has had much effect on the desktop, yet. Now, Linux in the server environment...
So, your solution to fixing the drawbacks of GNUCash over a commercial system is to:
Fix it yourself
There's nothing really that makes GNUCash unusable as a commercial system. Maybe you meant a closed source, commercial backed system?
Right. This is so typical of open-source philosiphy. Believe it or not, you typical user *does not* want to hear rants about *why* GNUCash doesn't do what they want.
They also don't want tax software to write into the beginning section of the hard drive so they, legal buyers, can be treated like criminals. And really, the answer to GNUCash is exactly what the grandparent said, either the world has to go to a single tax system and developers can support that or developers can write per-country plugins. And those developers can sell those plugins.
That's why commercial software remains more popular. Intuit doesn't tell its users that the features they want are trivial. They don't tell their users to "do it themselves". Their product has to *sell*, so they can't tell their users to bug off.
What's your metric of more popular? More sales? GNUCash, I doubt, is selling. It's also not even *trying* to compete with Intuit. Someone could come along, take GNUCash, spruce it up, and start selling it just like the rest of commercial software. I doubt they'd last calling problems their customers requested trivial. On the other hand, the grandparent post never *said* it was trivial.:)
Sorry, but Linux is not ready for primetime if this is what the software situation is like.
That's a pretty amazing extrapolation. If enough people start using Linux, what makes you think Intuit won't sell a Linux version of their software? Or is all that freeware Windows software a huge detriment to the Windows platform because they're not at all required to be responsive to what users want?
Someone was stating that the accounting software was severely lacking in Linux. Someone else stated that GNUCash might be a solution.
Well, it *might* be a solution, for some people. Like the grandparent was saying, Germany might be a place where it'd be good.
Evidently, it isn't a very good one. Particularly not if the developers have an attitude anything like the parent.
What's wrong with wanting a few users (since it's not like every single user is going to be coding) who want something to work at it? If you have a million users, you might only get 10 or 20 people who are willing to help work on it. Pointing out that more help would be appreciated is hardly an attitude. And for all those users who *can't* fix it, well, the whole "fix it" wasn't towards you. Or are all commands given to you a challenge to your being which can't be just brushed aside if they're not meant towards you.
In any case, given the rate at which tax programs come and go, I'd think that gnucash would be a good accounting software package and some company could come along and just sell tax software for Linux just like Windows. If you're not happy with there not being tax software on Linux yet, *bug Intuit*. Maybe they'll not call your problem trivial and they'll do something. Then you can vote with your money for what you think is the best software and leave open source software to do whatever it does instead of acting outraged it's not doing what you want.
IANAL, either, but I think you're reading too much into it. For starters, you have a right to use any legally possession (just general common law and was set firmly in stone in First Sale Doctrine, at least in the US). Now, use is generally seen as the limited spectrum of using the binary to do something. Maybe code inspection for learning would be covered.. In any case, it's not until the point of distribution that any of this matters.
Until the point of distribution, the license means nothing. When you *do* want to distribute, then you have to agree/disagree with it and "suffer" the consequences. So, all the talk about copy, modify, etc is really just to group all non-use acts as one so they're treated the same. The modify bit, especially, is important because as you noted derivative works are covered under the scope of the original copyright, and the GPL does allow you to distribute derivative works, so it's necessary to make mention of modified works, copies, etc to be covered under the GPL. I don't doubt the mention of "copy" is there to cover the case of personal use copying being struck down possibly in the future so the GPL will be able to extend into that case, if necessary.
This article is not advocating slowing down the security patch cycle; the slashdot title is misleading... the author is advocating slowing down the security patch distribution method.
Part of the patch cycle is the distribution and patching.
He is advocating sending out encrypted versions of a patch, get everyone who is always-connected to the internet to automatically download the encrypted version, and once the downloads per second curve decreases by a certain amount (say 95% or so), then you send out the decryption key. Everyone installs the patch simultaneously; and zero-day exploits have as targets only those systems that do not subscribe to the patch service, and use traditional methods to procure patches.
First, none of this seems to indicate it'd actually help for the *lazy* administrators. Why? Because most lazy admins won't subscribe any more than they'll use auto-update tools. So, the major thing which seems to be the aim of accomplishment is the responsible admins have a shorter interval between patching and when other people can reverse-engineer and make an exploit.
Of course, with something like MS's distributed update service, the patch is d/led once to a server and the patching is done at LAN speeds (the patch has to be sent over the LAN, either way), so the responsible admins should actually patch *sooner*, since at minimal they don't have to get and send the decryption key (nor wait for it).
This is based on the assumption that zero-day exploits reverse engineer patches.
Just so you know, zero-day exploits involve exploiting something *before* the patch is released, so the only possible zero-day exploits would be from reverse engineering a patch is if one of the alpha testers is doing it.
What about hackers taking advantage of the vulnerability in the meantime? What about those "zero-day" exploits? To answer this, we need to know how the researcher/patcher/exploiter cycle really works and the motivations of each party in the cycle. This cycle is where researchers discover vulnerabilities, software companies patch the vulnerabilities and hackers exploit the vulnerabilities.
A cycle is, by definition, a one-directional serial connection that returns to some previous stage. While it doesn't explicitly state that this cycle is the only cycle that exists, his whole solution assumes that it's the only cycle. Otherwise, logically, the exploits would already be in the wild and the best solution would be (*tada*) getting patches out as fast as possible.
In fact, zero-day exploits are based upon the idea of releasing something prior to there being a patch/official release. The day of the patch/official release would be day 1. So, this journalist obviously has a few issues, since he never tries to deal with them.
Except the issue with clickthrough agreements is that there's court cases which set forth First Sale Doctrine which say that even if you end up signing some contract to be allowed to read a book which limits your rights, it's still invalid. I think the whole point was the government grants rights to copyright holders, so the copyright holder's not the ones who have the right to make further restrictions. Ie, it's up to Congress to do that. As far as other things go, pgp key signing is already considered legally binding I think, so...
Well, in the past the RIAA has been convicted of price fixing. It does seem semi-strange that it sounds like all RIAA members are planning on upping their price. And as for your comment about "they don't prevent you from making an album...", I never claimed that wasn't true. There's obvious indie labels out there, as well. Neither of this is relevant, though, if it can be reasonably proven that there was a conspiracy to restraint trade/commerce.
If a single company on a commodity good raises prices, some other company sells the good instead. The only reasonable way, then, for the price to go up is if the supply side for all of them changes which increases their costs and thereby causes all their products to go up in price.
If a single company on a non-commodity good raises prices, there's a certain level of loss of sales based on the elasticity of demand. If there are good substitutes, trade shifts to other companies. If all companies which have good substitute goods for each other conspire to raise prices, then they're restraining trade. The biggest issue, of course, is if the companies conspired. Given that the actual supplies needed to sell the goods (licensing paper, since it's actually Apple, et al whose doing all the hosting work) haven't gone up 25% or more, it's reasonable to guess that all the companies in the RIAA raising their prices are likely conspiring.
At minimal, an investigation in such a situtation is warrented which the FBI might be compelled to pursue if the DOJ were to push them. I, however, am not very optimistic about this situation taking place, so my hypothesis about their being a conspiracy is unlikely to be properly tested.
Your suggestion about doing an album containing cover songs and bring it down to the local record store is interesting. I didn't realize cover songs covered more than allowing performances. However, the discussion is about sales online which seems to have at least a few more obstacles attached with it. It might not be unreasonable to do as you suggested. I personally do not have the capital to fund such a venture nor the musical talent necessary in song production. Beyond that, I don't actually want to make clone CDs of music.
Re:Good for the RIAA. This is capitalism at work.
on
RIAA's Nasty Easter Egg
·
· Score: 2, Insightful
All your argument is is that there are good substitutes for Britney's music. However, most your mentioned substitutes fall into monopolies controlled by other RIAA members. The problem is, when you have a collection of monopolies (copyrighted goods, by definition, are a temporary monopoly granted to the author; each RIAA member, then, is a multi-monpolist) an oligarchy forms. And the RIAA representing all these various companies together make a cartel. The problem is, cartels price fixing is clearly illegal, since all RIAA members charging the same price upon distributors is obviously a conspiracy to restraint trade/commerce (people have fixed income, therefore there will be logically less online music bought) . And you'll notice that book publishers, on the other hand, wouldn't all raise their books prices at the same time unless there was some good reason (like there was a writers strike, or the ink crop (do they still use ink from plants?) had a drought that limits yields) because, as you mentioned, there are substitute goods available for most books which would mean any single publisher upping the price would likely me less profits. Do you think the DOJ is going to do anything about all the RIAA members, though?
Your example, though, isn't at all the same, though. It's more than just a series of stills that make a movie. The stills, when assembled, have to appear fluid enough to be real-life like in appearance. From this, you could argue webcams generally don't make movies. Comics aren't movies either. But, if you put enough stills together you can make a flip-book, which is a really small movie (though admittedly, animated generally).
Well, I never really said that Linux *was* the right tool for the job. Just like freshwater lakes aren't very directly useful for most people who need something to drink. I was just pointing out that Green Hill was complaining more about an idea (OSS) instead of an implementation (Linux), which to me seems very diversionary.
There's nothing stopping someone from taking Linux and stripping it down to core features then going through and verifying each part. And simply the fact that people can add source to *another* tree doesn't really mean anything for the security of your own fork. And Linux is no more innately insecure than any other computer program (though you could always argue that the amount of breakage to make a system secure might disqualify it from still being called its original name), but its stock implementation might not be the easiest to verify.
I'd personally rather see the use of finite state automatons in place whereever possible in place of computer programs, personally. And where computer programs are necessary, I do agree that a minimal program to do the job is easier to verify. In fact, a custom/niche job might work best.
It just seems very strange for Green Hill, realizing how much easier it is for another company/organization to use and verify its own OS, to be complaining about Linux. It's also very strange to claim that OSS is more insecure because it has outside, possibly malicious, help and also claim OSS has an unfair advantage over proprietary software. It'd seem to me the only advantage Linux would have over Green Hills's RTOS, at the moment, is the user (for example, the FAA) can alter the OS without worrying about licensing issues with some company. I'd guess that in a fair market, Green Hill's RTOS would be easier to use and verify than a stock Linux embedded setup. I'd also guess that Green Hill's prices aren't fair, and tweaking Linux to work in place of Green Hill's RTOS might actually be cheaper in the long run (a big hint to this is the massive price number Green Hill claims it cost to verify each line of code). So, overall, it seems like Green Hill is trying desperately to justify its cost with leery suggestions about OSS in general, and Linux as it is right now in particular.
Green Hill seems to be making some unsubstantiated claim that open source isn't held up to the same standards as closed source, and I find that rather funny. I think the real issue is, when Green Hill approaches the FAA or whatever, the FAA will do its own testing of the source. If Green Hill's code is breakable, Green Hill is the one responsible for fixing it. But, if what the FAA is reviewing is open source, it's possible the FAA can just fix the source themselves (and avoid having to pay an outside contractor). So, Green Hill, to avoid the scenario where the FAA might be displeased with Green Hill's RTOS and switch to open source, decides on its *own* to spend $500/$1,000 per line to audit their OS.
In the end, this means to me that Green Hill believes OSS has an unfair advantage. Personally, I think it's perfectly fair for people to offer free software. If Green Hill doesn't like it, tough. Or, they can just make their RTOS so good that the FAA or some other organization will be so impressed they won't bother going over some OSS and possible having to fix bugs or write documentation. Looks like the free market to me.
PS: SAYODF == Self-Analysising Your Own Dog Food; it's like a water bottling plant bitching about there being freshwater lakes because lakes don't have to do their own quality control
Close. It was 14 years plus a 14 year extension possible. I think your talk about the "artists tend to be poorer" is a rather large misconception. For the most part, only people with any significant level of learning could write proficiently enough to author a book. It wasn't until the 19th/20th century that there were folklorists and general widespread literacy improvements that allowed for the poor to write books, so most stories were still told orally for the poor.
During the time between a book starting to be written to the point where sales are enough to live off of, an author needs somewhere to live and eat. There wasn't much of a middle class at the start of the US, so generally that shifts virtually all writers into the comfortably rich. I think all this amounts to most authors of the time having a natural life span around 60 years (ignoring the revolutionary war that shrank writers lives).
However, I don't think that copyright as it was was 14 (+14) years because of the average lifespan of the author. US doctrine doesn't believe the author has any innate right to copyrighted works. In reality, the likelyhood is the 14 (up to 28) year span was more a result of communication lag which could mean it'd take several years before even a popular book to go from one major city to every rich person in even the more rural settings.
Today, it takes literally seconds for most works to go from a major city to a rural setting. While I don't believe a copyright the length of a few days would be sufficient incentive for an author (though it covers news stories well enough), if anything the increase in rate of information transfer should be *decreasing* the length of copyright, not increasing it. The US's adoption of the Berne Convention is to me, an ignorant surrender of a basic ideological difference between given and natural born rights. I truly wish that at some point the US takes measures to reaffirm the basics of what copyright is.
And you can turn that argument around. You are allowed to make a copy of a toaster. But it is too difficult for the average person to do so, which is a natural obstacle. The typical person would rather just spend $20-40 on a new toaster instead of building his own new toaster. Thus, there is an incentive for toaster manufacturers to keep on making toasters.
OTOH, making a copy of a DVD is trivially easy. Shouldn't the manufacturers of DVDs be given an incentive to make DVDs that would otherwise be mass produced and sold from the trunk of a car?
Are you talking about the manufacturers of DVDs or the authors of the content? As far as the actual manufacturers of the physical DVD, I say fuck them. They're in the same area as the toaster. It's only because it's intrinsically hard to make a toaster that toaster makers stay in business. There's no reason to protect the DVD manufacturers.
Now, as for the content, I'd say there's an understandable want to give the author some protection. However, the fact is the law is already *written* to provide some exclusionary rules to this protection (like the archival copy, which seems aimed at libraries). Beyond this is the precedent of First Sale Doctrine which says you have an intrinsic right to use the stuff you buy (in a way, it's sad that it took a court case for IP owners to realize that them selling something then *not* giving you access is paramount to not giving you anything, which obviously goes against the point of copyright (to promote the arts and sciences)). Anyways, back to the issue..
When you do buy a copy of a book, you're not just buying a physical copy of a book, or you'd be allowed to make and sell as many copies as you were physically capable of. More and more, it's the publishers who keep pushing towards the idea of buying the medium in such a way that the copyrighted work is somehow intertwined with it which doesn't work very well since there's no medium that exists that can't have exactly equally meaning in another medium (ie, text on a book or in a computer is the same, music on a cd or in a computer is the same, etc). So, every time it becomes a question of siding with the manufacturer/publisher, I keep asking "how does this benefit this author, and does it make sense". Things like the DMCA only further artificially bind the work and the medium which benefits the publisher the most.
Does buying two copies of a book promote the arts and sciences twice as much? How about if it's given to two people? What if one's just a backup to the other? I just can't see how we can justify giving the author twice as much money because he or his publisher decided to use crapy paper. If I decide to buy the book again because it's easier than bothering with a backup, so be it. But with DVDs and CDs, it's trivial to backup, so there's a real threat to not getting another resale. That's life. If they don't like it, the publisher shouldn't be allowed to rely on law-based artificial restrictions to push more merchandise. And maybe that means more things will be published on hard-to-copy, biodegradable media, but at least then it'll be out in the open and the public can easily boycott it instead of being pressed under government restrictions to comply.
Technically speaking, you can make a backup copy of a magazine, book, etc. Whether the courts consider it fair use or part of archival is a second issue. However, since copyright allows archival for at least libraries and the dmca blocks that, either the dmca has to go, copyright has to be rewritten to overcome this contradiction, or there has to be some means of achieving the ends provided for by the law. Of course, the third still needs the law to be rewritten to get rid of the contradiction (at some point).
I'm not sure why you keep acting like a toaster and a dvd are the same. I'm allowed to make a copy of a toaster. It keeps occuring that the law says I'm not allowed to make a copy of a dvd, except under strict limitations. If I wasn't allowed to make my own toaster or modify it, don't you think I'd want some sort of law providing something in return for that advantage given to toaster makers?
The GPL is about freedom of the user, not freedom of the developer. Unless you only use code you wrote yourself, you'll probably advantage from code under the GPL.
You can make a backup of a magazine, book, etc. You can make a backup of a car manual. The car itself isn't an IP good. If you can't make a backup, you're offering the consumer no means of backing up a work which they have a right to.
Basically, when you buy a copy of a work, you have an infinite time based right to access the work. If there's laws that prevent it, those laws should be deemed unconstitutional. Once a work goes into the public domain, for example, making as many copies as you want so you can be sure you never lose a copy of a work is possible. If laws that prevent such copying of a copyrighted work are upheld, it only makes sense that the copyright owner should be held responsible for either a) continuous distribution so you can buy another copy of the work at any time or b) replacement for the normal wear/tear that occurs on all physically objects.
I'm not sure about (1), but I doubt it (and parts of IIS (for example) runs in the kernel so even if (1) is true, it doesn't help much). (2) is very true, but even though it's non-static, it still might be pretty predictable (at least enough that you could unprotect enough pages to be sure that the stack is infact unprotected). (3) is also true, but my later comment points out that even if (3) is true, you can still run several calls on the stack which still amounts to running malicious code (it's just a lot more limited than running real code). And for (4), only the software stack corruption detection would stop this. Even then, software stack corruption detection (like propolice, which I'm sure MS's software is similar to) can be circumvented. How, you ask?
First, propolice does two things. One, it reorders all the buffers towards the top of the current frame. Second, it includes at compile time a value into the stack to detect overwrite. So, the end result looks like this.
Before returning, each function checks to see if that NNNNNNNN isn't right. Now, this would be *really* great if the number was set at *runtime*, but since it's done at compile time, that means that all executables of the same build would be vulnerable to the same buffer exploit attack. Yes, that does mean that if you have enough varied builds installed, the odds are low that all your machine will be infected (since a worm might be unable to detect the build of your server (hiding version numbers to slow down worms, maybe?) hence unable to craft the proper filler value to not trip the detection software), but for something like Windows, you'll end up having everyone update to the latest version which restores the monoculture. The problem is the same in Linux for distros where you don't build from source (though there are more distros/builds of a version, which does give slightly more protection).
But back to the point, even rearranging the stack to grow up instead of down (therefore making it impossible to overwrite the return address) would prevent smashing data on the stack which could still have bad results. The only real protection is to not use functions (or make functions) that will unlimitedly write to the stack (or the heap). I think having data storage areas prefixed with a size indicator wouldn't be a bad idea, either.
Well, if you ignored that it was the wrong order (since it should be:
[junk][page permission set call address][RWX][page][pointer to code ][code ]
)
The point is you can just write stuff to the stack to do a call which can remove the NX bit from the stack, and then you can continue to run malicious code on the stack.
The only way truely eliminate arbitrary code execution is to mark pages with data non-executable and have a processor level exception thrown when you try to execute code from a data page.
You know, all this work on NX is so *off* it's not funny. Why, you ask? Simply.
Imagine the following is your stack.
[local vars][return address ][local vars]...
Most buffer overflow exploits write code to the local vars and modify the return address to point to it:
[code ][pointer to code ][local vars]...
However, there's nothing stopping this:
[junk][RWX][page][page permission set call][filler][pointer to code ][code ]
Fixing the page permission at startup might help prevent the above, but even then you're not guaranteed that someone can't just do a lot of smart stack modification to run all the stuff they need to start *another* process to do their dirty work.
Of course, just making the stack grow up instead of down would resolve all these problems...but that's not as "efficient".:)
This is one reason why MS is pushing opaque memory. Then you can't, hypothetically, ever crack code since you can't see it. Of course, if there's still buffer overflows, you can still just do some library calling to have the program export its entire contents out somewhere...
Slashdot Mirror
So you wouldn't call Red Hat 7.x production code?
Red Hat does not put out beta code an call it production.
Yes, lets just forget Red Hat's inclusion of GCC 2.96. Though I personally don't have evidence backing the grandparent's post, I wouldn't put it past Red Hat given their past history.
I think what you, and really PJ, seem to ignore is that Linux is very open ended (tons more than a Mac, much more than a Windows machine). The fact is, you have a lot of small tools that each their own job well. The result is you, the user, have to realize you can take tools x to z to do some task. There really doesn't *exist* a means, yet, to graphically paradigm all the components necessary together to do the one task, let alone to do it repetitively, with mutations, and with conditions.
Now, to some extent PJ realizes there's no GUI to do the job, so you have to use the command-line, but then she wants to know what tools to do what. That's great, in theory, if everyone keeps wanting to do the same thing (and then someone could just make a hardcoded gui to do the task), but PJ is basically asking computer engineers to do the equivalent of what hardware engineers can't even begin to do (just try to get a single location storing all the various ways you can hook up various physical tools to do some job).
In fact, in an attempt to prevent people from having to learn a billion different tools, whole languages have evolved in an attempt to simplify a lot of tasks while generally giving up a bit of flexibility. But, then you're talking about teaching every single person one or more scripting languages. I'm not against the idea in utter theory, but *none* of it is practical to fulfill the needs of usability. Entire volumes of books could try to guide you how to do task x with a collection of tools, and I'm sure people can buy them up. But, one place for them all to be freely used? For the most part, the job really *is* that of the user to learn the necessary tools and to use them to do some task..or to do it all manually with a few gui tools which were never designed for the job.
The biggest thing that Linux really needs, then, is better descriptions of what tools do and how to use them. For the most part, that just means a better search tool than "apropos". Man pages, generally, are actually pretty good at providing concise details, examples, etc (exception on the monoliths *cough*bash*cough*). To this end, I agree. It'd also be nice to have a who tool to look up famous people, while we're at it. Provide a good gateway for people to learn what tools do what, and then let them read and toy with information from mans until the do the task. And maybe they'll have to learn a scripting language. The important part about usability isn't quick to learn, it's easy to learn. I think man pages, generally, do provide a good framework for that. They're just not a complete one (howtos come to mind).
>>There are no DirecTV thieves. And if there are, then the police should track down the people who stole equipment or other property from DirecTV and make them return it (in addition to facing charges).
>Much to IP pirates' dismay, just like "piracy" and a million other words in English, "theft" has acquired a new definition thanks to usage. Copyright violation is Theft
Too bad that it's not copyright violation. How, you ask? Simple. Imagine a company that buys water from the local city, purifies it, then funnels the water into the local river. Instead of charging for the water itself, they'd charge a monthly fee for little plastic cups. However, some people are bringing their own cups, and the company doesn't like that so it pushes to have laws passed that even though it's using public property and dumping its product on a public space, only people who rent its cups can use the product.
If it was the other way around, and people were making up fake cards to get a drink from a otherwise closed tap, you'd have a point. Then it'd just be fraud.
So, instead of 9999% markup, it's only now 1999%? They're really shaking in their boots.. And security? If Microsoft didn't at least play lipservice, people might just jump ship to Apple (or more lately, other commercial *nixes for servers) even if it were really, really hard. Unless you're a government backed monopoly, you have to worry at least a little about PR just in case someone comes along. I don't think Linux or GNU has had much effect on the desktop, yet. Now, Linux in the server environment...
So, your solution to fixing the drawbacks of GNUCash over a commercial system is to:
:)
Fix it yourself
There's nothing really that makes GNUCash unusable as a commercial system. Maybe you meant a closed source, commercial backed system?
Right. This is so typical of open-source philosiphy. Believe it or not, you typical user *does not* want to hear rants about *why* GNUCash doesn't do what they want.
They also don't want tax software to write into the beginning section of the hard drive so they, legal buyers, can be treated like criminals. And really, the answer to GNUCash is exactly what the grandparent said, either the world has to go to a single tax system and developers can support that or developers can write per-country plugins. And those developers can sell those plugins.
That's why commercial software remains more popular. Intuit doesn't tell its users that the features they want are trivial. They don't tell their users to "do it themselves". Their product has to *sell*, so they can't tell their users to bug off.
What's your metric of more popular? More sales? GNUCash, I doubt, is selling. It's also not even *trying* to compete with Intuit. Someone could come along, take GNUCash, spruce it up, and start selling it just like the rest of commercial software. I doubt they'd last calling problems their customers requested trivial. On the other hand, the grandparent post never *said* it was trivial.
Sorry, but Linux is not ready for primetime if this is what the software situation is like.
That's a pretty amazing extrapolation. If enough people start using Linux, what makes you think Intuit won't sell a Linux version of their software? Or is all that freeware Windows software a huge detriment to the Windows platform because they're not at all required to be responsive to what users want?
Someone was stating that the accounting software was severely lacking in Linux. Someone else stated that GNUCash might be a solution.
Well, it *might* be a solution, for some people. Like the grandparent was saying, Germany might be a place where it'd be good.
Evidently, it isn't a very good one. Particularly not if the developers have an attitude anything like the parent.
What's wrong with wanting a few users (since it's not like every single user is going to be coding) who want something to work at it? If you have a million users, you might only get 10 or 20 people who are willing to help work on it. Pointing out that more help would be appreciated is hardly an attitude. And for all those users who *can't* fix it, well, the whole "fix it" wasn't towards you. Or are all commands given to you a challenge to your being which can't be just brushed aside if they're not meant towards you.
In any case, given the rate at which tax programs come and go, I'd think that gnucash would be a good accounting software package and some company could come along and just sell tax software for Linux just like Windows. If you're not happy with there not being tax software on Linux yet, *bug Intuit*. Maybe they'll not call your problem trivial and they'll do something. Then you can vote with your money for what you think is the best software and leave open source software to do whatever it does instead of acting outraged it's not doing what you want.
IANAL, either, but I think you're reading too much into it. For starters, you have a right to use any legally possession (just general common law and was set firmly in stone in First Sale Doctrine, at least in the US). Now, use is generally seen as the limited spectrum of using the binary to do something. Maybe code inspection for learning would be covered.. In any case, it's not until the point of distribution that any of this matters.
Until the point of distribution, the license means nothing. When you *do* want to distribute, then you have to agree/disagree with it and "suffer" the consequences. So, all the talk about copy, modify, etc is really just to group all non-use acts as one so they're treated the same. The modify bit, especially, is important because as you noted derivative works are covered under the scope of the original copyright, and the GPL does allow you to distribute derivative works, so it's necessary to make mention of modified works, copies, etc to be covered under the GPL. I don't doubt the mention of "copy" is there to cover the case of personal use copying being struck down possibly in the future so the GPL will be able to extend into that case, if necessary.
We use rocks to computer (silicon). We have paper storage (mentioned above). And scissors..err..are metal? I guess they're part of computing too..
This article is not advocating slowing down the security patch cycle; the slashdot title is misleading... the author is advocating slowing down the security patch distribution method.
Part of the patch cycle is the distribution and patching.
He is advocating sending out encrypted versions of a patch, get everyone who is always-connected to the internet to automatically download the encrypted version, and once the downloads per second curve decreases by a certain amount (say 95% or so), then you send out the decryption key. Everyone installs the patch simultaneously; and zero-day exploits have as targets only those systems that do not subscribe to the patch service, and use traditional methods to procure patches.
First, none of this seems to indicate it'd actually help for the *lazy* administrators. Why? Because most lazy admins won't subscribe any more than they'll use auto-update tools. So, the major thing which seems to be the aim of accomplishment is the responsible admins have a shorter interval between patching and when other people can reverse-engineer and make an exploit.
Of course, with something like MS's distributed update service, the patch is d/led once to a server and the patching is done at LAN speeds (the patch has to be sent over the LAN, either way), so the responsible admins should actually patch *sooner*, since at minimal they don't have to get and send the decryption key (nor wait for it).
This is based on the assumption that zero-day exploits reverse engineer patches.
Just so you know, zero-day exploits involve exploiting something *before* the patch is released, so the only possible zero-day exploits would be from reverse engineering a patch is if one of the alpha testers is doing it.
From the article:
What about hackers taking advantage of the vulnerability in the meantime? What about those "zero-day" exploits? To answer this, we need to know how the researcher/patcher/exploiter cycle really works and the motivations of each party in the cycle. This cycle is where researchers discover vulnerabilities, software companies patch the vulnerabilities and hackers exploit the vulnerabilities.
A cycle is, by definition, a one-directional serial connection that returns to some previous stage. While it doesn't explicitly state that this cycle is the only cycle that exists, his whole solution assumes that it's the only cycle. Otherwise, logically, the exploits would already be in the wild and the best solution would be (*tada*) getting patches out as fast as possible.
In fact, zero-day exploits are based upon the idea of releasing something prior to there being a patch/official release. The day of the patch/official release would be day 1. So, this journalist obviously has a few issues, since he never tries to deal with them.
Except the issue with clickthrough agreements is that there's court cases which set forth First Sale Doctrine which say that even if you end up signing some contract to be allowed to read a book which limits your rights, it's still invalid. I think the whole point was the government grants rights to copyright holders, so the copyright holder's not the ones who have the right to make further restrictions. Ie, it's up to Congress to do that. As far as other things go, pgp key signing is already considered legally binding I think, so...
Well, in the past the RIAA has been convicted of price fixing. It does seem semi-strange that it sounds like all RIAA members are planning on upping their price. And as for your comment about "they don't prevent you from making an album...", I never claimed that wasn't true. There's obvious indie labels out there, as well. Neither of this is relevant, though, if it can be reasonably proven that there was a conspiracy to restraint trade/commerce.
If a single company on a commodity good raises prices, some other company sells the good instead. The only reasonable way, then, for the price to go up is if the supply side for all of them changes which increases their costs and thereby causes all their products to go up in price.
If a single company on a non-commodity good raises prices, there's a certain level of loss of sales based on the elasticity of demand. If there are good substitutes, trade shifts to other companies. If all companies which have good substitute goods for each other conspire to raise prices, then they're restraining trade. The biggest issue, of course, is if the companies conspired. Given that the actual supplies needed to sell the goods (licensing paper, since it's actually Apple, et al whose doing all the hosting work) haven't gone up 25% or more, it's reasonable to guess that all the companies in the RIAA raising their prices are likely conspiring.
At minimal, an investigation in such a situtation is warrented which the FBI might be compelled to pursue if the DOJ were to push them. I, however, am not very optimistic about this situation taking place, so my hypothesis about their being a conspiracy is unlikely to be properly tested.
Your suggestion about doing an album containing cover songs and bring it down to the local record store is interesting. I didn't realize cover songs covered more than allowing performances. However, the discussion is about sales online which seems to have at least a few more obstacles attached with it. It might not be unreasonable to do as you suggested. I personally do not have the capital to fund such a venture nor the musical talent necessary in song production. Beyond that, I don't actually want to make clone CDs of music.
All your argument is is that there are good substitutes for Britney's music. However, most your mentioned substitutes fall into monopolies controlled by other RIAA members. The problem is, when you have a collection of monopolies (copyrighted goods, by definition, are a temporary monopoly granted to the author; each RIAA member, then, is a multi-monpolist) an oligarchy forms. And the RIAA representing all these various companies together make a cartel. The problem is, cartels price fixing is clearly illegal, since all RIAA members charging the same price upon distributors is obviously a conspiracy to restraint trade/commerce (people have fixed income, therefore there will be logically less online music bought) . And you'll notice that book publishers, on the other hand, wouldn't all raise their books prices at the same time unless there was some good reason (like there was a writers strike, or the ink crop (do they still use ink from plants?) had a drought that limits yields) because, as you mentioned, there are substitute goods available for most books which would mean any single publisher upping the price would likely me less profits. Do you think the DOJ is going to do anything about all the RIAA members, though?
Your example, though, isn't at all the same, though. It's more than just a series of stills that make a movie. The stills, when assembled, have to appear fluid enough to be real-life like in appearance. From this, you could argue webcams generally don't make movies. Comics aren't movies either. But, if you put enough stills together you can make a flip-book, which is a really small movie (though admittedly, animated generally).
Well, I never really said that Linux *was* the right tool for the job. Just like freshwater lakes aren't very directly useful for most people who need something to drink. I was just pointing out that Green Hill was complaining more about an idea (OSS) instead of an implementation (Linux), which to me seems very diversionary.
There's nothing stopping someone from taking Linux and stripping it down to core features then going through and verifying each part. And simply the fact that people can add source to *another* tree doesn't really mean anything for the security of your own fork. And Linux is no more innately insecure than any other computer program (though you could always argue that the amount of breakage to make a system secure might disqualify it from still being called its original name), but its stock implementation might not be the easiest to verify.
I'd personally rather see the use of finite state automatons in place whereever possible in place of computer programs, personally. And where computer programs are necessary, I do agree that a minimal program to do the job is easier to verify. In fact, a custom/niche job might work best.
It just seems very strange for Green Hill, realizing how much easier it is for another company/organization to use and verify its own OS, to be complaining about Linux. It's also very strange to claim that OSS is more insecure because it has outside, possibly malicious, help and also claim OSS has an unfair advantage over proprietary software. It'd seem to me the only advantage Linux would have over Green Hills's RTOS, at the moment, is the user (for example, the FAA) can alter the OS without worrying about licensing issues with some company. I'd guess that in a fair market, Green Hill's RTOS would be easier to use and verify than a stock Linux embedded setup. I'd also guess that Green Hill's prices aren't fair, and tweaking Linux to work in place of Green Hill's RTOS might actually be cheaper in the long run (a big hint to this is the massive price number Green Hill claims it cost to verify each line of code). So, overall, it seems like Green Hill is trying desperately to justify its cost with leery suggestions about OSS in general, and Linux as it is right now in particular.
Green Hill seems to be making some unsubstantiated claim that open source isn't held up to the same standards as closed source, and I find that rather funny. I think the real issue is, when Green Hill approaches the FAA or whatever, the FAA will do its own testing of the source. If Green Hill's code is breakable, Green Hill is the one responsible for fixing it. But, if what the FAA is reviewing is open source, it's possible the FAA can just fix the source themselves (and avoid having to pay an outside contractor). So, Green Hill, to avoid the scenario where the FAA might be displeased with Green Hill's RTOS and switch to open source, decides on its *own* to spend $500/$1,000 per line to audit their OS.
In the end, this means to me that Green Hill believes OSS has an unfair advantage. Personally, I think it's perfectly fair for people to offer free software. If Green Hill doesn't like it, tough. Or, they can just make their RTOS so good that the FAA or some other organization will be so impressed they won't bother going over some OSS and possible having to fix bugs or write documentation. Looks like the free market to me.
PS: SAYODF == Self-Analysising Your Own Dog Food; it's like a water bottling plant bitching about there being freshwater lakes because lakes don't have to do their own quality control
Close. It was 14 years plus a 14 year extension possible. I think your talk about the "artists tend to be poorer" is a rather large misconception. For the most part, only people with any significant level of learning could write proficiently enough to author a book. It wasn't until the 19th/20th century that there were folklorists and general widespread literacy improvements that allowed for the poor to write books, so most stories were still told orally for the poor.
During the time between a book starting to be written to the point where sales are enough to live off of, an author needs somewhere to live and eat. There wasn't much of a middle class at the start of the US, so generally that shifts virtually all writers into the comfortably rich. I think all this amounts to most authors of the time having a natural life span around 60 years (ignoring the revolutionary war that shrank writers lives).
However, I don't think that copyright as it was was 14 (+14) years because of the average lifespan of the author. US doctrine doesn't believe the author has any innate right to copyrighted works. In reality, the likelyhood is the 14 (up to 28) year span was more a result of communication lag which could mean it'd take several years before even a popular book to go from one major city to every rich person in even the more rural settings.
Today, it takes literally seconds for most works to go from a major city to a rural setting. While I don't believe a copyright the length of a few days would be sufficient incentive for an author (though it covers news stories well enough), if anything the increase in rate of information transfer should be *decreasing* the length of copyright, not increasing it. The US's adoption of the Berne Convention is to me, an ignorant surrender of a basic ideological difference between given and natural born rights. I truly wish that at some point the US takes measures to reaffirm the basics of what copyright is.
And you can turn that argument around. You are allowed to make a copy of a toaster. But it is too difficult for the average person to do so, which is a natural obstacle. The typical person would rather just spend $20-40 on a new toaster instead of building his own new toaster. Thus, there is an incentive for toaster manufacturers to keep on making toasters.
OTOH, making a copy of a DVD is trivially easy. Shouldn't the manufacturers of DVDs be given an incentive to make DVDs that would otherwise be mass produced and sold from the trunk of a car?
Are you talking about the manufacturers of DVDs or the authors of the content? As far as the actual manufacturers of the physical DVD, I say fuck them. They're in the same area as the toaster. It's only because it's intrinsically hard to make a toaster that toaster makers stay in business. There's no reason to protect the DVD manufacturers.
Now, as for the content, I'd say there's an understandable want to give the author some protection. However, the fact is the law is already *written* to provide some exclusionary rules to this protection (like the archival copy, which seems aimed at libraries). Beyond this is the precedent of First Sale Doctrine which says you have an intrinsic right to use the stuff you buy (in a way, it's sad that it took a court case for IP owners to realize that them selling something then *not* giving you access is paramount to not giving you anything, which obviously goes against the point of copyright (to promote the arts and sciences)). Anyways, back to the issue..
When you do buy a copy of a book, you're not just buying a physical copy of a book, or you'd be allowed to make and sell as many copies as you were physically capable of. More and more, it's the publishers who keep pushing towards the idea of buying the medium in such a way that the copyrighted work is somehow intertwined with it which doesn't work very well since there's no medium that exists that can't have exactly equally meaning in another medium (ie, text on a book or in a computer is the same, music on a cd or in a computer is the same, etc). So, every time it becomes a question of siding with the manufacturer/publisher, I keep asking "how does this benefit this author, and does it make sense". Things like the DMCA only further artificially bind the work and the medium which benefits the publisher the most.
Does buying two copies of a book promote the arts and sciences twice as much? How about if it's given to two people? What if one's just a backup to the other? I just can't see how we can justify giving the author twice as much money because he or his publisher decided to use crapy paper. If I decide to buy the book again because it's easier than bothering with a backup, so be it. But with DVDs and CDs, it's trivial to backup, so there's a real threat to not getting another resale. That's life. If they don't like it, the publisher shouldn't be allowed to rely on law-based artificial restrictions to push more merchandise. And maybe that means more things will be published on hard-to-copy, biodegradable media, but at least then it'll be out in the open and the public can easily boycott it instead of being pressed under government restrictions to comply.
Technically speaking, you can make a backup copy of a magazine, book, etc. Whether the courts consider it fair use or part of archival is a second issue. However, since copyright allows archival for at least libraries and the dmca blocks that, either the dmca has to go, copyright has to be rewritten to overcome this contradiction, or there has to be some means of achieving the ends provided for by the law. Of course, the third still needs the law to be rewritten to get rid of the contradiction (at some point).
I'm not sure why you keep acting like a toaster and a dvd are the same. I'm allowed to make a copy of a toaster. It keeps occuring that the law says I'm not allowed to make a copy of a dvd, except under strict limitations. If I wasn't allowed to make my own toaster or modify it, don't you think I'd want some sort of law providing something in return for that advantage given to toaster makers?
The GPL is about freedom of the user, not freedom of the developer. Unless you only use code you wrote yourself, you'll probably advantage from code under the GPL.
You can make a backup of a magazine, book, etc. You can make a backup of a car manual. The car itself isn't an IP good. If you can't make a backup, you're offering the consumer no means of backing up a work which they have a right to.
Basically, when you buy a copy of a work, you have an infinite time based right to access the work. If there's laws that prevent it, those laws should be deemed unconstitutional. Once a work goes into the public domain, for example, making as many copies as you want so you can be sure you never lose a copy of a work is possible. If laws that prevent such copying of a copyrighted work are upheld, it only makes sense that the copyright owner should be held responsible for either a) continuous distribution so you can buy another copy of the work at any time or b) replacement for the normal wear/tear that occurs on all physically objects.
I'm not sure about (1), but I doubt it (and parts of IIS (for example) runs in the kernel so even if (1) is true, it doesn't help much). (2) is very true, but even though it's non-static, it still might be pretty predictable (at least enough that you could unprotect enough pages to be sure that the stack is infact unprotected). (3) is also true, but my later comment points out that even if (3) is true, you can still run several calls on the stack which still amounts to running malicious code (it's just a lot more limited than running real code). And for (4), only the software stack corruption detection would stop this. Even then, software stack corruption detection (like propolice, which I'm sure MS's software is similar to) can be circumvented. How, you ask?
First, propolice does two things. One, it reorders all the buffers towards the top of the current frame. Second, it includes at compile time a value into the stack to detect overwrite. So, the end result looks like this.
[local vars][local bufs][NNNNNNNN][return addres]...
Before returning, each function checks to see if that NNNNNNNN isn't right. Now, this would be *really* great if the number was set at *runtime*, but since it's done at compile time, that means that all executables of the same build would be vulnerable to the same buffer exploit attack. Yes, that does mean that if you have enough varied builds installed, the odds are low that all your machine will be infected (since a worm might be unable to detect the build of your server (hiding version numbers to slow down worms, maybe?) hence unable to craft the proper filler value to not trip the detection software), but for something like Windows, you'll end up having everyone update to the latest version which restores the monoculture. The problem is the same in Linux for distros where you don't build from source (though there are more distros/builds of a version, which does give slightly more protection).
But back to the point, even rearranging the stack to grow up instead of down (therefore making it impossible to overwrite the return address) would prevent smashing data on the stack which could still have bad results. The only real protection is to not use functions (or make functions) that will unlimitedly write to the stack (or the heap). I think having data storage areas prefixed with a size indicator wouldn't be a bad idea, either.
Well, if you ignored that it was the wrong order (since it should be:
[junk][page permission set call address][RWX][page][pointer to code ][code ]
)
The point is you can just write stuff to the stack to do a call which can remove the NX bit from the stack, and then you can continue to run malicious code on the stack.
The only way truely eliminate arbitrary code execution is to mark pages with data non-executable and have a processor level exception thrown when you try to execute code from a data page.
:)
You know, all this work on NX is so *off* it's not funny. Why, you ask? Simply.
Imagine the following is your stack.
[local vars][return address ][local vars]...
Most buffer overflow exploits write code to the local vars and modify the return address to point to it:
[code ][pointer to code ][local vars]...
However, there's nothing stopping this:
[junk][RWX][page][page permission set call][filler][pointer to code ][code ]
Fixing the page permission at startup might help prevent the above, but even then you're not guaranteed that someone can't just do a lot of smart stack modification to run all the stuff they need to start *another* process to do their dirty work.
Of course, just making the stack grow up instead of down would resolve all these problems...but that's not as "efficient".
This is one reason why MS is pushing opaque memory. Then you can't, hypothetically, ever crack code since you can't see it. Of course, if there's still buffer overflows, you can still just do some library calling to have the program export its entire contents out somewhere...