If you talk to a school administrator and ask them to recover from the nightly backups, you are likely to get a blank stare back. School districts and schools couldn't be worse set up to deal with complex system recovery.
The apple mouse, the one with the touch panel where the buttons would be seems to manage this. You can configure it to register a middle tap as a middle click and disable the scroll function. Not that I play many games on my mac. Why you can't disable the scroll with normal mice is beyond me. I'd pay extra for a switch array on the bottom, just like Happy Hacking do with their keyboards.
In fact, we need the Happy Hacking people to make a mouse. They wouldn't screw it up.
A gaming mouse should be tailored to a user's hand. That means a slanted one handed mouse. The entire point of the exercise is to get a mouse that is suitable for YOU, not "suitable for everybody".
My fingers appear to have been the result of an evolutionary process that allows the fingers to flex and form to the shape of the thing it is gripping, whether bilaterally symmetric or bilaterally asymmetric.
>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.
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.
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.
Slashdot Mirror
If there is a vacuum in space, would their need to be a corresponding antivacuum?
There is an antivacuum in the universe . . . more specifically, in my apartment.
At least that is what my cleaning girl claims . . . when she tries to vacuum here . . .
An antivacuum is usually called 'gas'.
I've done that. CeBit in Hanover. I didn't get to wear chaps though.
I was envisaging one of those black, spikey gaming mouses. I can see how that mouse might work well.
Sometimes brute force is preferred.
No, I don't.
TFA quotes the RSA test which states: "These guidelines are applicable to all booth staff, regardless of gender"
I wonder why they didn't include Cowboy chaps and codpieces, but maybe that's not a big issue on the floor.
How dare you oppress me and my right as a man to be slutty.
Unless you're playing nethack through an Xterm.
Are you plating nethack through a Xterm? If not, why not?
I'm doing all right with it. I don't suffer from excess dogma though.
Not if it's symmetric. But a side button for the thumb would suck on an asymmetric mouse.
I first grabbed a computer mouse in 1984 and I've been using them ever since, without hand pain. How long to I have to wait to find out?
The only issues I have with computer mice is the button configuration and the crap that builds on up the bottom.
If you talk to a school administrator and ask them to recover from the nightly backups, you are likely to get a blank stare back.
School districts and schools couldn't be worse set up to deal with complex system recovery.
> Touch panels are terrible.
For games, yes.
It's pretty neat for my mac where I can switch pretty seamlessly between 'X mode' and mac mode, depending on what window I'm in.
The apple mouse, the one with the touch panel where the buttons would be seems to manage this. You can configure it to register a middle tap as a middle click and disable the scroll function. Not that I play many games on my mac. Why you can't disable the scroll with normal mice is beyond me. I'd pay extra for a switch array on the bottom, just like Happy Hacking do with their keyboards.
In fact, we need the Happy Hacking people to make a mouse. They wouldn't screw it up.
A gaming mouse should be tailored to a user's hand. That means a slanted one handed mouse. The entire point of the exercise is to get a mouse that is suitable for YOU, not "suitable for everybody".
My fingers appear to have been the result of an evolutionary process that allows the fingers to flex and form to the shape of the thing it is gripping, whether bilaterally symmetric or bilaterally asymmetric.
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.