That would have been a reasonable argument if they were found to have been using something like DES-based crypt(3) to hash their passwords. But they didn't, they were just plain text.
> I wish there was a guide for "proper" SO questions; my impression is, the only ones are super-detailed questions about some super-particular APIs.
And those questions can in most cases be answered by the docs anyway. The times I've used SO is when the problem can't be answered by the docs, my own experience or that of the team, but then I've received either no answer or a series of non-answers (that should have been comments instead, but a lot of people can't comment).
I also see quite a bit of overt reputation farming there. Like vague questions that receive an improbably precise answer that immediately gets selected. Like "how do u process payments?" (the orthography is usually bad) immediately followed by very specific instructions from a very specific payment processor not mentioned in the question, probably taken straight from its documentation. And I rarely see "closed as too broad" on those, probably because of the quick turn-around.
What kind of capitalisation convention is that? It's not German, or all the nouns would have been capitalised. Prepositions and conjunctions, with verbs and pronouns some of the time?
> I honestly think the finance industry could be half the size it is with no real harm to the rest of the economy.
With technology it should have shrunk by a couple of orders of magnitude. You don't need a room full of old men in green visors cranking away at adding machines to get anything done anymore. Instead technology has only made it bigger.
If you use Postgres, CTEs are optimization boundaries that make temp tables - you may end up inlining the CTEs or making them into regular temp tables so you can put indexes on them.
I've heard this but I haven't heard why this is. Do you know if this is deliberate or just falls out of the implementation? I wonder if they'd consider an explicit syntax to have them inlined. I love CTEs for organizations, would love to not think about them affecting performance someday.
It's deliberate, and sometimes it's helpful to have a way to force the ordering of work in the database.
One potentially simple option is to have the database temp space stored in RAM, by registering a ramdisk. That also helps large sorts, which implicitly make temp tables.
You can also manually inline everything, but if you have a lot of joins, you may end up tuning queries by changing join order. By default, if there are >8 joins it uses the order you give it. If you set the 8 higher the planning step takes a little longer - fine if it's for ETL but not ideal for a web app.
> One potentially simple option is to have the database temp space stored in RAM, by registering a ramdisk. That also helps large sorts, which implicitly make temp tables.
PostgreSQL sorts small amounts of data in RAM by default, choosing to spill to disk only for larger amounts of data. This threshold is tunable:
If you want it to sort everything in memory all the time, a high value for `work_mem` in postgresql.conf should do it. Alternately, like most parameters, you can set it:
* on a per-user basis (ALTER USER _ SET work_mem='2GB')
* on a per-session basis using SQL within the app (SET work_mem='2GB')
* on a per-session basis using `libpq` environment variables (export PGOPTIONS="-c work_mem=2GB"), or
* on a per-transaction basis using SQL (BEGIN; SELECT set_config('work_mem', '2GB', true); COMMIT;)
I've used each of these mechanisms to turn various knobs over the years. For example: one database has a small-ish global `temp_file_limit`, which was preferred and worked fine for years until a certain overnight job started failing. Rather than raise the limit globally, I changed it just for the single query in question.
> You can also manually inline everything, but if you have a lot of joins, you may end up tuning queries by changing join order. By default, if there are >8 joins it uses the order you give it.
This… isn't true. Pick two tables and compare:
EXPLAIN SELECT * FROM a JOIN b ON b.a_id=a.id;
EXPLAIN SELECT * FROM b JOIN a ON a.id=b.a_id;
PostgreSQL chooses the same plan for both queries. It may do `a` then `b`, or `b` then `a`, but in either case the plan will be stable given the set of analyzer statistics.
When the number of JOINs get large, the query planner does not consider every join order, since the number of possible orderings grows too large to search. This is where GEQO comes in:
> Refactoring your code to be as simple as possible
> Following style conventions for names, whitespace, etc.
> Replacing private information with environment variables
> Commenting your code to contextualize snippets within your broader codebase.
While I do wish more software was released under a FOSS license, I also wish that these points were a given for any codebase regardless of license or source disclosure policy. I really don't think you can be agile no matter how many agile-trademarked tools and processes you pile on top of your project if you don't do this first.
I keep hearing Americans refer to these boys as the "coke brothers". Is that a jab at their petroleum cracking activities producing massive amounts of coke, or do they actually call themselves the "coke brothers"?
That was the first place I looked, and by its descriptive nature it is indeed useful for ascertaining that people do in fact say "coke brothers". But the question asked was what the actual Koch brothers say.
It's of German origin, I would have assume it would be pronounced either as such[1], or anglicised with a k as in "stomach", which seems like the most common way for English speakers to deal with the troublesome voiceless velar fricative. Another option is to simply use the English cognate "Cook". "Coke" on the other hand seems far fetched enough that I wondered if it was some kind of a joke at the Koch brothers' expense.
I figured he had been sued for patent infringement or something. This must be written by someone who buys things at a discount and then believe the difference is an income she has earned and not buying it is a loss.
