Comment Re:Leave then (Score 1) 886
You said black people are not the same as gay people. That was pretty clear.
That mumbo jumbo about how laws don't count, only the constitution does is what I found hard to match up to reality.
You said black people are not the same as gay people. That was pretty clear.
That mumbo jumbo about how laws don't count, only the constitution does is what I found hard to match up to reality.
You may be afflicted with Christianity, but you should not seek to afflict others with it.
>I really wish people would stop trying to compare gays to black people. They are not the same.
Are you saying there are no gay black people?
I have friends who would be surprised to find that they are not what they think they are. You should let them know quickly. Don't delay. You are in possession of special new knowledge.
American aerospace contractors are displeased to note that NASA plans to have the Asteroid Redirect Vehicle fabbed on a 20nm process by TSMC, rather than more traditional launch partners...
NASA is displeased to find that TSMC's 20nm process is actually a planar 28nm process with the name changed. Elon Musk is upset that NASA didn't select his far superior 14nm trigate process that is superior in every metric.
This does very little to put us on a footing for a post-scarcity society. And we are assuredly on that path right now
No we're not. We have to solve the energy crisis first. That requires a dyson sphere, which will provide 13,000 trillion times the energy we use today.
That's a pretty bold claim for a vacuum cleaner.
No. He's right. It won't effect the future. The future will happen anyway.
In many organizations the App is not king. The database is.
For such organizations using an in-memory database is usually frowned upon. SQL is king of the hill.
Alas, ((Popular != Correct) && (Popular != Optimal) && (Popular != Secure)) == True.
If the business got that big, I'd be hiring people to do it for me and there would be some benefits to using more standard approaches since getting people who think like I do would suck and it would suck for employees to have to follow their boss's crazy ideas on the right way to make a responsive database for a point of sale environment.
But there's nothing preventing an in-memory database being duplicated, load balanced, redundantized (or whatever the right word is for adding redundant mirror servers) etc. In fact the consistency transactions are easier because the parties are algorithms talking to each other, rather than algorithms talking via a storage medium. You would have to write it yourself though since the world still seems to have a hard on for SQL long after they left Cobol behind, which is bad for the same reasons. In a point of sale situation, the order of transactions is not that important except for specific things, like you can't return an item before you've purchased it. So it's easy to post-hoc order the transaction log, a bit like the bitcoin block chain, where the current head of the list is indeterminate, but it's resolved a few steps back.
My issue isn't with disk vs. memory. That's a normal tradeoff. My issue is with SQL, which is horrible in every way that an insecure, computationaly undecidable lump of middleware can be.
How do you maintain relational constraints?
With a few lines of python that put constraints in the database.
Why said Oracle was an option being considered?
I've used a few databases and they all suck with layers of excess complexity. BDB and related DBs are ok. They don't suffer interface bloat nearly as much. A Turing complete query language is completely stupid from a security standpoint.
I'm moving to an in-memory database held in a running program with the client transaction atomicity enforced through the API and with a transaction log to disk from which the running state can be re-built.
It used to be a problem to keep things in memory, but I can drop 64Gig of RAM in a server and keep all the store inventory and sale data live. The clients don't know the difference, except they don't have to deal with build SQL strings or typing the schema to the constraints of the latest and greatest ORM to come along this week.
God I hate SQL databases.
More like for 100% of tasks.
I tried invoking it on the Linux server that runs my back end and it couldn't even find it. It's worse than useless for that task.
She's a third year physics major. She knows exactly what she wants. MBPs, fuck off with that fanboy shit. You've never used OS X UNIX if you think it's anything like GNU.
Troll a lol a lol.
Maybe she does. Or maybe she wants a general Linuxy feel, where you can open a bash shell, run vim inside emacs and 'rm -rf *' does what you expect.
The mac works fine for this and the hardware is very good.
You can run Linux on a mac if you want to.
A Macbook Pro is a good answer. Any number of modern PC laptops would be fine also. There's no obvious best choice.
Second, what's you're requirement for not having the security benefit? Given that certs are about $10 a year and require negligible resources, what is your compelling reason for not having encryption by default?
Don't the government have their own CA? The cost to cut a cert should be less than $0.04. I know this because I've set up a real CA and $0.04 per cert included the costs of the operations along with the profit. The actual computing cost is negligible. The costs are the premises and pay for employees, spread out across all the certs they cut.
I'm referring to the early 80s, with things like Hard Hat Mack, Archon II, Pinball Construction Set, The Bard's Tale. At that age I was a consumer, not a developer. I missed the Nintendo thing, since I had 'real' computers.
So it's safe to say the rot happened sometime between 1985 and 1995.
Lawrence Radiation Laboratory keeps all its data in an old gray trunk.
