It would certainly be nice if they fixed the performance of shared folders. That would make it much more practical to run multiple VM's on a single machine.
See http://mitchellh.com/comparing... for some interesting info.
I tried this myself, and it's true -- read performance on shared folders is many times slower than virtual disks, making them fairly useless.
Wildly inaccurate. The typical spread (prior to decimalization) for actively traded issues was more like 6.25cents (a sixteenth), which was the difference between the bid and ask prices. A market-maker (or specialist) would typically kick back some of the spread to both market participants in the form of "price improvement", so the actual spread pocketed by the market-maker was probably more like 3-4cents.
For this, the market-maker assumed risk by committing capital to maintain a position in a security, and also was responsible for "maintaining an orderly market" in the securities in which it made markets. (In practice, NYSE specialists were much more accountable than NASDAQ market-makers).
In retrospect, this appears to have been a small price to pay.
For me, it was the Tom Swift books. But I agree with the others who are saying:
- keep it simple (Dune? Are you kidding?)
- the hero/heroine should be a kid
- some of the older Asimov etc. "juveniles" could be a problem, just because they are so out-of-date by now.
I used to have a co. that sold budgeting software for commercial film production, and I can tell you from experience that if your prospective customers can use your software without paying for it, they will. (OK, not all of them, just most of them). I ended up using hardware dongles, and while they were a big PITA for both me and my customers, the alternative would have been to simply give the software away.
Actually, it's not so much about the spread as it is about the size. The decimalization of the markets in 2001 had the effect of fragmenting liquidity, by allowing arbitragers to "ping" the market with orders with very little risk. (Google "SOES bandit" for more info).
Also, 25-cent spreads (a "quarter") had all but disappeared by that time, except for very thinly-traded issues. The average spread was a "steenth" (6.25 cents) back in those days, and in retrospect that wasn't so bad. It left enough room for both buying and selling broker to make a little money while giving the customer "price improvement" -- i.e., a better-than-quoted price -- esp. for large trades.
The SEC's rataionale for moving to decimal pricing was apparently to help the "little guy", but it missed the point that most "little guys" have their money invested with big mutual funds, etc. Decimalization actually hurt them (and their little-guy customers) by fragmenting liquidity to the point that it became very difficult to execute large orders without "price impact" (which is when arbitragers find out that a big fund is buying or selling and try to jump ahead).
At the time I was consulting with the 2nd largest "wholesale" broker on Nasdaq, and they shut down the business because they could not make money at sub-penny spreads. Fewer market-makers means less liquidity which leads to situations like the May "flash crash" where so-called "market-makers" run for cover by posting "stub quotes", rather than "maintaining an orderly market" as specialists on traditional exchanges are required to do.
Yes, specialists and market-makers made good money back in the old days, but for the most part, they earned it by risking their own capital. (And by having a vested interest in the overall health of the markets). When all is considered, it seems that "we" (as in society) may be paying a much higher price today.
The securities markets are open to all -- including "investors" (i.e., those who buy with a "long-term" horizon, whatever that is these days) and speculators. The speculators engage in what is called arbitrage -- finding discrepancies in the market and taking advantage of those discrepancies to make a profit.
It can be argued that the speculators serve a useful purpose by keeping the markets "efficient" -- i.e., making sure that prices don't get too out-of-whack.
To a large extent, this problem was caused in the late 90's when the SEC mandated that stock prices be quoted in pennies rather than the quaint eighths, sixteenths, etc. (of a dollar). This led to traders being able to game the system with minimal risk by "stepping in front" of published (and presumably real) quotes for a dollar (i.e., a penny times 100 shares, which is a "round-lot" order).
The idea of decimalization was that it would benefit the small investor, but in fact most small investors (i.e., you and me) invest through mutual funds or something similar, typically managed by an "institutional investor" (e.g., Fidelity). The narrowing of the bid-ask spread made it much more difficult for institutional investors to find large blocks of liquidity without "market impact" (what happens when other traders find out if there's a big buyer or seller in the market).
There are markets are designed for institutional investors and that don't exhibit this behavior -- one is a company called Liquidnet, which only allows institutional investors and specifically excludes the "sell-side" traders because of the problems mentioned above.
There is a lot more to it, and yes, the markets continue to get faster, with "co-location" being an important factor now (because the speed of light is "too slow", many traders locate their computers in the same data center as the exchanges to eliminate transmission delays). Some traders boast of microsecond and even nanosecond latencies, but for the most part they are cooking those numbers to make them look better than they really are.
In the past, I've dealt with these kinds of things by creating a virtual machine with required VPN, AV, etc. etc. and use the VM image to access the network.
Sorry, but I do this for a living, and nobody who has a clue is using Java for low-latency application development. All the benchmarks and whitepapers are fine and dandy, but in the REAL WORLD, Java simply can't handle (very) heavy loads without falling over.
I don't know why that is, but suspect that it's simply a matter of too many frickin' layers.
The other issue is that Java performance is simply not deterministic because of the GC -- everything is fine for a while, and then you have a 100ms spike when the VM decides to do GC. And yes, I know that there's a lot of work going on to address that, and some of it is promising, but it simply ain't there yet.
I have no idea how much of this is also applicable to.Net, although I suspect at least some of it is. I also suspect that the bigger problem is that the whole project ended up being a gigantic clusterfsck, between Microsoft and Accenture (and who the heck thought Accenture knew anything about designing trading systems anyway?)
Last point: you think that was bad -- the volumes in UK are WAY lower than here in the US, so one can only imagine what would happen if they tried to roll out something like this in a really high-volume environment.
If you read about this you'll find that he was intrigued by the idea of creating a 6-second piece of music that would actually be... well, music. (http://en.wikipedia.org/wiki/Brian_Eno#The_Microsoft_Sound)
Some of his other "innovations" include "oblique strategies" (http://www.kk.org/cooltools/archives/000914.php) and "Frippertronics" (http://en.wikipedia.org/wiki/Frippertronics).
I once had an early morning job interview that I really didn't want to be late for. As I'm a heavy sleeper, I was a bit worried about it -- my solution was to plug a vacuum cleaner into my clock radio (which had a switched outlet on the back). That did the trick!
++ to BC! (http://scootersoftware.com/)
If you only go in one direction, automated or semi-automated tools are great (e.g., robocopy on win). But I've never trusted automatic bi-directional replication -- just because one file is older than another doesn't mean it doesn't contain info that the newer file doesn't. BC makes reconciliing different directories and files as pleasant as possible.
Depends on whether you want to "manage" the docs, or just be able to find them. The google thing looks promising (http://ask.slashdot.org/comments.pl?sid=1264509&cid=28285635), and is probably a LOT cheaper to get going with. Then, if you think you need more you could look at some of the more heavyweight solutions.
"Perfect is the enemy of the good" -- Voltaire
You can run a network over it using something called "homelink" -- runs at 10Mbps, and is apparently similar to DSL. I had one for a while, and it mostly worked OK.
Geez -- I think I may actually hold the patent -- at least I have prior art that goes back to 1995 at least. (Oops -- the idea was old even back then).
Well it doesn't hurt to expand your horizons a bit. My son has a Logitech 5.1 speaker system, which he loves because it has "good" (i.e., loud) bass, but the muddy sound drove me nuts.
So I bought him a pair of monitor speakers for his birthday, and he couldn't believe the stuff he was hearing for the first time. Short version is, he's really happy with the new setup (monitor + surround).
Hear, hear!
One of the H1B's I worked with (great guy, really smart) HAD to live in company-provided housing (that was part of the deal). He was paid substantially less than market wages because he was in reality an "indentured servant", AND he paid back a substantial chunk of that in rent to his employers (a large Indian consulting co.).
" You load sixteen tons, and what do you get?
Another day older and deeper in debt.
Saint Peter, don't you call me, 'cause I can't go;
I owe my soul to the company store... " - Merle Travis, "Sixteen Tons"
then things might be different. As it is, the H1B program has merely managed to feed the "fat cats" without improving the lot of US citizens.
By all means, encourage immigration of hard-working, talented, intelligent people.
But allow them to control their own destinies and compete without handicapping them or US citizens by institutionalizing a system that unfairly depresses wages for all.
Maybe we've just reached a sort of equilibrium here, where US wages have stagnated while the rest of world's has grown.
Add scarab/collabnet to the list of junk. It seems designed solely to give PHB's (not-so) pretty reports to look at. Sheesh -- can't even do a text search (I guess that's why God gave us eyeballs).
Actually, no they don't. Don't worry -- you'll understand in a few years:-)
The problem -- even for people with "normal" vision -- is that as you age you get more far-sighted, so you need correction for that. Of course, that correction totally screws up your near vision. So you end up needing different sets of glasses for reading, driving, etc.
And if you are already near-sighted, it's not like they cancel out -- you just get to be BOTH near-sighted AND far-sighted. Big PITA!
Don't even get me started on macular degeneration, glaucoma, cataracts, etc.
Here is what I ask candidates:
1. What is the hardest problem you (personally) have ever had to solve? What was your approach? Why did it succeed/fail?
2. What is the hardest NON-TECHNICAL problem you have ever had to solve? (Note that most people assume question #1 refers to technical problems, which is not unreasonable). What was your approach? Why did it succeed/fail?
3. If there was only one thing you would like me to know about you, what is it?
4. What question are you dying for me to ask you? (I'm assuming here that it's because you think you have a really great answer for this question -- OK, let's hear it).
In a half-hour I can usually tell who's a maker, who's a faker and who's a taker.
While there are a number of ways to capture and diff information (VM's probably being the best), the diff's may be a bit hard to interpret, depending on what you're trying to identify -- otherwise diff's will just show you that two files have different bit patterns, but what do those bits mean?
Two areas immediately spring to mind:
- the registry is probably the most important object you want to monitor, so you'll need to somehow export the registry into a diff-able format.
- windows also uses "structured storage" (basically a filesystem in a file) for a lot of things -- you'll also need to be able to export those somehow?
Slashdot Mirror
It would certainly be nice if they fixed the performance of shared folders. That would make it much more practical to run multiple VM's on a single machine. See http://mitchellh.com/comparing... for some interesting info. I tried this myself, and it's true -- read performance on shared folders is many times slower than virtual disks, making them fairly useless.
Wildly inaccurate. The typical spread (prior to decimalization) for actively traded issues was more like 6.25cents (a sixteenth), which was the difference between the bid and ask prices. A market-maker (or specialist) would typically kick back some of the spread to both market participants in the form of "price improvement", so the actual spread pocketed by the market-maker was probably more like 3-4cents.
For this, the market-maker assumed risk by committing capital to maintain a position in a security, and also was responsible for "maintaining an orderly market" in the securities in which it made markets. (In practice, NYSE specialists were much more accountable than NASDAQ market-makers).
In retrospect, this appears to have been a small price to pay.
For me, it was the Tom Swift books. But I agree with the others who are saying:
- keep it simple (Dune? Are you kidding?)
- the hero/heroine should be a kid
- some of the older Asimov etc. "juveniles" could be a problem, just because they are so out-of-date by now.
Have fun!
I used to have a co. that sold budgeting software for commercial film production, and I can tell you from experience that if your prospective customers can use your software without paying for it, they will. (OK, not all of them, just most of them).
I ended up using hardware dongles, and while they were a big PITA for both me and my customers, the alternative would have been to simply give the software away.
Actually, it's not so much about the spread as it is about the size. The decimalization of the markets in 2001 had the effect of fragmenting liquidity, by allowing arbitragers to "ping" the market with orders with very little risk. (Google "SOES bandit" for more info).
Also, 25-cent spreads (a "quarter") had all but disappeared by that time, except for very thinly-traded issues. The average spread was a "steenth" (6.25 cents) back in those days, and in retrospect that wasn't so bad. It left enough room for both buying and selling broker to make a little money while giving the customer "price improvement" -- i.e., a better-than-quoted price -- esp. for large trades.
The SEC's rataionale for moving to decimal pricing was apparently to help the "little guy", but it missed the point that most "little guys" have their money invested with big mutual funds, etc. Decimalization actually hurt them (and their little-guy customers) by fragmenting liquidity to the point that it became very difficult to execute large orders without "price impact" (which is when arbitragers find out that a big fund is buying or selling and try to jump ahead).
At the time I was consulting with the 2nd largest "wholesale" broker on Nasdaq, and they shut down the business because they could not make money at sub-penny spreads. Fewer market-makers means less liquidity which leads to situations like the May "flash crash" where so-called "market-makers" run for cover by posting "stub quotes", rather than "maintaining an orderly market" as specialists on traditional exchanges are required to do.
Yes, specialists and market-makers made good money back in the old days, but for the most part, they earned it by risking their own capital. (And by having a vested interest in the overall health of the markets). When all is considered, it seems that "we" (as in society) may be paying a much higher price today.
The securities markets are open to all -- including "investors" (i.e., those who buy with a "long-term" horizon, whatever that is these days) and speculators. The speculators engage in what is called arbitrage -- finding discrepancies in the market and taking advantage of those discrepancies to make a profit.
It can be argued that the speculators serve a useful purpose by keeping the markets "efficient" -- i.e., making sure that prices don't get too out-of-whack.
To a large extent, this problem was caused in the late 90's when the SEC mandated that stock prices be quoted in pennies rather than the quaint eighths, sixteenths, etc. (of a dollar). This led to traders being able to game the system with minimal risk by "stepping in front" of published (and presumably real) quotes for a dollar (i.e., a penny times 100 shares, which is a "round-lot" order).
The idea of decimalization was that it would benefit the small investor, but in fact most small investors (i.e., you and me) invest through mutual funds or something similar, typically managed by an "institutional investor" (e.g., Fidelity). The narrowing of the bid-ask spread made it much more difficult for institutional investors to find large blocks of liquidity without "market impact" (what happens when other traders find out if there's a big buyer or seller in the market).
There are markets are designed for institutional investors and that don't exhibit this behavior -- one is a company called Liquidnet, which only allows institutional investors and specifically excludes the "sell-side" traders because of the problems mentioned above.
There is a lot more to it, and yes, the markets continue to get faster, with "co-location" being an important factor now (because the speed of light is "too slow", many traders locate their computers in the same data center as the exchanges to eliminate transmission delays). Some traders boast of microsecond and even nanosecond latencies, but for the most part they are cooking those numbers to make them look better than they really are.
In the past, I've dealt with these kinds of things by creating a virtual machine with required VPN, AV, etc. etc. and use the VM image to access the network.
Sorry, but I do this for a living, and nobody who has a clue is using Java for low-latency application development. All the benchmarks and whitepapers are fine and dandy, but in the REAL WORLD, Java simply can't handle (very) heavy loads without falling over. .Net, although I suspect at least some of it is. I also suspect that the bigger problem is that the whole project ended up being a gigantic clusterfsck, between Microsoft and Accenture (and who the heck thought Accenture knew anything about designing trading systems anyway?)
I don't know why that is, but suspect that it's simply a matter of too many frickin' layers.
The other issue is that Java performance is simply not deterministic because of the GC -- everything is fine for a while, and then you have a 100ms spike when the VM decides to do GC. And yes, I know that there's a lot of work going on to address that, and some of it is promising, but it simply ain't there yet.
I have no idea how much of this is also applicable to
Last point: you think that was bad -- the volumes in UK are WAY lower than here in the US, so one can only imagine what would happen if they tried to roll out something like this in a really high-volume environment.
If you read about this you'll find that he was intrigued by the idea of creating a 6-second piece of music that would actually be... well, music. (http://en.wikipedia.org/wiki/Brian_Eno#The_Microsoft_Sound) Some of his other "innovations" include "oblique strategies" (http://www.kk.org/cooltools/archives/000914.php) and "Frippertronics" (http://en.wikipedia.org/wiki/Frippertronics).
I once had an early morning job interview that I really didn't want to be late for. As I'm a heavy sleeper, I was a bit worried about it -- my solution was to plug a vacuum cleaner into my clock radio (which had a switched outlet on the back). That did the trick!
++ to BC! (http://scootersoftware.com/)
If you only go in one direction, automated or semi-automated tools are great (e.g., robocopy on win). But I've never trusted automatic bi-directional replication -- just because one file is older than another doesn't mean it doesn't contain info that the newer file doesn't.
BC makes reconciliing different directories and files as pleasant as possible.
Depends on whether you want to "manage" the docs, or just be able to find them. The google thing looks promising (http://ask.slashdot.org/comments.pl?sid=1264509&cid=28285635), and is probably a LOT cheaper to get going with. Then, if you think you need more you could look at some of the more heavyweight solutions.
"Perfect is the enemy of the good" -- Voltaire
You can run a network over it using something called "homelink" -- runs at 10Mbps, and is apparently similar to DSL. I had one for a while, and it mostly worked OK.
Geez -- I think I may actually hold the patent -- at least I have prior art that goes back to 1995 at least. (Oops -- the idea was old even back then).
The other thing you want to check is support for clock sync between host and guest OS's with your vm of choice. For instance, Vmware has had lots of issues with this, esp. w/AMD chips and/or Windows hosts (e.g., http://kb.vmware.com/selfservice/microsites/search.do?cmd=displayKC&docType=kc&externalId=916&sliceId=2&docTypeID=DT_KB_1_1&dialogID=10148667&stateId=0%200%2012087601)
Well it doesn't hurt to expand your horizons a bit. My son has a Logitech 5.1 speaker system, which he loves because it has "good" (i.e., loud) bass, but the muddy sound drove me nuts.
So I bought him a pair of monitor speakers for his birthday, and he couldn't believe the stuff he was hearing for the first time. Short version is, he's really happy with the new setup (monitor + surround).
Hear, hear! One of the H1B's I worked with (great guy, really smart) HAD to live in company-provided housing (that was part of the deal).
He was paid substantially less than market wages because he was in reality an "indentured servant", AND he paid back a substantial chunk of that in rent to his employers (a large Indian consulting co.).
" You load sixteen tons, and what do you get? Another day older and deeper in debt. Saint Peter, don't you call me, 'cause I can't go; I owe my soul to the company store... "
- Merle Travis, "Sixteen Tons"
then things might be different.
As it is, the H1B program has merely managed to feed the "fat cats" without improving the lot of US citizens.
By all means, encourage immigration of hard-working, talented, intelligent people.
But allow them to control their own destinies and compete without handicapping them or US citizens by institutionalizing a system that unfairly depresses wages for all.
Maybe we've just reached a sort of equilibrium here, where US wages have stagnated while the rest of world's has grown.
Add scarab/collabnet to the list of junk. It seems designed solely to give PHB's (not-so) pretty reports to look at.
Sheesh -- can't even do a text search (I guess that's why God gave us eyeballs).
Concur. Have had this happen to me. It's easy and quick to check.
Actually, no they don't. Don't worry -- you'll understand in a few years :-)
The problem -- even for people with "normal" vision -- is that as you age you get more far-sighted, so you need correction for that. Of course, that correction totally screws up your near vision. So you end up needing different sets of glasses for reading, driving, etc.
And if you are already near-sighted, it's not like they cancel out -- you just get to be BOTH near-sighted AND far-sighted. Big PITA!
Don't even get me started on macular degeneration, glaucoma, cataracts, etc.
Here is what I ask candidates:
1. What is the hardest problem you (personally) have ever had to solve? What was your approach? Why did it succeed/fail?
2. What is the hardest NON-TECHNICAL problem you have ever had to solve? (Note that most people assume question #1 refers to technical problems, which is not unreasonable). What was your approach? Why did it succeed/fail?
3. If there was only one thing you would like me to know about you, what is it?
4. What question are you dying for me to ask you? (I'm assuming here that it's because you think you have a really great answer for this question -- OK, let's hear it).
In a half-hour I can usually tell who's a maker, who's a faker and who's a taker.
Two areas immediately spring to mind:
- the registry is probably the most important object you want to monitor, so you'll need to somehow export the registry into a diff-able format.
- windows also uses "structured storage" (basically a filesystem in a file) for a lot of things -- you'll also need to be able to export those somehow?
Just what is it that makes ORM a non-starter for this project?