1,881 karma · joined May 24, 2010
Every language has a design goal. Python doesn't care about interface contracts. The "one correct way" is the contract.
What is a class or static method? These are OO constructs and require additional mental overhead when learning.
We've known this for a looong time, it's just that it's so damned complex that we have trouble grappling with it.
And let's not forget the rest of the cell and all of the information encoded at the protein/messenger level.
First they started filtering marketing messages into separate tabs, which I'm assuming dramatically cut readership. Now they're going to make it impossible to "bug" emails for read receipts. The only metric left is the "click".
Email marketing just became a whole lot less valuable.
Should (yet another) digital currency be created to address this issue? Imagine if every person on earth was assigned an equal amount of such a digital currency (ignore the infeasibility). Would that be a healthier market?
You wouldn't imagine that such a finely delineated categorical segmentation would occur, but it's very visible. Take, for instance, the fighting between Fulton County and the metro/MSA: last year's SPLOST vote [1], the Braves Stadium move [2], etc. all serve to exemplify how polar these two populations are.
Those in the city want regional tax money to improve transportation in and around the city, those outside the city want to be left alone (yet still be able to commute to the city); Atlantans bemoan urban sprawl, suburbanites loathe city spending. It's interesting to watch nothing get done.
[1] http://southernspaces.org/sites/southernspaces.org/files/ima...
[2] http://www.ajc.com/news/sports/baseball/braves-plan-to-build...
Not to discredit Google's attempts here prematurely, but they are known for shutting down non-profitable/low-trafficked services.
Why don't we go back to funding moonshot projects instead, then? Let's see Apollo Program/Human Genome Project-level spending on Next-generation sequencing (protein and RNA included), novel propulsion engines for deep space probes, battery research, materials, etc. If we spent the same money on pressing problems, we could support the science and tech sectors all the while doing incredible societal good.
Could bitcoin be extended to support such a feature it were possible?
echo shell_exec('touch /etc/foo');
touch: cannot touch `/etc/foo': Permission denied
Don't learn Django or RoR either. You'll just be solving the same problem in a different way. Intead, try something entirely new--write a chat or job server with Twisted, try your hand at image processing, write some ML classifiers, and so forth. It's not as hard or out of reach as you'd think. Imagine a fun problem to solve--something you've always wanted your computer to do (perhaps something that irks you, that you want to automate) and just do it!
You'll find yourself in that "other category" without that having been your objective at all, and you'll have much more to show for it.
Are my ideas on how to proceed correct? I'm not sure--perhaps I should validate on my own. I can't afford to scale yet (time and money), so perhaps I should seek to "wow" and then seek interest. I can at least do that on my own.
That said, your post was really insightful. As another already mentioned, I wasn't aware about the solicitation rule.
A great percentage of the content I'm interested in is created or updated only rarely, and it tends to be superior to the kind of content that is churned out for quick consumption.
I fear that even with a tool like this, discovery, spam, and the need for heavy personal curation will still be problems. In any case, this stands to help improve signal:noise.
Honestly, people are not going to change their password habits, i.e. we can't expect users not to reuse the same password at different sites. Moreover, I would wager that most people trust that websites are inherently secure and that password-related functions are safe.
The party to blame, then, is squarely the website that allows the leak of unhashed, unsalted passwords.
I believe we should seek legislation similar to HIPAA wherein the damages are inversely proportional to the ignorance and mitigation preparedness of the party to blame. (Damages might also be directly proportional to number of accounts breached, but only after the former is considered.)
As an example, imagine that a kid acting alone gets his forum or website broken into. There's probably not much that a teenager would have known about password security. Additionally, they probably weren't servicing millions of users as a part of a commercial service. You can apply this same kind of situational blamelessness to small businesses, clubs, churches, and so forth.
If, however, a multi-million dollar company gets breached, it's a likely different story. Such a company has employed engineers that are familiar with such topics as scaling and cross-browser support. If these types of business concerns are known and handled, then it's almost a certainty that they also know about password hashing. (If not, I would bet that new legislation would result in widespread education on the issue.)
If the cost of changes is estimated to be too high, we could even go as far as to lower or absolve damages if the 3rd party were to inform its users that its passwords were not hashed or not salted; a "use at your own risk" notice, if you will.
I feel strongly that we need to do something drastic about unhashed/unsalted passwords. This is becoming absolutely ridiculous; it makes our profession look like a circus show, and all for something that can be easily avoided.
Does this imply a certain density to prime numbers? And given this new information, does it mean that it could be less computationally hard to find or verify primes?
I'm wondering if perhaps Sony won a Pyrrhic victory here.
I tried to bid for 'bt.io' due to my name sharing the initialism; that thing wound up going for quite a bit. You're probably sitting on a goldmine here, OP.
Take no offense. I'd just like to imagine that HN will remain constructive and helpful to our community.