Better yet: Don't waste my time prompting me with crap every time I want to install software.
Imagine if your favourite *nix package manager, ports tree, or build system prompted you with "legal info" for every single piece of software you tried to install. Or every library.
Click-wrap is the some of the most annoying and pointless bullshit users put up with, and they really shouldn't have to.
Not only is that a tired old joke that isn't funny anymore, but you've just shown everyone that you have no idea what you're talking about when it comes to the GNU/Linux naming controversy.
Perhaps Debian could live with using the mainline codebase, and contributing patches to Mozilla rather than going out on its own?
Sure, if you want to say goodbye to security patches, patches that affect portability to (say) sparc64, and patches that make the browser integrate with the rest of the system. While we're at it, why don't we take away the authority for package maintainers to make any code changes at all?
This isn't the 1990s. The "Linux distros" are now quite different from each other, and often binary-incompatible in some ways. Granted, it's very easy to port software between them (if you have source code, which you usually do), but they are most definitely different OSes now.
There are (or will soon be) more similarities between e.g. Debian GNU/Linux and Debian GNU/kFreeBSD than between Debian GNU/Linux and Mandriva Linux or Fedora Core.
Um... That's one screwed up command. You just created a sparse file that contains with 9.6 TB of zeros followed by the data on the disc. And it's not CSS-decrypted.
Most people who murder someone will probably spend the rest of their life fucked up in the head. They have created their own punishment, living every day with the guilt.
Have any evidence to back up that claim? Several police officers I know would disagree with tou.
(AAAAhh someone who is willing to pay for linux programs!!! oh the humanity)
This isn't the early 1990s. If you don't understand the difference between "freedom" and "free of charge" by now, you shouldn't be posting to online forums yet.
- Schraegstrichpunkt, who has purchased VMware Workstation, Crossover Office, various Loki games, and several commercial Linux-based operating systems (though I still prefer Debian).
I don't think you can ptrace another user's programs, unless you are already root.
News flash: You can ptrace your own xterms. Anybody who can run any code as you can sniff your password as you type it.
And X security is on by default.
What? No, it's not. The only thing that's on by default is binary access control. Once a program is authorized to use the X server, it can basically do whatever it wants, including keylogging and taking over the keyboard and mouse (ever heard of the XTEST extension?). There is a mechanism to set various X security policies so you can use untrusted X clients, but you'll have trouble even running GTK+ if you use that.
The (sub?)title of the article is "Polluting sys_execve() in kernel space without depending on the sys_call_table[]". The idea is that if you're auditing Linux, this is a problem, because it introduces another way to hook into sys_execve() without modifying the syscall table. If you put the kernel into ROM, then you might otherwise be able to assert that execve() can't be messed with, given certain conditions. This bug renders that assertion invalid.
But yeah, it's not exactly something that sysadmins need to get up at 1AM to patch their systems for.
There are two pieces of software here: the driver (which runs on the host), and firmware (which runs on the card). Theo wants freely redistributable firmware (which can be binary-only for all he cares), and documentation to write a free driver (which definitely must NOT be binary-only). Try not to get confused: He's not asking for free (as in freedom) firmware (though it would be nice), and he's not tolerating binary blobs that run on the host.
Technically-speaking, do you even need need clean room reverse engineering? As long as you don't copy code (i.e. you don't do anything that's prohibited by copyright statute), I would think you're legally in the clear. In that case, the benefit to doing it clean-room-style is that if the code you wrote happened to be very similar to the code you took apart, you would have documentation that shows that you couldn't have lifted code verbatim, because the person who wrote the code never saw the original.
As far as I know, no such "tainting" exists in law, but your boss's lawyer will advise him to have you do things clean-room anyway, so that your laziness doesn't end up adversely affecting the organization.
Slashdot Mirror
Microsoft can change OS prices at will. This makes them a legal monopoly.
Better yet: Don't waste my time prompting me with crap every time I want to install software.
Imagine if your favourite *nix package manager, ports tree, or build system prompted you with "legal info" for every single piece of software you tried to install. Or every library.
Click-wrap is the some of the most annoying and pointless bullshit users put up with, and they really shouldn't have to.
You might be interested in this article.
Have a nice day.
Sure, if you want to say goodbye to security patches, patches that affect portability to (say) sparc64, and patches that make the browser integrate with the rest of the system. While we're at it, why don't we take away the authority for package maintainers to make any code changes at all?
Not going to happen.
This isn't the 1990s. The "Linux distros" are now quite different from each other, and often binary-incompatible in some ways. Granted, it's very easy to port software between them (if you have source code, which you usually do), but they are most definitely different OSes now.
There are (or will soon be) more similarities between e.g. Debian GNU/Linux and Debian GNU/kFreeBSD than between Debian GNU/Linux and Mandriva Linux or Fedora Core.
"or some other implementation-defined manner" (ISO/IEC 9899:1999 (E), s. 5.1.2.2.1 "Program startup")
Maybe the guy is writing code for some weird embedded OS? ;)
There's a good way to shudder?
How is the parent a troll?
Are you talking about a permanent injunction, or are you talking about a preliminary injunction?
Have any evidence to back up that claim? Several police officers I know would disagree with tou.
You've obviously never seen The Daily WTF. I wouldn't touch that software with a 10-foot pole controlled 10,000 miles away through a SSH connection.
So?
Good idea. Then lowlifes like you won't be able to afford Internet access, thanks to economies of scale.
Ok, I'm not advocating "callbacks" here, but do they actually violate the standard? If so, what part?
This isn't the early 1990s. If you don't understand the difference between "freedom" and "free of charge" by now, you shouldn't be posting to online forums yet.
- Schraegstrichpunkt, who has purchased VMware Workstation, Crossover Office, various Loki games, and several commercial Linux-based operating systems (though I still prefer Debian).
Your standards are obsolete.
News flash: You can ptrace your own xterms. Anybody who can run any code as you can sniff your password as you type it.
What? No, it's not. The only thing that's on by default is binary access control. Once a program is authorized to use the X server, it can basically do whatever it wants, including keylogging and taking over the keyboard and mouse (ever heard of the XTEST extension?). There is a mechanism to set various X security policies so you can use untrusted X clients, but you'll have trouble even running GTK+ if you use that.
The (sub?)title of the article is "Polluting sys_execve() in kernel space without depending on the sys_call_table[]". The idea is that if you're auditing Linux, this is a problem, because it introduces another way to hook into sys_execve() without modifying the syscall table. If you put the kernel into ROM, then you might otherwise be able to assert that execve() can't be messed with, given certain conditions. This bug renders that assertion invalid.
But yeah, it's not exactly something that sysadmins need to get up at 1AM to patch their systems for.
Twice-pressing the "Power" button on your UPS does too. That doesn't make it useful.
Anyone who can use ptrace or who can connect to your X session can probably sniff whatever password you happen to type.
I understand this view, but my understanding is that it's an urban myth. Do you have any statute and/or case law to back up your claims?
There are two pieces of software here: the driver (which runs on the host), and firmware (which runs on the card). Theo wants freely redistributable firmware (which can be binary-only for all he cares), and documentation to write a free driver (which definitely must NOT be binary-only). Try not to get confused: He's not asking for free (as in freedom) firmware (though it would be nice), and he's not tolerating binary blobs that run on the host.
Technically-speaking, do you even need need clean room reverse engineering? As long as you don't copy code (i.e. you don't do anything that's prohibited by copyright statute), I would think you're legally in the clear. In that case, the benefit to doing it clean-room-style is that if the code you wrote happened to be very similar to the code you took apart, you would have documentation that shows that you couldn't have lifted code verbatim, because the person who wrote the code never saw the original.
As far as I know, no such "tainting" exists in law, but your boss's lawyer will advise him to have you do things clean-room anyway, so that your laziness doesn't end up adversely affecting the organization.