The "stockholders" consist of fund managers and traders who are simply engaged in gambling. They don't care about who runs the company, because they will likely be out of the stock by the end of the week.
You should review Yahoo's DEF-14A. Yes, the top three stockholders appeared to be funds. No, they're probably not trading it actively, because trying to buy or sell 90 million shares is guaranteed to move the price against you. Yes, they're interested in the company's chief officers, but probably only for quarterly profit, and not the long-term (decades and beyond) success of Yahoo!.
In the case of HFT operations, shares are held for milliseconds, with no human even knowing which companies were invested in.
You can bet your ass that every HFT operation knows YHOO; there is always a person behind the algorithm. And yes, there's probably a large share volume being traded by HFT algorithms and market makers. However, the total number shares owned by these organizations at "voting time" is probably next to nothing. You don't get voting rights just for having the stock passed through your hands: you actually have to hold onto it (at least for one day), which is antithetical to any form of day-trading.
The whole stock market and share system has become a den of rank iniquity. But people still believe in it, and still trust their life savings to it.
Someone who is entrusting their entire savings to the stock market is either (1) young, (2) stupid, or (3) isn't paying attention. For retirement investments, the stock market is advertised as high-risk/high-reward and is not suitable for lump-sum liquidation. I agree with you that too many Americans don't treat it this way, and this is a travesty. But please don't be bitter at the stock market for being the speculative arena that it always has been.
The problem is, how do you GUARANTEE that with this ISP-managed method, my Minecraft server doesn't get shafted and its packets dropped to the end of the queue/back of the buffer?
Whether you like it or not, the ISP is managing your packets, and when packet queuing happens something has to suffer (but a good ISP will specifically target latency-insensitive packets for this, such as known torrents, large HTTP transfers, FTP, etc). If you want GUARANTEED bandwidth to reduce bandwidth and packet loss, you need to be prepared to pay for it. Barring that, If you simply believe that your minecraft traffic is being dropped more than other traffic, I would suggest measuring the packet loss and raising a stink (whether formally via suit or via a visit to the local office is up to you... YMMV depending on the ISP). There's actually a decent chance that the excessive packet loss/delay isn't intentional, but if nobody complains they won't ever see the "bug".
If the shareholders win, the company pays the shareholders X dollars minus legal fees, the value of the company decreases by X dollars plus legal fees.
FTFY. I guess the silver lining is "everyone else gets a jolly good laugh."
Exchanges should prohibit these types of games by instituting a random delay of one to two minutes on every trade in the system. Why should a big investment bank with a room full of computers be able to do what the man in the street can't?
If you don't want to compete with an automated system, you can restrict your stock trading activity to the opening and closing auctions. Everyone gets the same price!
This is not least because the algorithms lack necessary human qualities of a rogue, such as sneak attack, trapfinding, improved evasion, and a profit motive.
It's still common practice for hedge funds to buy and sell stocks with knowledge of what the prices will be ahead of time on some of the smaller exchanges
The time frame for which the future price is available has shrunk significantly since the 20s, but it's still there.
Well I bet it's certainly shrunk a lot in the last few years, given that the US stock market is governed as a National Market System. In other words, that behavior (presumably arbitrage between exchanges and giving brokerage customers the worse price) is illegal.
I'm sorry, I'm not sure if you're arguing in favor of zero-sum or against it, so I'm just going to embellish upon your comments:
You are ignoring dividends, splits, reverse splits
All of which adjust the price of the stock appropriately, so the net capital is the same. 20% dividend issued on a $50 stock? It opens at $40 the next day, with $10/share added to the accounts of the shareholders. The $50/share of wealth still exists. Stock splits? Now twice the number of shares exist at half the price, same wealth.
not to mention all the friction from trade costs.
That friction (which some call "skimming", depending on how much vitriol they want to inject into the conversation) is what pays for the services of exchanges, regulators, and market makers. The wealth still exists, it just stops becoming "shares" and turns back into "money". Glorious, Swimmable, Scrooge McDuck money.
Your second point addresses this. "They provide liquidity." Maybe that's a valuable service but there's been a number of posts here claiming that they don't actually provide that.
Providing liquidity is useful because it reduces bid/ask spreads and lowers volatility. However, as at least one other poster mentioned, most HFTs—most traders, really—are not required to provide liquidity. That role is reserved for a handful of entrenched registered/lead/designated market makers (most of which are probably HFTs by now, simply out of necessity).
Also, I have a 24 hour convenience store here that I never use. There is no way in the world I would pay them just to be there even if I never bought anything from them.
To continue the analogy, you only "pay" for liquidity when you trade. A long-term investor should only be interacting with the market once a month, or once a quarter. You're not funding HFTs or market makers unless you trade on a regular basis. In short, I agree with you: you shouldn't pay for liquidity that you don't use. You don't.
Maybe for single-player games, but not for competitive twitch-games online. Most modern LCDs come with gobs of post-processing that puts display latency up to the 100-200ms range (of course, you turn this off if you care). I find it extreme enough to absolutely destroy my shotgun accuracy in a local split-screen game. I expect remote rendering would have a similar effect, only worse because the Internet is less deterministic than a TV's post-processing pipeline.
In fact, every console game that Eurogamer measured had at least 67ms of latency, and they claim that the average seemed to be about 133ms. Gamers are clearly willing to accept this latency...
GTA players may be willing to put up with high latency, but that doesn't fly so well with button-combo-fighting games (Soul Calibur, Street Fighter both 67ms) or competitive FPS games (CoD:MW 67-84ms). Those games just will not work with the additional latency of remote rendering over the Internet. 50ms light speed one way becomes 100ms round trip minimum, and it dramatically increases the probability of packet loss (mo' bandwidth, mo' problems).
What is the actual right / normal course of action?
Allowing the user to specify "empty" vs. "nonexistent" is almost always the wrong answer.
In general, data for human contact is either provided or nonexistent, not empty. This can be name components, address components, phone numbers, etc.
It's hard to set a generalized rule for handling of other inputs, but typically the data model will dictate whether a given "string" datum is optional (NULLable), or whether it has content requirements (empty allowed). Very little data is both optional and allowed to be empty. So keep your interface clean, and do the mapping behind the scenes for data cleanliness.
When I talked about buffering up to a minute ahead to cover up hiccups up to a minute, I was thinking more of feature films (>= 90 minutes) or at least TV series episodes (24-48 minutes). This wouldn't work for the 1- to 3-minute videos common on YouTube.
Agreed on short videos, but many HD videos on YouTube are long. The ones I watch are daily publications lasting between 10-45 minutes. I know that on my connection I can always watch 480p, never watch 1080p, and off-peak usually watch 720p in order to avoid buffering mid-program.
And I'm not sure what you mean by "ham-fist", other than what YouTube already does (provide the first 10 seconds or so in a burst, and the rest of the video just above real time).
By "ham-fist" I mean reducing the buffers proportional to the increase in bandwidth. Such an action may sound reasonable to a bean-counter; but it doesn't reduce the probability of a stall, merely the impact. Such a reduction also increases the sensitivity to other transient events that don't improve with the network (e.g. wireless interference due to a microwave oven).
From the consumer's point of view, what's the point of downloading faster than one can listen?
Higher bandwidth means a reduction in the number of stalls for transient problems or high utilization. I won't see my HD youtube videos spend as much time paused and buffering, because the probability of insufficient buffered data goes down (unless you ham-fist the buffering algorithm).
Oh come on. Even Firefox with its single-threaded blocking-at-every-excuse implementation can't possibly botch a simple select-read-write -loop to this extent.
Several things could come into play here to cause FF to have poorer bandwidth than wget.
buffer size tuning: If the OS (or FF, if it overrides) provides buffer sizes that are too small, the TCP protocol is designed to apply backpressure to the sender, slowing down total file transfer.
process scheduling: if the OS is frequently unable (or unwilling) to schedule FF while data is available to read, then you end up exacerbating any buffer-size issues. I expect that FF does more work while idling than wget, leading to potential schedule penalties.
TCP congestion behavior: If the sending side decides that the receiving side dropped a packet, it may (temporarily) reset its sending window to the worst possible value (1 byte? 1 MTU? I don't know, TBH).
You may actually get a perfect storm where FF's buffers fill up due to poor scheduler performance, causing the OS to drop packets, causing the sender to slam on the brakes until FF catches up. Lather, rinse, repeat. Of course, all of this is perfectly testable with tcpdump, so unless the GP is willing to cough up a packet capture I would consider his statement hearsay.
I really like this book because Lakos breaks down intermodule relationships very well, something that doesn't get enough (or any) discussion from other popular references. However, it's very clear that he grew up in an age with shitty C++ compilers. IIRC he had some weird recommendations like avoiding namespaces and duplicating header guards outside of #include directives.
A separate init() method encourages reuse of objects, making it easier to make them members by reference or value.
If "being uninitialized" is a well-defined state for the object, then I agree. For example, you can have an empty container, an empty string, or a disconnected TCP "connection" (fd==-1 is a natural state, and instead of init() you have connect() or bind()). OTOH, I frequently discourage my co-workers from reusing value-objects. It's just as easy to say homeAddress=StreetAddress(street,unit,city,state,zip) as it is to say homeAddress.init(street,unit,city,state,zip). I have seen the latter pattern contribute to bugs when somebody added a member variable and didn't think to add it to the init() method, whereas nobody seems to accidentally omit it from the constructor.
Modern C++ compilers put the unwinding logic in other pages. The C++ one can be faster if errors are rare, but slower if errors are common.
I've looked at this myself. It is very nice that in C++ the "default" way of approaching error handling with RAII plays nicely with the compiler's static branch prediction logic. However, it's not a sufficient argument for truly high-performance code. Either your compiler provides conventions on static branch prediction or it provides intrinsics such as __builtin_expect that give you control. Both of these will give you the same benefits as the C++ RAII style, and (in my experience) neither approach gums up the logic enough to hurt readability.
For instance, when the stream gets an indication that the TCP connection was disconnected, they could perhaps try to re-establish the connection, but if that doesn't work it should throw the DisconnectedException it got up to their caller until either something either fixes the problem or the application crashes.
Please humor my pedantry, but perhaps this is a bad example. A TCP connection is a stream, so any other stream based on a TCP connection is not at the appropriate abstraction level to catch anything. If it's an HTTP connection (with an in-flight GET request that may have been lost), let that layer handle restarting the stream and re-issuing the request. If it's a lossey stream of video data, let that layer restart the stream, wait for the next keyframe to show up in the input, and resume sending new data. I regularly see people writing "adapter" layers such as a TCP iostream wrapper and trying to handle exceptions when it is wholly inappropriate to do so—they should simply guarantee some level of exception safety and then get out.
What you want to do in an exception handler is fix what you can, and throw up the call chain what you can't.
IMHO, what you really want to do is replace the exception handler with a RAII "guard" object that will perform cleanup in its destructor if.commit() has not been called. This gives you all of the benefits of a try/catch block without forcing the try/catch on your parents. Keep in mind that if an exception is thrown with no outer try block, the program may omit stack unwinding and abort with a nice healthy core dump. If a single "middleware" layer inserted a try/catch block with a re-throw, then your stack trace shows up in the middleware's (usually useless) function and the source of the std::out_of_range remains a mystery. (note: this is probably undefined behavior, but it is damn nice and worth leveraging.)
They had no problem with a "merger" when they acquired Nextel or the other companies that formed what is now Sprint. This block is clearly politically motivated thuggery and greed.
The ATT/Tmobile merger just screams "too big to fail" to me. I would consider it thuggery to allow such a merger given the history of the Bells; Sprint/Nextel OTOH were comparatively small potatoes.
I look forward to his future articles on the evils of pencils, the alphabet, and whiskey.
Dear Sir,
I noticed that the bottle in your cabinet was over a decade old (!), so I took the liberty of discarding it in the refuse and replacing it with a fresh bottle. I didn't want you to get food poisoning. I trust you will appreciate this attentiveness.
I admit my crappy service threshold is a tad high—it took three bad experiences at two locations before I gave up on a franchise.
I don't think that's high. I agree, it doesn't make sense to write off a restaurant for a single bad experience after repeated good experiences. "Vote with your dollar" is the usual mantra, but for a small/local restaurant "Talk to the manager" is probably more effective.
Perhaps the GP was already on the fence about the establishment, with the raw GroupOn deal only being the "last straw".
Whats the price difference between 2 600GB mechanicals and the 1 1TB drive?
The limiting factor may be space. If the 1x1TB drive fits into a 1U enclosure but the 2x600GB drive requires a 2U enclosure, it may not be worth doubling your datacenter rack space for the storage.
The limiting factor may be reliability. Mechanical drives fail frequently on startup/shutdown due to temperature changes. Putting two mechanical drives in a host (instead of one solid-state) sounds like a good way to increase failure rates, with all other things being equal. Even comparing two RAID0 arrays, SSD should be more reliable. YMMV with current offerings on the market.
Slashdot Mirror
Fire and acid, my friend.
You should review Yahoo's DEF-14A. Yes, the top three stockholders appeared to be funds. No, they're probably not trading it actively, because trying to buy or sell 90 million shares is guaranteed to move the price against you. Yes, they're interested in the company's chief officers, but probably only for quarterly profit, and not the long-term (decades and beyond) success of Yahoo!.
You can bet your ass that every HFT operation knows YHOO; there is always a person behind the algorithm. And yes, there's probably a large share volume being traded by HFT algorithms and market makers. However, the total number shares owned by these organizations at "voting time" is probably next to nothing. You don't get voting rights just for having the stock passed through your hands: you actually have to hold onto it (at least for one day), which is antithetical to any form of day-trading.
Someone who is entrusting their entire savings to the stock market is either (1) young, (2) stupid, or (3) isn't paying attention. For retirement investments, the stock market is advertised as high-risk/high-reward and is not suitable for lump-sum liquidation. I agree with you that too many Americans don't treat it this way, and this is a travesty. But please don't be bitter at the stock market for being the speculative arena that it always has been.
Whether you like it or not, the ISP is managing your packets, and when packet queuing happens something has to suffer (but a good ISP will specifically target latency-insensitive packets for this, such as known torrents, large HTTP transfers, FTP, etc). If you want GUARANTEED bandwidth to reduce bandwidth and packet loss, you need to be prepared to pay for it. Barring that, If you simply believe that your minecraft traffic is being dropped more than other traffic, I would suggest measuring the packet loss and raising a stink (whether formally via suit or via a visit to the local office is up to you... YMMV depending on the ISP). There's actually a decent chance that the excessive packet loss/delay isn't intentional, but if nobody complains they won't ever see the "bug".
FTFY. I guess the silver lining is "everyone else gets a jolly good laugh."
If you don't want to compete with an automated system, you can restrict your stock trading activity to the opening and closing auctions. Everyone gets the same price!
FTFY
Well I bet it's certainly shrunk a lot in the last few years, given that the US stock market is governed as a National Market System. In other words, that behavior (presumably arbitrage between exchanges and giving brokerage customers the worse price) is illegal.
All of which adjust the price of the stock appropriately, so the net capital is the same. 20% dividend issued on a $50 stock? It opens at $40 the next day, with $10/share added to the accounts of the shareholders. The $50/share of wealth still exists. Stock splits? Now twice the number of shares exist at half the price, same wealth.
That friction (which some call "skimming", depending on how much vitriol they want to inject into the conversation) is what pays for the services of exchanges, regulators, and market makers. The wealth still exists, it just stops becoming "shares" and turns back into "money". Glorious, Swimmable, Scrooge McDuck money.
Providing liquidity is useful because it reduces bid/ask spreads and lowers volatility. However, as at least one other poster mentioned, most HFTs—most traders, really—are not required to provide liquidity. That role is reserved for a handful of entrenched registered/lead/designated market makers (most of which are probably HFTs by now, simply out of necessity).
To continue the analogy, you only "pay" for liquidity when you trade. A long-term investor should only be interacting with the market once a month, or once a quarter. You're not funding HFTs or market makers unless you trade on a regular basis. In short, I agree with you: you shouldn't pay for liquidity that you don't use. You don't.
Maybe for single-player games, but not for competitive twitch-games online. Most modern LCDs come with gobs of post-processing that puts display latency up to the 100-200ms range (of course, you turn this off if you care). I find it extreme enough to absolutely destroy my shotgun accuracy in a local split-screen game. I expect remote rendering would have a similar effect, only worse because the Internet is less deterministic than a TV's post-processing pipeline.
GTA players may be willing to put up with high latency, but that doesn't fly so well with button-combo-fighting games (Soul Calibur, Street Fighter both 67ms) or competitive FPS games (CoD:MW 67-84ms). Those games just will not work with the additional latency of remote rendering over the Internet. 50ms light speed one way becomes 100ms round trip minimum, and it dramatically increases the probability of packet loss (mo' bandwidth, mo' problems).
Allowing the user to specify "empty" vs. "nonexistent" is almost always the wrong answer. In general, data for human contact is either provided or nonexistent, not empty. This can be name components, address components, phone numbers, etc.
It's hard to set a generalized rule for handling of other inputs, but typically the data model will dictate whether a given "string" datum is optional (NULLable), or whether it has content requirements (empty allowed). Very little data is both optional and allowed to be empty. So keep your interface clean, and do the mapping behind the scenes for data cleanliness.
Agreed on short videos, but many HD videos on YouTube are long. The ones I watch are daily publications lasting between 10-45 minutes. I know that on my connection I can always watch 480p, never watch 1080p, and off-peak usually watch 720p in order to avoid buffering mid-program.
By "ham-fist" I mean reducing the buffers proportional to the increase in bandwidth. Such an action may sound reasonable to a bean-counter; but it doesn't reduce the probability of a stall, merely the impact. Such a reduction also increases the sensitivity to other transient events that don't improve with the network (e.g. wireless interference due to a microwave oven).
Higher bandwidth means a reduction in the number of stalls for transient problems or high utilization. I won't see my HD youtube videos spend as much time paused and buffering, because the probability of insufficient buffered data goes down (unless you ham-fist the buffering algorithm).
Several things could come into play here to cause FF to have poorer bandwidth than wget.
You may actually get a perfect storm where FF's buffers fill up due to poor scheduler performance, causing the OS to drop packets, causing the sender to slam on the brakes until FF catches up. Lather, rinse, repeat. Of course, all of this is perfectly testable with tcpdump, so unless the GP is willing to cough up a packet capture I would consider his statement hearsay.
I really like this book because Lakos breaks down intermodule relationships very well, something that doesn't get enough (or any) discussion from other popular references. However, it's very clear that he grew up in an age with shitty C++ compilers. IIRC he had some weird recommendations like avoiding namespaces and duplicating header guards outside of #include directives.
Vim is an IDE, ergo vim is horrible.
If "being uninitialized" is a well-defined state for the object, then I agree. For example, you can have an empty container, an empty string, or a disconnected TCP "connection" (fd==-1 is a natural state, and instead of init() you have connect() or bind()). OTOH, I frequently discourage my co-workers from reusing value-objects. It's just as easy to say homeAddress=StreetAddress(street,unit,city,state,zip) as it is to say homeAddress.init(street,unit,city,state,zip). I have seen the latter pattern contribute to bugs when somebody added a member variable and didn't think to add it to the init() method, whereas nobody seems to accidentally omit it from the constructor.
I've looked at this myself. It is very nice that in C++ the "default" way of approaching error handling with RAII plays nicely with the compiler's static branch prediction logic. However, it's not a sufficient argument for truly high-performance code. Either your compiler provides conventions on static branch prediction or it provides intrinsics such as __builtin_expect that give you control. Both of these will give you the same benefits as the C++ RAII style, and (in my experience) neither approach gums up the logic enough to hurt readability.
Please humor my pedantry, but perhaps this is a bad example. A TCP connection is a stream, so any other stream based on a TCP connection is not at the appropriate abstraction level to catch anything. If it's an HTTP connection (with an in-flight GET request that may have been lost), let that layer handle restarting the stream and re-issuing the request. If it's a lossey stream of video data, let that layer restart the stream, wait for the next keyframe to show up in the input, and resume sending new data. I regularly see people writing "adapter" layers such as a TCP iostream wrapper and trying to handle exceptions when it is wholly inappropriate to do so—they should simply guarantee some level of exception safety and then get out.
IMHO, what you really want to do is replace the exception handler with a RAII "guard" object that will perform cleanup in its destructor if .commit() has not been called. This gives you all of the benefits of a try/catch block without forcing the try/catch on your parents. Keep in mind that if an exception is thrown with no outer try block, the program may omit stack unwinding and abort with a nice healthy core dump. If a single "middleware" layer inserted a try/catch block with a re-throw, then your stack trace shows up in the middleware's (usually useless) function and the source of the std::out_of_range remains a mystery. (note: this is probably undefined behavior, but it is damn nice and worth leveraging.)
The ATT/Tmobile merger just screams "too big to fail" to me. I would consider it thuggery to allow such a merger given the history of the Bells; Sprint/Nextel OTOH were comparatively small potatoes.
I'm sorry, I have a cold.
Dear Sir,
I noticed that the bottle in your cabinet was over a decade old (!), so I took the liberty of discarding it in the refuse and replacing it with a fresh bottle. I didn't want you to get food poisoning. I trust you will appreciate this attentiveness.
Rgrds,
smellotron
I don't think that's high. I agree, it doesn't make sense to write off a restaurant for a single bad experience after repeated good experiences. "Vote with your dollar" is the usual mantra, but for a small/local restaurant "Talk to the manager" is probably more effective.
Perhaps the GP was already on the fence about the establishment, with the raw GroupOn deal only being the "last straw".
The limiting factor may be space. If the 1x1TB drive fits into a 1U enclosure but the 2x600GB drive requires a 2U enclosure, it may not be worth doubling your datacenter rack space for the storage.
The limiting factor may be reliability. Mechanical drives fail frequently on startup/shutdown due to temperature changes. Putting two mechanical drives in a host (instead of one solid-state) sounds like a good way to increase failure rates, with all other things being equal. Even comparing two RAID0 arrays, SSD should be more reliable. YMMV with current offerings on the market.