Aside from that, shell history doesn't contain anything not entered into the shell. Particularly, it doesn't contain anything entered into another remote shell.
Wikipedia is not and is not supposed to be a credible source by itself. It does, however, link to a credible source, which would have been better to use in your message.
You're lucky to easily figure out for 90% of your downloads. If I consider potential downloads (including the ones that I don't download because I can't figure out why it needs certain permissions), I don't even get to 50%, and at that point, it becomes enough of a pain to investigate each and every possibly useful app that I wish the default would be to have an explanation in the description.
You're absolutely correct in that ideas are not patentable, but your suggested change no longer makes the point I was trying to make. It's conceivable that someone might come up with a patent-worthy new process of recording a bird song. The patenting of the idea or concept of recording bird songs was meant to be absurd.
But users cannot sanely determine whether they should give the app permissions, unless the app explains why it wants those permissions. If I install a clock widget and it asks for permissions to send text messages to pay numbers, I don't trust it. If the clock description lists a feature to send text messages to another phone when a user-defined timer goes off, I might trust it. (And it would take more than just that description to make me trust it.)
The core point doesn't work. If bird songs are copyrightable, then different people can hold copyright on different bird songs. If someone patented the idea of recording a bird song, you could claim prior art by pointing to anyone who recorded a bird song before the patent.
They told everyone about it by mentioning it in both of the first two links in the summary, in addition to the New Features page linked to in another comment.
I bought a DVD with DRM and it would play in my DVD player but not on my computer so I returned it as defective.
Me too. The customer service lady made a big fuss about it, and was shocked that I would return a DVD in an opened box, and was even more shocked when the entertainment department told her to just give me my money back. She did so, but hesitantly, and it left me with a bitter aftertaste. I did not have a separate DVD player, so the disc really was completely useless for me.
I'll keep doing that until they figure out that it costs them more to add drm than not.
Other shops don't make me worry whether they'll let me return a defective product, they do, so they've lost me as a customer.
Note that on 32-bit systems, btrfs will only work well until your inode numbers no longer fit in a 32-bit int, which unlike with other file systems can easily happen. stat() will return an error code, and critical things like the ELF loader will no longer work.
Nope, sorry, not true. Parameter names never conflict with identifiers in any other scope.
They conflict with macros. Users are allowed to define macros before including standard library headers, and often do. I'm not familiar with GNU C coding standards, so you may have a point that __len should be _Len according to that, but as far as the C standard and POSIX care, either is fine.
Which would be fine, except that the glibc man pages don't say which functions are from which standard,
glibc doesn't include man pages, so firstly, your complaint isn't with glibc, and secondly, the ones on my system, as provided by man-pages, do. For example, from `man send`:
CONFORMING TO 4.4BSD, SVr4, POSIX.1-2001. These function calls appeared in 4.2BSD. POSIX.1-2001 only describes the MSG_OOB and MSG_EOR flags. The MSG_CONFIRM flag is a Linux extension.
If a function comes from 4BSD but was later adopted by POSIX and SUS, what do you define?
If you're writing in the POSIX subset of glibc, you define the POSIX macro.
If you define the POSIX macro, then you may find that you've suddenly hidden a load of other things that were working correctly.
So you're not limiting yourself to POSIX anyway, and the problem isn't glibc's POSIX support, it's how to combine POSIX with glibc extensions.
There are some really fun cases where no combination of the public macros expose all of the features that you want and you need to define some of the glibc internal ones.
_GNU_SOURCE should make everything from glibc available. What are you using that isn't exposed by this macro?
Unfortunately for developers, Debian GNU/kFreeBSD uses GNU libc, rather than FreeBSD libc, so you get all of the fun of working with a libc written by someone who can't read the C standard (see unistd.h and its use of reserved identifiers for inline function parameters)
Well duh! Of course libc uses reserved identifiers for those. If it used non-reserved identifiers, it would conflict with valid user code.
and requires a huge mess of -D flags to compile POSIX / SUS code.
It requires one or more of the macros that, according to POSIX / SUS, the code needs to define. If the code (for convenience I'll include the build system in "code") doesn't define those macros, but does make use of POSIX functions, that's already a bug in the code.
Personally however, I think any judge would see through that and realize that the electronic ability to distribute only the modified part of a work doesn't change the intent to distribute a modified work itself.
If I publish an unauthorised errata for a paper book, would you expect me to get convicted of copyright infringement?
BTW, does the C standard demand that all integer types use the same representation?
The C standard almost requires that the corresponding signed and unsigned types have the same representation for non-negative values within the signed type's range, so you probably won't see a little-endian signed int and a big-endian unsigned int even on specially created weird archs, but other than that, anything goes. ("Almost requires": it doesn't actually require it, but there are a few ways where the standard allows you to read a signed value using an unsigned type or vice versa, so if the representations differ, some sort of type tagging is needed.)
If not, one could imagine that e.g. char uses signed magnitude, short uses ones complement, and long uses twos complement.
As far as I know, that does not violate any of C's rules.
The C standard says a char is one byte, but does not say one byte is one octet. It allows for 16-bit bytes, which of course also means 16-bit chars.
Speaking of weird archs, omething I'm experimenting with myself is enabling alignment checks on x86 (x86-64 only right now; x86-32 causes too many problems); a large number of packages have no problems whatsoever with it, and of those that do, most of it comes from "if x86 then don't bother with alignment" logic, which is easily disabled.
Technically, yes, the protocol of a URL is required, but that's because a URL is a form of an absolute URI, and absolute URIs are those that include the protocol. Relative URIs are perfectly valid. The protocol is required in an absolute URI. If it is omitted, it's a relative URI. This is not the browser making assumptions, this is how URIs are defined.
If any license that the user agreed to says "for non-commercial use", then it really doesn't matter whether it's patented or copyrighted: you agreed not to use it for commercial use. What matters is whether that license agreement is valid, and in some coutries, even those in the EU, it is.
For example, my Windows 7 box mentions (translated) "You must agree to the enclosed license terms before you can use this software. If you wish to read the license terms, visit www.microsoft.com/useterms. For use on a single computer or device." This sounds like it satisfies the criteria.
According to the same article, though, if I manage to install Windows 7 without breaking any laws and without clicking "I Agree", then the EULA does not apply to me, and Dutch copyright law allows me to use Windows anyway.
Where did you see "first one"? "Most complete" doesn't mean it's the first, it means it's more complete than the other browsers. (Whether that's true, I have no idea.)
Also, and I may be wrong here to please correct me if I am, I was under the impression that some video/audio content delivered via the new HTML5 facilities would be presented without the need for any scripting support?
You're correct, but NoScript doesn't block only scripts. It includes the option to block <video> content, and some other non-scripted annoyances.
Slashdot Mirror
We can tell whether " is an opening or closing quotation mark, but computers can't, so they look awful when printed.
A criminal offense will not be a dispute between you and Netflix. It will be brought to court by the prosecutor.
No, that's not expected behaviour. Extensions can share information with websites, but if they don't, websites should not be able to get anything.
Aside from that, shell history doesn't contain anything not entered into the shell. Particularly, it doesn't contain anything entered into another remote shell.
Wikipedia is not and is not supposed to be a credible source by itself. It does, however, link to a credible source, which would have been better to use in your message.
You're lucky to easily figure out for 90% of your downloads. If I consider potential downloads (including the ones that I don't download because I can't figure out why it needs certain permissions), I don't even get to 50%, and at that point, it becomes enough of a pain to investigate each and every possibly useful app that I wish the default would be to have an explanation in the description.
You're absolutely correct in that ideas are not patentable, but your suggested change no longer makes the point I was trying to make. It's conceivable that someone might come up with a patent-worthy new process of recording a bird song. The patenting of the idea or concept of recording bird songs was meant to be absurd.
But users cannot sanely determine whether they should give the app permissions, unless the app explains why it wants those permissions. If I install a clock widget and it asks for permissions to send text messages to pay numbers, I don't trust it. If the clock description lists a feature to send text messages to another phone when a user-defined timer goes off, I might trust it. (And it would take more than just that description to make me trust it.)
That's why plenty of free apps want network access. But how is access to the user's contacts required for displaying ads?
The core point doesn't work. If bird songs are copyrightable, then different people can hold copyright on different bird songs. If someone patented the idea of recording a bird song, you could claim prior art by pointing to anyone who recorded a bird song before the patent.
I wouldn't take copyright advice from someone who doesn't understand the difference between that and patents.
"You have the right to remain silent: we will accept your confession in writing."
They told everyone about it by mentioning it in both of the first two links in the summary, in addition to the New Features page linked to in another comment.
I bought a DVD with DRM and it would play in my DVD player but not on my computer so I returned it as defective.
Me too. The customer service lady made a big fuss about it, and was shocked that I would return a DVD in an opened box, and was even more shocked when the entertainment department told her to just give me my money back. She did so, but hesitantly, and it left me with a bitter aftertaste. I did not have a separate DVD player, so the disc really was completely useless for me.
I'll keep doing that until they figure out that it costs them more to add drm than not.
Other shops don't make me worry whether they'll let me return a defective product, they do, so they've lost me as a customer.
Note that on 32-bit systems, btrfs will only work well until your inode numbers no longer fit in a 32-bit int, which unlike with other file systems can easily happen. stat() will return an error code, and critical things like the ELF loader will no longer work.
Yes, I've seen this happen.
They conflict with macros. Users are allowed to define macros before including standard library headers, and often do. I'm not familiar with GNU C coding standards, so you may have a point that __len should be _Len according to that, but as far as the C standard and POSIX care, either is fine.
glibc doesn't include man pages, so firstly, your complaint isn't with glibc, and secondly, the ones on my system, as provided by man-pages, do. For example, from `man send`:
If you're writing in the POSIX subset of glibc, you define the POSIX macro.
So you're not limiting yourself to POSIX anyway, and the problem isn't glibc's POSIX support, it's how to combine POSIX with glibc extensions.
_GNU_SOURCE should make everything from glibc available. What are you using that isn't exposed by this macro?
Well duh! Of course libc uses reserved identifiers for those. If it used non-reserved identifiers, it would conflict with valid user code.
It requires one or more of the macros that, according to POSIX / SUS, the code needs to define. If the code (for convenience I'll include the build system in "code") doesn't define those macros, but does make use of POSIX functions, that's already a bug in the code.
If I publish an unauthorised errata for a paper book, would you expect me to get convicted of copyright infringement?
The C standard almost requires that the corresponding signed and unsigned types have the same representation for non-negative values within the signed type's range, so you probably won't see a little-endian signed int and a big-endian unsigned int even on specially created weird archs, but other than that, anything goes. ("Almost requires": it doesn't actually require it, but there are a few ways where the standard allows you to read a signed value using an unsigned type or vice versa, so if the representations differ, some sort of type tagging is needed.)
As far as I know, that does not violate any of C's rules.
The C standard says a char is one byte, but does not say one byte is one octet. It allows for 16-bit bytes, which of course also means 16-bit chars. Speaking of weird archs, omething I'm experimenting with myself is enabling alignment checks on x86 (x86-64 only right now; x86-32 causes too many problems); a large number of packages have no problems whatsoever with it, and of those that do, most of it comes from "if x86 then don't bother with alignment" logic, which is easily disabled.
Technically, yes, the protocol of a URL is required, but that's because a URL is a form of an absolute URI, and absolute URIs are those that include the protocol. Relative URIs are perfectly valid. The protocol is required in an absolute URI. If it is omitted, it's a relative URI. This is not the browser making assumptions, this is how URIs are defined.
If any license that the user agreed to says "for non-commercial use", then it really doesn't matter whether it's patented or copyrighted: you agreed not to use it for commercial use. What matters is whether that license agreement is valid, and in some coutries, even those in the EU, it is.
That's true in the Netherlands. However, the EULA does not need to be actually presented prior to the sale. As long as the buyer is notified of the fact that there is an EULA beforehand, has some possibility to view it, and agrees to the EULA (even by clicking "I Agree" during installation) after the sale, the EULA constitutes a contract.
For example, my Windows 7 box mentions (translated) "You must agree to the enclosed license terms before you can use this software. If you wish to read the license terms, visit www.microsoft.com/useterms. For use on a single computer or device." This sounds like it satisfies the criteria.
According to the same article, though, if I manage to install Windows 7 without breaking any laws and without clicking "I Agree", then the EULA does not apply to me, and Dutch copyright law allows me to use Windows anyway.
Where did you see "first one"? "Most complete" doesn't mean it's the first, it means it's more complete than the other browsers. (Whether that's true, I have no idea.)
You're correct, but NoScript doesn't block only scripts. It includes the option to block <video> content, and some other non-scripted annoyances.