It's quite a double-standard that we live in a world where SPAM is evil and ISPs should cut them off, and yet it's not OK to cut people off for sharing files that infringe copyright.
Well, a TOS violation remains a TOS violation. If you get service from an ISP and agree to not infringe copyright, then you shouldn't be surprised if you get cut off when you start downloading loads of videos without permission.
OTOH, it is users who cause problems for other customers of the ISP who really get stomped on. Spammers do this. So do people who use bittorrent without limiting their upstream bandwidth to well below the physical capacity. (Please don't do that if you've not got a business-class uplink; it annoys your neighbors on the same network segment who are just browsing the web.)
That would be pointless. Once something gets on the web, it stays there forever. Google's cache, other people mirroring it, etc..
Google doesn't spider everything immediately; it can take some time. This means that there's a window of opportunity for those seeking to suppress information. Though if someone not present actually viewed the image then they'd have a copy and the cat would be truly out of the bag. (Which should be as big a hint as anyone needs for defeating this sort of thing...)
The first thing Obama should do is replace Griffin and then do a real independent review of all the alternatives, including at least Ares, DIRECT and the EELVs.
The problem with doing a review is that it takes a lot of time, effort and money while only being meta-work that doesn't actually deliver real value toward NASA's overall goals. And even then, it's entirely possible that the review will say "do not change anything", in which case the money will have been entirely wasted.
It would be far better to try to ensure that the money goes towards doing things that inspire both current and future generations. And NASA at its best is just that: truly inspiring in a way that transcends both generations and borders.
Any and all developers should be sanitizing any and all text that will later be displayed in a browser.
Actually, you should be sanitizing on output so that all characters with special meaning for HTML are quoted, with particular attention on angle brackets. If you feel you have to allow HTML-like tags (e.g. such as/. does) then allow only exact forms and sanitize everything else, so you don't get caught out by attributes. And don't forget to test your sanitizer with evil cases.
It's probably better to consider using a proper HTML templating library.
Wow, actually that makes perfect sense. Democrats suck, Republicans are mindless, socialists are hairy lunatics, and the best way to get rid of a libertarian is to nuke the site from orbit...It's the only way to be sure.
Not quite. With Libertarians, you're dealing with bizarre aliens who are not of this earth. Reminds me rather a lot of John Redwood.
In my opinion, Ron Paul was the best choice for President, but the media wrote him off.
Alas (for you) a majority of other people think Ron Paul is a fruit loop.
For entertainment's purposes, could you outline how Ron Paul would have dealt with the banking crisis, assuming that (through some kind of magic) he had come to power at the start of 2007. Pay particular attention to questions like "Would it have destroyed even more people's savings?" and "Would it have resulted in more people losing their homes?" (Note that ranting about how we wouldn't have got in the situation is probably not useful; by the start of 2007 the crash was probably inevitable.)
You've omitted the ability to match other number bases. I don't know about you, but I find it useful to be able to cope with numbers in base 2, base 8 and base 16 as well (both as integers or floats, of course).
However, trying to defend the idea that economic success implies technological superiority is wholely without merit.
Because that would imply that your favourite language is a failure, and you find that conclusion unacceptable?
Lisp is a power tool for a Very Smart Person. Like all such tools, they're difficult to master. The truly successful stuff tends to be usable in an effective manner by people who aren't VSPs. (For example, making it easier to see where the costs of resource management are biting makes it easier for programmers to get good performance. Well, for a large enough fraction of programmers for most SW companies to have at least one on staff...)
Really the arguments against this are getting silly. Self-signed should work and be treated at least as well as unencrypted pages. It does seem possible that there are powerful forces trying to get the browsers to not like self-signed certificates because the arguments for Firefox's behavior are getting really out there...
Then explain to me why it is so important to support self-signed certificates. They really are less secure than those that have been signed by a trusted third party as it's trivial to generate them on demand. All you're asking to do is to turn HTTPS into yet more security theatre.
Note that you don't have to trust the CAs that everyone else uses. Having one for you and your friends is perfectly fine, and doesn't have any of the problems. (You don't really need to defend your online banking from governments that much; they can always pressure the bank directly instead...)
Nonsense, you can easily detect if someone forges certs in a man-in-the-middle attack by comparing signatures after the fact.
Alas, that runs up against practical problems too. Server keys get compromised for stupid reasons. They also expire (which is good!) and services get moved around for stupid marketing reasons and crap like that. Almost all of these are not problems that should be exposed to users; you only want to pop up a warning dialog when something is really wrong so users won't get habituated to them.
Given that, plus the fact that you also want to protect users who don't have the signatures stored, you're advocating killing the baby because of dirty bath water. Governments are definitely not the only folks against who we need to protect.
Generating self-signed certificates that match the site is a trivial process for any reasonably-well equipped man-in-the-middle.
In fact, it's trivial for anyone who can master the (admittedly large) hurdle of reading and understanding the documentation of openssl. Doing the MITM then just requires a careful bit of DNS poisoning, or DDoS attack, or sending a fake webpage, or any number of techniques that have been seen in the wild.
The only time a self-signed certificate is at all useful is when you get all parties wanting to trust the cert to know the certificate directly first using out-of-band techniques, e.g. by meeting the other person directly, or using some other previously-trusted encrypted channel. I use self-signed certs for testing just fine (well, I actually set up my own CA as that reduces the amount of management) but I never deploy with them.
wow, I hope that wasn't for paying a bill, you might find your house foreclosed when you get back.
As it happens, it wasn't a financial message, but rather an instruction telling us to stay away as the person we were going to visit was ill with laryngitis (or something like that). Alas it was too late even by the time it was actually sent; we'd already booked accommodation in the area.
Curiously, the message arrived about two weeks before she visited us the following year, causing massive confusion! Spooky coincidence, especially given that such visits either way are rare. (The trip is over a thousand miles each way, through some of the busiest highways in Europe.) On the other hand, I've had statistical training so I'd be really worried if coincidences never happened...
Having been in the private utility biz, I know better than to say, "Not economically feasible. We're not building it." We always said, "Not at this time, but it is in our long term plans".
Of course, the response to that is "Can you give an estimate on the schedule for the roll-out on that area?" (or an equivalent phrase) which leaves you thoroughly on the spot. You have to be very careful when you use Sometime as the answer, as most folks (rightly) interpret it as (Practically) Never; the rest will sue when they figure they've been lied to.
This solution already exists in the form of one-time security codes like the RSA SecurID range of products. Basically it's a PRNG which spits out a number every few minutes which is unique to the customer.
The advantage of the mobile phone strategy is it is making use of a device that the user is (with very high probability) already carrying on their person. Most people don't like carrying lots of extra gadgets.
The problem is that the carriers are unreliable in timing of delivery even w/o grid problems. So many times I have got text messages and even voice mail hours after it was delivered.
I've had it take 9 months. Admittedly I wasn't in my home country at the time the SMS was sent.
Solving the halting problem for a finite-storage Turing machine approximation is trivial: simply trace the algorithm and compare each state it reaches with each previous state. If the states are identical, then the algorithm will never terminate, for it has entered an infinite loop.
This is the sort of "trivial" that is only used by pure mathematicians. In practice, it's much harder than that, especially when modeling any program with non-determinism in it (almost all of them these days).
The problem is two-fold. Firstly, working out when two states are the same is a much harder challenge than it first appears: e.g. does it matter that the system clock has advanced in the meantime? Secondly, the state space grows massively fast and storing all the states of even a small program tends to lead to a memory structure that is very inefficient (you get a fully random access memory pattern across data that is too large even to fit on a substantial modern cluster...) You can use the solution to the first problem to help deal with the second, but state comparison and compression algorithms are tricky to write in a way that isn't very specific to the program being analyzed.
I say this as someone who has (a few years ago now) written deadlock checkers and temporal logic model checkers for real programs. Yes, the problem is actually parallelizable, but it's still very hard because of that dirty great store of all visited states; BDDs can help, but are horribly dependent on the order of variables and I never knew of an algorithm for determining an optimal ordering...
If you've got a file that you always want to set some specific variable to a non-default value for when editing, use something like this (taken from the end of a C file...)
Debian, at least, requires all packages to provide manpages for every "program, utility, and function". To not do so is a bug (policy manual 12.1)
So at least on that distribution, I find the manpage selection to be very broad. I have also not generally had a problem with manpage quality. But YMMV.
In my experience, they've got some way to do to get the quality up to where it should be. OTOH, it's a lot of work and massive kudos to them for taking it on. (Key problems tend to be things like failing to explain assumptions on which the software is based, resulting in something that can be used by experts or utter novices, but which isn't helpful to people who are generally good but not experienced with that particular tool.)
Documentation is important. Unsexy, but important. It's also something that people can help a lot with while learning a tool.
You don't want to read the complete elisp manual (about 340,000 words, according to cat/usr/share/info/elisp* | gunzip | wc) in $PAGER.
Hang on there a moment, I most certainly would like to do that. Especially as it would allow me to quickly find anything that I might be interested in, and not just the individual words that the authors thought were worthy of indexing. OK, when I'm online I can just google, but when I'm working on the train I want everything where I can get at it. (The route the train takes has terrible network connectivity due to physical constraints like tunnels and deep cuttings. But at least it makes people yakking on their mobiles shut up...)
More awesomely, if you have found something in your history with ^R or up arrow or whatever, then you can press ^O to "execute this line and put the next line in the history onto the command line".
That's not a universally configured binding (it does nothing under bash on OSX, using the default configuration). Alas.
Develop the prototype as a proof of concept (use those words if "prototype" sends your people into a frenzy) and show them the UI with nothing attached underneath first.
If you polish the mock-up (another useful phrase) too hard, people will lose sight of the fact that there's only smoke and mirrors behind it. Even people who should know better (other programmers!) fall into this trap. So make sure that the mock-up is producing actual nonsense results and is also doing annoying stuff like popping up dialogs ("data wasn't actually saved because this part isn't written yet: OK") so that nobody thinks it is in a shippable state. It also helps if you can precede the demo with a presentation with a Gantt chart showing that this is just a small part of the overall project; while Gantt charts are dangerous, failing to manage expectations is far worse.
(Also don't forget to write unit tests so that you can shorten the cycle time to dealing with issues and keeping them dealt with. No point in sending stuff with obvious faults to QA; let them work on the integration and acceptance testing...)
It's quite a double-standard that we live in a world where SPAM is evil and ISPs should cut them off, and yet it's not OK to cut people off for sharing files that infringe copyright.
Well, a TOS violation remains a TOS violation. If you get service from an ISP and agree to not infringe copyright, then you shouldn't be surprised if you get cut off when you start downloading loads of videos without permission.
OTOH, it is users who cause problems for other customers of the ISP who really get stomped on. Spammers do this. So do people who use bittorrent without limiting their upstream bandwidth to well below the physical capacity. (Please don't do that if you've not got a business-class uplink; it annoys your neighbors on the same network segment who are just browsing the web.)
That would be pointless. Once something gets on the web, it stays there forever. Google's cache, other people mirroring it, etc..
Google doesn't spider everything immediately; it can take some time. This means that there's a window of opportunity for those seeking to suppress information. Though if someone not present actually viewed the image then they'd have a copy and the cat would be truly out of the bag. (Which should be as big a hint as anyone needs for defeating this sort of thing...)
The first thing Obama should do is replace Griffin and then do a real independent review of all the alternatives, including at least Ares, DIRECT and the EELVs.
The problem with doing a review is that it takes a lot of time, effort and money while only being meta-work that doesn't actually deliver real value toward NASA's overall goals. And even then, it's entirely possible that the review will say "do not change anything", in which case the money will have been entirely wasted.
It would be far better to try to ensure that the money goes towards doing things that inspire both current and future generations. And NASA at its best is just that: truly inspiring in a way that transcends both generations and borders.
When they said "Green Power", did they prefix it with "Glowing"?
Any and all developers should be sanitizing any and all text that will later be displayed in a browser.
Actually, you should be sanitizing on output so that all characters with special meaning for HTML are quoted, with particular attention on angle brackets. If you feel you have to allow HTML-like tags (e.g. such as /. does) then allow only exact forms and sanitize everything else, so you don't get caught out by attributes. And don't forget to test your sanitizer with evil cases.
It's probably better to consider using a proper HTML templating library.
Then again, maybe we have both had too much coffee today. :)
DDDDDDdoooonnn'nn'ttt bbeee sssiilllllllyyyy! Nnnnnoo sssssuuccchh tttthhhinngggg!!!!
There are very unpopular restrinctions by the EU. Ask milk producers.
Remember, national governments find it very convenient to be able to blame the EU for unpopular policies that they still want to implement.
Not quite. With Libertarians, you're dealing with bizarre aliens who are not of this earth. Reminds me rather a lot of John Redwood.
... but it seems that a DNS attack redirected it to a fluff piece without any useful content.
In my opinion, Ron Paul was the best choice for President, but the media wrote him off.
Alas (for you) a majority of other people think Ron Paul is a fruit loop.
For entertainment's purposes, could you outline how Ron Paul would have dealt with the banking crisis, assuming that (through some kind of magic) he had come to power at the start of 2007. Pay particular attention to questions like "Would it have destroyed even more people's savings?" and "Would it have resulted in more people losing their homes?" (Note that ranting about how we wouldn't have got in the situation is probably not useful; by the start of 2007 the crash was probably inevitable.)
This regex matches a number: interger or float, scientific notation or plain, plus or minus...
[-+]?(?:\b[0-9]+(?:\.[0-9]*)?|\.[0-9]+\b)(?:[eE][-+]?[0-9]+\b)?
You've omitted the ability to match other number bases. I don't know about you, but I find it useful to be able to cope with numbers in base 2, base 8 and base 16 as well (both as integers or floats, of course).
However, trying to defend the idea that economic success implies technological superiority is wholely without merit.
Because that would imply that your favourite language is a failure, and you find that conclusion unacceptable?
Lisp is a power tool for a Very Smart Person. Like all such tools, they're difficult to master. The truly successful stuff tends to be usable in an effective manner by people who aren't VSPs. (For example, making it easier to see where the costs of resource management are biting makes it easier for programmers to get good performance. Well, for a large enough fraction of programmers for most SW companies to have at least one on staff...)
Really the arguments against this are getting silly. Self-signed should work and be treated at least as well as unencrypted pages. It does seem possible that there are powerful forces trying to get the browsers to not like self-signed certificates because the arguments for Firefox's behavior are getting really out there...
Then explain to me why it is so important to support self-signed certificates. They really are less secure than those that have been signed by a trusted third party as it's trivial to generate them on demand. All you're asking to do is to turn HTTPS into yet more security theatre.
Note that you don't have to trust the CAs that everyone else uses. Having one for you and your friends is perfectly fine, and doesn't have any of the problems. (You don't really need to defend your online banking from governments that much; they can always pressure the bank directly instead...)
Nonsense, you can easily detect if someone forges certs in a man-in-the-middle attack by comparing signatures after the fact.
Alas, that runs up against practical problems too. Server keys get compromised for stupid reasons. They also expire (which is good!) and services get moved around for stupid marketing reasons and crap like that. Almost all of these are not problems that should be exposed to users; you only want to pop up a warning dialog when something is really wrong so users won't get habituated to them.
Given that, plus the fact that you also want to protect users who don't have the signatures stored, you're advocating killing the baby because of dirty bath water. Governments are definitely not the only folks against who we need to protect.
Generating self-signed certificates that match the site is a trivial process for any reasonably-well equipped man-in-the-middle.
In fact, it's trivial for anyone who can master the (admittedly large) hurdle of reading and understanding the documentation of openssl. Doing the MITM then just requires a careful bit of DNS poisoning, or DDoS attack, or sending a fake webpage, or any number of techniques that have been seen in the wild.
The only time a self-signed certificate is at all useful is when you get all parties wanting to trust the cert to know the certificate directly first using out-of-band techniques, e.g. by meeting the other person directly, or using some other previously-trusted encrypted channel. I use self-signed certs for testing just fine (well, I actually set up my own CA as that reduces the amount of management) but I never deploy with them.
wow, I hope that wasn't for paying a bill, you might find your house foreclosed when you get back.
As it happens, it wasn't a financial message, but rather an instruction telling us to stay away as the person we were going to visit was ill with laryngitis (or something like that). Alas it was too late even by the time it was actually sent; we'd already booked accommodation in the area.
Curiously, the message arrived about two weeks before she visited us the following year, causing massive confusion! Spooky coincidence, especially given that such visits either way are rare. (The trip is over a thousand miles each way, through some of the busiest highways in Europe.) On the other hand, I've had statistical training so I'd be really worried if coincidences never happened...
Having been in the private utility biz, I know better than to say, "Not economically feasible. We're not building it." We always said, "Not at this time, but it is in our long term plans".
Of course, the response to that is "Can you give an estimate on the schedule for the roll-out on that area?" (or an equivalent phrase) which leaves you thoroughly on the spot. You have to be very careful when you use Sometime as the answer, as most folks (rightly) interpret it as (Practically) Never; the rest will sue when they figure they've been lied to.
None of that is special to utilities.
This solution already exists in the form of one-time security codes like the RSA SecurID range of products.
Basically it's a PRNG which spits out a number every few minutes which is unique to the customer.
The advantage of the mobile phone strategy is it is making use of a device that the user is (with very high probability) already carrying on their person. Most people don't like carrying lots of extra gadgets.
The problem is that the carriers are unreliable in timing of delivery even w/o grid problems. So many times I have got text messages and even voice mail hours after it was delivered.
I've had it take 9 months. Admittedly I wasn't in my home country at the time the SMS was sent.
Solving the halting problem for a finite-storage Turing machine approximation is trivial: simply trace the algorithm and compare each state it reaches with each previous state. If the states are identical, then the algorithm will never terminate, for it has entered an infinite loop.
This is the sort of "trivial" that is only used by pure mathematicians. In practice, it's much harder than that, especially when modeling any program with non-determinism in it (almost all of them these days).
The problem is two-fold. Firstly, working out when two states are the same is a much harder challenge than it first appears: e.g. does it matter that the system clock has advanced in the meantime? Secondly, the state space grows massively fast and storing all the states of even a small program tends to lead to a memory structure that is very inefficient (you get a fully random access memory pattern across data that is too large even to fit on a substantial modern cluster...) You can use the solution to the first problem to help deal with the second, but state comparison and compression algorithms are tricky to write in a way that isn't very specific to the program being analyzed.
I say this as someone who has (a few years ago now) written deadlock checkers and temporal logic model checkers for real programs. Yes, the problem is actually parallelizable, but it's still very hard because of that dirty great store of all visited states; BDDs can help, but are horribly dependent on the order of variables and I never knew of an algorithm for determining an optimal ordering...
If you've got a file that you always want to set some specific variable to a non-default value for when editing, use something like this (taken from the end of a C file...)
* Local Variables:
* fill-column: 78
* c-basic-offset: 4
* End:
*/
Debian, at least, requires all packages to provide manpages for every "program, utility, and function". To not do so is a bug (policy manual 12.1)
So at least on that distribution, I find the manpage selection to be very broad. I have also not generally had a problem with manpage quality. But YMMV.
In my experience, they've got some way to do to get the quality up to where it should be. OTOH, it's a lot of work and massive kudos to them for taking it on. (Key problems tend to be things like failing to explain assumptions on which the software is based, resulting in something that can be used by experts or utter novices, but which isn't helpful to people who are generally good but not experienced with that particular tool.)
Documentation is important. Unsexy, but important. It's also something that people can help a lot with while learning a tool.
You don't want to read the complete elisp manual (about 340,000 words, according to cat /usr/share/info/elisp* | gunzip | wc) in $PAGER.
Hang on there a moment, I most certainly would like to do that. Especially as it would allow me to quickly find anything that I might be interested in, and not just the individual words that the authors thought were worthy of indexing. OK, when I'm online I can just google, but when I'm working on the train I want everything where I can get at it. (The route the train takes has terrible network connectivity due to physical constraints like tunnels and deep cuttings. But at least it makes people yakking on their mobiles shut up...)
More awesomely, if you have found something in your history with ^R or up arrow or whatever, then you can press ^O to "execute this line and put the next line in the history onto the command line".
That's not a universally configured binding (it does nothing under bash on OSX, using the default configuration). Alas.
Develop the prototype as a proof of concept (use those words if "prototype" sends your people into a frenzy) and show them the UI with nothing attached underneath first.
If you polish the mock-up (another useful phrase) too hard, people will lose sight of the fact that there's only smoke and mirrors behind it. Even people who should know better (other programmers!) fall into this trap. So make sure that the mock-up is producing actual nonsense results and is also doing annoying stuff like popping up dialogs ("data wasn't actually saved because this part isn't written yet: OK") so that nobody thinks it is in a shippable state. It also helps if you can precede the demo with a presentation with a Gantt chart showing that this is just a small part of the overall project; while Gantt charts are dangerous, failing to manage expectations is far worse.
(Also don't forget to write unit tests so that you can shorten the cycle time to dealing with issues and keeping them dealt with. No point in sending stuff with obvious faults to QA; let them work on the integration and acceptance testing...)