The articles from legitimate press are limited. I'm sad to say that I've personally seen a divorce case where a mother, badly counseled by her unqualified, untrained, and unlicensed therapist, accused the father of sexual abuse of their children. The mother was claiming that practices common around the world, such as casual nudity in the home, or bathing with infants, were sexual abuse in and of themselves. That took years of horrific court intervention and a change of therapist to help clear up, and it still ruined their family.
This does not mean that all such allegations, or even a high proportion of them, are false. It most _certainly_ does not mean this man is innocent. It does mean that some skepticism of criminal allegations is badly needed. It would be horrific if the accusations were ill-founded.
> Try to come up with a proposal for a better approach. Do you want to allow secret trials?
This already exists for children: proceedings are sealed from the press, and after they become adults many records are supposed to be expunged. There are many cases where plaintiffs, defendants, and prosecutors are forbidden to publish anything about it. Jurors are also normally forbidden from speaking to the press. There is also the entire Guantanamo Bay legal fiasco, where secret prisoners are kept without habeas corpus, without trial, tortured, and in some cases beaten to death.
“Electronic front running,” which involves a HFT firm racing ahead of a large client order on an exchange, scooping up all the shares on offer at various other exchanges (if it is a buy order) or hitting all the bids (if it is a sell order), and then turning around and selling them to (or buying them from) the client and pocketing the difference.
> ARBITRAGE IS GOOD FOR EVERYONE!
I'm afraid that you keep saying that as if it were true. It's not. Arbitrage has limited benefits, and for modern stock markets HFT inserts an entirely unnecessary and undesirable layer of arbitrage. The same transactions would be available directly to most traders a few seconds later, with profits and risks more directly accessible to them, without any high frequency trading whatsoever. given lightspeed delays, the delay before they can receive the same starting information is no approximate 100 msec, even on the other side of the world. Given analysis delays, the ability of other algorithmic orders to make their trades is no more than 1 second. But the HFT traders have already bought and sold and bought and sold the same stock a dozen times before the ordinary trader can respond, shaving most of the available profit right out of the transaction.
Unnecessary middle men are a bane of many markets. The HFT systems insert themselves not as a single middle man, but as many middle men transactions shaving off profits in numerous thin slices as a stock price shifts rather than in the manageable segments available to ordinary traders without their size and their tools.
> NO THEY DO NOT! I stopped reading here, because HFTs DO NOT FRONT RUN!
I'm afraid they do. Predicting how their own early trading will boost or lower a stock price is built into HFT, and it's a major source of their profits. it's critical to managing their arbitrage, to predict precisely when to reverse their tactics an individual stock or the whole market rebounds from their leading trades. If they didn't factor in the results of their own trade, _and deliberately game the system_, it would cause even larger oscillations.
> Is more proof that you are ignorant on this matter. It's not insider trading. That again is where you have privileged information.
In this case, the "privileged information" is the microseconds or milliseconds of advance knowledge. Others can't afford the technological advantage, or in fact are blocked by exclusive contract from tapping the fiber optic closer to the stock exchanges. It's currently legal, but it's definitely privileged. The idea that "it's not harmful" is, I'm afraid to say, based in self serving fraud.
> it was always because they were the BEST available option for the trader who was opposing them.
This is blatant nonsense. In an HFT brokered transaction, the HFT trader has intercepted the "best trade" before the other dealers, businesses, or stock owner could possibly have been aware of that "BEST" available option. Also, I'm afraid that the concept that all trades are the "BEST" option is impossible. If they each chose the "BEST" option, they would each know the complete results of the transaction to have perfect knowledge of the results of the trade. They do not, and they cannot: information is limited, and the stock market is a chaotic system. They may be able to make well informed guesses, but there is no more way to predict it perfectly than there are means to perfectly predict the weather.
Sadly, the HFT companies are effectively reading the weather reports before anyone else can see the report and gambling with that information before anyone else gets the data. It's unfair competition.
The "better deal" was intercepted by the HFT, who insert themselves as middle men between the original stock owner or traders and the possible clients before either of them can possibly be aware of the market changes. They also prevent possible competitors by ordering or selling stock at such scale that ordinary traders have no shares available with which to offer competitive deals. That's not "the best deal". That is monopoly power, and it's anti-competitive at its core.
I'm afraid you've also not accounted for HFT order cancellation. They make orders that have risks. Then they cancel all but the profitable orders, at little to no risk to themselves. These canceled orders _themselves_ manipulate the stock prices in their desired directions for profitability. It encourages "spoofing", where large volumes of orders create illusory market demands. The HFT systems are _designed_ to encourage changes in the market, calculate the results of the positive feedback of their large scale transactions, and reverse their ordering just as the market rebounds. They're tapping the profits when fluctuations occur either way, which is how traders work. But they're doing it on a massive scale and _generating their own exaggerated market fluctuations_ by the scale of their orders.
The result is destructive. It's anti-competitive because the presumption of equal prices for all customers is broken: the HFT's have a price preview unavailable to other potential stock traders or stockholders due to signal transmission delays, limited by the speed of light between the stock exchanges and other potential dealers and their clients, and limited by the transaction speed of the computers tied to those signals.
> So, the best thing we can do, actually, is let the BEST traders take the most money, because they provide the most "information"
Except that the HFT traders do not "provide information". They tap the information before others can receive it. This is normally called "insider trading", and that is illegal for very good reasons.
Ordinary traders do not require microsecond response times. The microsecond response times are in fact quite dangerous because the HFT's create positive feedback: as a price changes, their orders push that change further, faster, than anyone else can respond, and they can drive the market straight into a crash. They've already done so. The 2010 "flash crash" is an infamous example of HFT run wild and destroying billions of dollars of market value. Similar HFT problems though smaller scale, led to the "Peet's Coffee" incident in 2012.
> It's quite likely that even if convicted he would be released immediately due to "time served" being stuck in the embassy.
Conviction would be a legal problem, since it would create significant visa issues. The real risk for him once he's outside an embassy is extradition to a nation interested in prosecuting him for espionage. Even if no extradition proceedings are currently in progress, I'm certain they'd be filed within moments of his departure from the embassy.
> HFT is good actually for markets, and good for everyone, because, if you actually examine the operation of markets (as double opposing queues), you will see that it is NEVER possible to harm another trader by placing trades, because you only provide (at least) BETTER opportunities for other traders, or match other traders SOONER than they OTHERWISE would have been.
I'm afraid it's not "good for markets". The extensive arbitrage saps the profit from those who offer stock, or those who do longer term investment or cannot afford HFT systems, and leaves the stock profits in the hands of those committing arbitrage and providing no direct service to the economy or to the system itself. They do not provide "BETTER" opportunities, they've already tapped the profits out of the system before most other traders were even aware of pending market changes. Much like insider trading, it's information that is not available to the market at large, despite the extensive work by the stock markets to make the information available simultaneously to all traders.
The idea that they "provide information to the market" is a very strange one. Waiting a few hundred milliseconds for light speed delays to allow the signals to travel the globe and reach actual investors would provide very much the same information, without the HFT systems pre-sampling and effectively insider trading that information before it can reach less technologically invested traders. Speed of information transfer does not _increase_ the quality of the information.
> you will see that it is NEVER possible to harm another trader by placing trades,
I'm afraid this is nonsense. If you use what is effectively insider information to make a trade that profits you, based on information not available to other traders, that can be a form of theft. Trades can also be used to pump and dump, effectively lying to other traders about the value of investments to mislead them and crash the stock value to one's own profit. Less commonly described, trades can be used for the _opposite_ of pump and dump. where a spate of short orders can trigger other investors to sell off stock immediately, one buys up the stock at its predicted lowest price, and sells it off during the recovery.
This is coupled with the dangerous feedback loops of multiple HFT companies operating at speeds so fast that they cannot possibly track the simultaneous negative feedback of other HFT systems. Large scale negative feedback loops, out of phase, almost inevitably lead to destructive positive feedback loops unless they are damped. Damping them would eliminate the _purpose_ of HFT, and the result is quite dangerous. This played out destructively in the "flash crash" of 2010.
Goodness, my typing was horrible in my response. It detracted. The core of the message should stand, but I do need some sleep. If the danger of relying on rsync to consistently copy non-symlinked source content to local symlinked content, and expecting the changes to propagate reliably to the symlink target, is unclear, I'll revisit the issue.
Symlinks to place content on another fileystem is useful. It needs to be handled with caution.
"--inplace" breaks symlinks and hardlinks. I just tested it under CygWin and under a current Linux. "--copy-dest" simply replicates unchanged files. That is not part of the "copying content from elsewhere on toop of symlinks and making sure the conent is copied to the target of the symlink that I was trying to explain. "--backup" doesn't help the issue. The backup exists and you can derive the old symlink to script around the issue. You can also do a "--dry-run" and parse that to deduce what needs to be synced locally and what needs to be copied elsewhere to copy correctly to the symlink target. "--link-dest" is entirely useless for the original suggested purpose of "On an operating system with working symlinks, you can install part of a game on ssd, and part on HDD. "
I'mn afraid that ensuring that a local symlink in the target directory gets replication copied to the target of the symlink cannot be done well by a simple symlink rsync command. It requires separate tuning, _outside_ the programming of the rsync command line options.
Also, at least according to the current "ln" manual page, you *can* hardlink directories with the "-d" option, depending on the filesystem. I admit that it seems to be disabled on the first Linux ext4 filesystems I tried it on, and under CygWin accessible NTFS. But it used to be a much more commonly supported option. I'm not clear whether it's been entirely discarded.
The idea that an employee transfers to a new environment where their hard-won expertise is able to be better used is a popular one, and I've certainly seen it in play. I've also encouraged it for people I worked with, or who worked for me, to produce better products for the _vendors_ and creators of software I worked with.
However, that does not eliminate the prevalence of wholesale theft of software, of trade secrets, and even of hardware patents as part of employee hiring. Microsoft was caught doing it with David Cutler and his team from DEC. Intellectual property theft is, unfortunately, common place.
> I was addressing mechanisms to deliberately slow down HFT trading and the like.
This is not difficult. Force the "high speed traders" to actually make the purchases, or sales, and pay transaction fees. As it stands they actually _discard_ most of their orders and pay no transaction fees, nor do the stocks ever actually transfer to their cofferes. They're engaging in pure arbitrage, at very little sirk. The largest risk is that they won't profit enough to pay for the infrastructure required for HFT.
The HFT system does not "provide information to the market", It intercepts information before other traders can csee it. I'm afraid that the idea that it "promotes liquidity" is a self-serving fraud by the traders that can afford HFT systems.
> Slowing down the market like you suggest is another unnecessary and actually harmful solution to a system that is specifically designed and intended to provide instantly up to date prices that reflect all known information about a stock, in the limit (the efficient market hypothesis).
They would realize that gambling for fun, and fraud, are critical parts of the complete system. I'm afraid that the "efficient market hypothesis" is as valid in economic models as a "frictionless surface" is in physics. It allows some useful model creation, but it's not a complete model. It especially founders on phase delay: different information channels about prices have different transmission delays to different locations. It also founders very badly in terms of "chaos theory", where small, even unmeasurable changes in state cause systemwide and difficult to predict changes in the whole system.
There are things that high speed trading does well. It relies on what is effectively insider trading, the milliseconds advantage of having their FPGA circuitry on the fiber optics leaving the stock exchanges, to commit arbitrage before the rest of the stock market can see the information. The high speed response of such systems might, in theory, be tunable to detect cyber attacks and lock out suspicious traffic at the beginning of external cyber attacks and especially to block various denial-of-service attacks. But from what I've seen of high frequency trading, there is profound deceit at every level of it: I'd be very concerned about trusting the work from any company involved in it.
> Microsoft and google would both show you the door the second you handed them code belonging to another organisation
If the intellectual property is worth enough, the door they show you is a door to the senior management offices and, apparently, your own parking space. Microsoft in particular hired David Cutler to design their next operating system, and he brought core software and his old team from DEC to write NT.
Intellectual property theft is a way of life for many powerful companies. I'm afraid that Microsoft has, historically, been one of those. It's not all companies. Many of us strive to avoid such theft, partly because it damages the people who actually create technology. But it's startlingly commonplace among the small startup companies, many of whom had never had an original idea in their entire technology stack.
I'm afraid that rsync normally deletes the local file and replaces it with the new file, doing the replacment either bore the complete delivery (for certain options) or after completed delivery to a temp file. That breaks the hard link. Rsycing hardlinks is quite tricky if the hardlink exists on the _target_ filesystem, and not on the source filesystem, and does not happen if the hardlink leads outside the target rsync directory. "bind mounts" do not work for individual files in Linux filesystems, only for directories. So keeping individual symlinked files that may point elsewhere, to other attached filesystems, can be quite awkward.
I'm afraid that this kind of confusion is a common one. Developers and less experienced systems personnel believe that their casual familiarity with a tool applies to edge cases. It's when they have to actually do the work and deal with edge cases that they learn, sometimes quite painfully, that their original simple model can prove very complex to maintain, even proving incompatible with their other working tools.
I do apologize if I seem condescending about this: My experience with rsync and its limitations is hard-won, and its subtleties can be confusing.
Many, though not all, workplaces will work with you when you sign their employment contract to exclude company ownership of previous free software and open source software. Many, though not all, will also work with you to allow you to publish patches to the upstream owners of copyrighted free software, to avoid GPL confusion and to get the patches into the next official release. If your current workplace isn't clear about permitting such work, spend an hour with an attorney familiar with intellectual property law and do some personal, public work on something unrelated to your workplace.
This isn't always easy to do if you are a generalist in a consulting company: you can easily be called in for help because your work elsewhere is noticed. I've had good success protecting the intellectual property personally and with people working with or for me who had technical expertise outside our company's direct work.
You've a very good point that "rsync" provides options to handle symlinks differently. But those options are aimed at the correct replication of a symlink on the source side. The transfer of content on top of an existing symlink normally breaks the symlink on the receiving side, unless it is a matching symlink.
If you've seen a way to get it to consistently transfer plain file content from the resource side, on top of an existing symlink, leave the symlink untouched and publish the content to the target of the symlink, I'd be curious to see the combination of options you're using.
Also, one has to be _very_ careful how new data is incorporated to avoid breaking symlinks. Tools like "cp" or "tar" in the Linux and UNIX world will normally copy content on top of symlinks, and write changes to the target of the symlink. "rsync" will not, nor will any operation that copies a temporary file in place and moves it to replace the previously symlinked file.
I've had extensive difficulty with people using symlinks carelessly to move bulky content elsewhere, then wondering why they discovered difficulty when they copied over new content and broke the symlink.
That is because most of laptop drives today are "hard drive". They're flash. Flash is much better for laptops, partly because of the lack of mechanical components, and partly because it retains state so much better without using batter power in sleep mode. It's also generally much faster to search and retrieve data randomly stored or ordered data, without spending extensive time "optimizing" the filesystem. But it is much, much more expensive per GB of storage space.
I worked extensively with both MacOS and NeXT at an earlier point of my career, integrating various tools into several multi-platform environments for groups that hadn't been able to standardize on operating systems or base hardwrae. There are some philosophical and design structure similarities, but the amount of core kernel and OS underpinnings that came from NeXT seemed much smaller than that which came from FreeBSD.
Oh. Oh, my. I'm sorry to say that that there is almost no paying work involving any of the BSD's, except for MacOS as a descendant of FreeBSD. Even the most casual search of job sites, whether hiring or looking for work, lists Linux over any or all of the BSD's by a ratio of hundreds to one.
The idea that they are a "go-to" operating system ignores that actual job listings involving the non-MacOS BSD's are almost entirely migration projects, to migrate from the BSD selected by a former technology architect, to a supportable and hardware compatible operating system. The individual BSD's can, and many do, have significant feature benefits over Linux. The lack of systemd is one of them, I can agree. But the featues you list have proven insufficient to gain market share compared to the ease of development, the ease of installation, and the broad usage of Linux.
There's a quite vocal contingent of the LGBTQ community that are insistent on the use of their preferred gender pronouns, and seek government restriction through the use of Title 9 funding, and who even demand civil prosecution for failing to use their desired pronouns. I recently attended a mandatory presentation with a business partner about just such gender identification issues. If we did not attend the seminar and sign agreement with the policies, we would not be permitted to work with that company.
I believe you failed to mention the theft of intellectual property when Microsoft hired David Cutler and his VMS team to write critical parts of Windows NT. That theft was part of the downfall of DEC. It was coupled with the wholesale theft of their hardware designs to create the Pentium chip.
>> This occurs for _any_ nation that invades Afghanistan.
> Ironically the Taliban are the only ones to ever stop opium production there.
May I disagree? I suggest that "not being at war" was the factor that curtailed opium production. I suggest that it wasn't merely that the Taliban were in charge, it was that food crops could be grown, harvested, and distributed legally, possibly even at a profit. For people in a war zone, short-term profit with smaller investment and more easily portable goods becomes critical.
I agree with you that managed legalization is a good step. But it does not seem to be an "approach that would eradicate the drug epidemic". It's not "eradicated" the problem for alcohol or tobacco, it's merely helped contain it.
Slashdot Mirror
The articles from legitimate press are limited. I'm sad to say that I've personally seen a divorce case where a mother, badly counseled by her unqualified, untrained, and unlicensed therapist, accused the father of sexual abuse of their children. The mother was claiming that practices common around the world, such as casual nudity in the home, or bathing with infants, were sexual abuse in and of themselves. That took years of horrific court intervention and a change of therapist to help clear up, and it still ruined their family.
This does not mean that all such allegations, or even a high proportion of them, are false. It most _certainly_ does not mean this man is innocent. It does mean that some skepticism of criminal allegations is badly needed. It would be horrific if the accusations were ill-founded.
> Try to come up with a proposal for a better approach. Do you want to allow secret trials?
This already exists for children: proceedings are sealed from the press, and after they become adults many records are supposed to be expunged. There are many cases where plaintiffs, defendants, and prosecutors are forbidden to publish anything about it. Jurors are also normally forbidden from speaking to the press. There is also the entire Guantanamo Bay legal fiasco, where secret prisoners are kept without habeas corpus, without trial, tortured, and in some cases beaten to death.
> Front running is placing an order BEFORE the other order hits the queue because you know the order ahead of time.
And many, if not all HFT practicioners, do exactly this. See:
http://www.investopedia.com/ar...
Quoting the article:
“Electronic front running,” which involves a HFT firm racing ahead of a large client order on an exchange, scooping up all the shares on offer at various other exchanges (if it is a buy order) or hitting all the bids (if it is a sell order), and then turning around and selling them to (or buying them from) the client and pocketing the difference.
> ARBITRAGE IS GOOD FOR EVERYONE!
I'm afraid that you keep saying that as if it were true. It's not. Arbitrage has limited benefits, and for modern stock markets HFT inserts an entirely unnecessary and undesirable layer of arbitrage. The same transactions would be available directly to most traders a few seconds later, with profits and risks more directly accessible to them, without any high frequency trading whatsoever. given lightspeed delays, the delay before they can receive the same starting information is no approximate 100 msec, even on the other side of the world. Given analysis delays, the ability of other algorithmic orders to make their trades is no more than 1 second. But the HFT traders have already bought and sold and bought and sold the same stock a dozen times before the ordinary trader can respond, shaving most of the available profit right out of the transaction.
Unnecessary middle men are a bane of many markets. The HFT systems insert themselves not as a single middle man, but as many middle men transactions shaving off profits in numerous thin slices as a stock price shifts rather than in the manageable segments available to ordinary traders without their size and their tools.
> NO THEY DO NOT! I stopped reading here, because HFTs DO NOT FRONT RUN!
I'm afraid they do. Predicting how their own early trading will boost or lower a stock price is built into HFT, and it's a major source of their profits. it's critical to managing their arbitrage, to predict precisely when to reverse their tactics an individual stock or the whole market rebounds from their leading trades. If they didn't factor in the results of their own trade, _and deliberately game the system_, it would cause even larger oscillations.
> Is more proof that you are ignorant on this matter. It's not insider trading. That again is where you have privileged information.
In this case, the "privileged information" is the microseconds or milliseconds of advance knowledge. Others can't afford the technological advantage, or in fact are blocked by exclusive contract from tapping the fiber optic closer to the stock exchanges. It's currently legal, but it's definitely privileged. The idea that "it's not harmful" is, I'm afraid to say, based in self serving fraud.
> it was always because they were the BEST available option for the trader who was opposing them.
This is blatant nonsense. In an HFT brokered transaction, the HFT trader has intercepted the "best trade" before the other dealers, businesses, or stock owner could possibly have been aware of that "BEST" available option. Also, I'm afraid that the concept that all trades are the "BEST" option is impossible. If they each chose the "BEST" option, they would each know the complete results of the transaction to have perfect knowledge of the results of the trade. They do not, and they cannot: information is limited, and the stock market is a chaotic system. They may be able to make well informed guesses, but there is no more way to predict it perfectly than there are means to perfectly predict the weather.
Sadly, the HFT companies are effectively reading the weather reports before anyone else can see the report and gambling with that information before anyone else gets the data. It's unfair competition.
The "better deal" was intercepted by the HFT, who insert themselves as middle men between the original stock owner or traders and the possible clients before either of them can possibly be aware of the market changes. They also prevent possible competitors by ordering or selling stock at such scale that ordinary traders have no shares available with which to offer competitive deals. That's not "the best deal". That is monopoly power, and it's anti-competitive at its core.
I'm afraid you've also not accounted for HFT order cancellation. They make orders that have risks. Then they cancel all but the profitable orders, at little to no risk to themselves. These canceled orders _themselves_ manipulate the stock prices in their desired directions for profitability. It encourages "spoofing", where large volumes of orders create illusory market demands. The HFT systems are _designed_ to encourage changes in the market, calculate the results of the positive feedback of their large scale transactions, and reverse their ordering just as the market rebounds. They're tapping the profits when fluctuations occur either way, which is how traders work. But they're doing it on a massive scale and _generating their own exaggerated market fluctuations_ by the scale of their orders.
The result is destructive. It's anti-competitive because the presumption of equal prices for all customers is broken: the HFT's have a price preview unavailable to other potential stock traders or stockholders due to signal transmission delays, limited by the speed of light between the stock exchanges and other potential dealers and their clients, and limited by the transaction speed of the computers tied to those signals.
> So, the best thing we can do, actually, is let the BEST traders take the most money, because they provide the most "information"
Except that the HFT traders do not "provide information". They tap the information before others can receive it. This is normally called "insider trading", and that is illegal for very good reasons.
Ordinary traders do not require microsecond response times. The microsecond response times are in fact quite dangerous because the HFT's create positive feedback: as a price changes, their orders push that change further, faster, than anyone else can respond, and they can drive the market straight into a crash. They've already done so. The 2010 "flash crash" is an infamous example of HFT run wild and destroying billions of dollars of market value. Similar HFT problems though smaller scale, led to the "Peet's Coffee" incident in 2012.
> It's quite likely that even if convicted he would be released immediately due to "time served" being stuck in the embassy.
Conviction would be a legal problem, since it would create significant visa issues. The real risk for him once he's outside an embassy is extradition to a nation interested in prosecuting him for espionage. Even if no extradition proceedings are currently in progress, I'm certain they'd be filed within moments of his departure from the embassy.
> HFT is good actually for markets, and good for everyone, because, if you actually examine the operation of markets (as double opposing queues), you will see that it is NEVER possible to harm another trader by placing trades, because you only provide (at least) BETTER opportunities for other traders, or match other traders SOONER than they OTHERWISE would have been.
I'm afraid it's not "good for markets". The extensive arbitrage saps the profit from those who offer stock, or those who do longer term investment or cannot afford HFT systems, and leaves the stock profits in the hands of those committing arbitrage and providing no direct service to the economy or to the system itself. They do not provide "BETTER" opportunities, they've already tapped the profits out of the system before most other traders were even aware of pending market changes. Much like insider trading, it's information that is not available to the market at large, despite the extensive work by the stock markets to make the information available simultaneously to all traders.
The idea that they "provide information to the market" is a very strange one. Waiting a few hundred milliseconds for light speed delays to allow the signals to travel the globe and reach actual investors would provide very much the same information, without the HFT systems pre-sampling and effectively insider trading that information before it can reach less technologically invested traders. Speed of information transfer does not _increase_ the quality of the information.
> you will see that it is NEVER possible to harm another trader by placing trades,
I'm afraid this is nonsense. If you use what is effectively insider information to make a trade that profits you, based on information not available to other traders, that can be a form of theft. Trades can also be used to pump and dump, effectively lying to other traders about the value of investments to mislead them and crash the stock value to one's own profit. Less commonly described, trades can be used for the _opposite_ of pump and dump. where a spate of short orders can trigger other investors to sell off stock immediately, one buys up the stock at its predicted lowest price, and sells it off during the recovery.
This is coupled with the dangerous feedback loops of multiple HFT companies operating at speeds so fast that they cannot possibly track the simultaneous negative feedback of other HFT systems. Large scale negative feedback loops, out of phase, almost inevitably lead to destructive positive feedback loops unless they are damped. Damping them would eliminate the _purpose_ of HFT, and the result is quite dangerous. This played out destructively in the "flash crash" of 2010.
Goodness, my typing was horrible in my response. It detracted. The core of the message should stand, but I do need some sleep. If the danger of relying on rsync to consistently copy non-symlinked source content to local symlinked content, and expecting the changes to propagate reliably to the symlink target, is unclear, I'll revisit the issue.
Symlinks to place content on another fileystem is useful. It needs to be handled with caution.
"--inplace" breaks symlinks and hardlinks. I just tested it under CygWin and under a current Linux.
"--copy-dest" simply replicates unchanged files. That is not part of the "copying content from elsewhere on toop of symlinks and making sure the conent is copied to the target of the symlink that I was trying to explain.
"--backup" doesn't help the issue. The backup exists and you can derive the old symlink to script around the issue. You can also do a "--dry-run" and parse that to deduce what needs to be synced locally and what needs to be copied elsewhere to copy correctly to the symlink target.
"--link-dest" is entirely useless for the original suggested purpose of "On an operating system with working symlinks, you can install part of a game on ssd, and part on HDD. "
I'mn afraid that ensuring that a local symlink in the target directory gets replication copied to the target of the symlink cannot be done well by a simple symlink rsync command. It requires separate tuning, _outside_ the programming of the rsync command line options.
Also, at least according to the current "ln" manual page, you *can* hardlink directories with the "-d" option, depending on the filesystem. I admit that it seems to be disabled on the first Linux ext4 filesystems I tried it on, and under CygWin accessible NTFS. But it used to be a much more commonly supported option. I'm not clear whether it's been entirely discarded.
The idea that an employee transfers to a new environment where their hard-won expertise is able to be better used is a popular one, and I've certainly seen it in play. I've also encouraged it for people I worked with, or who worked for me, to produce better products for the _vendors_ and creators of software I worked with.
However, that does not eliminate the prevalence of wholesale theft of software, of trade secrets, and even of hardware patents as part of employee hiring. Microsoft was caught doing it with David Cutler and his team from DEC. Intellectual property theft is, unfortunately, common place.
> I was addressing mechanisms to deliberately slow down HFT trading and the like.
This is not difficult. Force the "high speed traders" to actually make the purchases, or sales, and pay transaction fees. As it stands they actually _discard_ most of their orders and pay no transaction fees, nor do the stocks ever actually transfer to their cofferes. They're engaging in pure arbitrage, at very little sirk. The largest risk is that they won't profit enough to pay for the infrastructure required for HFT.
The HFT system does not "provide information to the market", It intercepts information before other traders can csee it. I'm afraid that the idea that it "promotes liquidity" is a self-serving fraud by the traders that can afford HFT systems.
> Slowing down the market like you suggest is another unnecessary and actually harmful solution to a system that is specifically designed and intended to provide instantly up to date prices that reflect all known information about a stock, in the limit (the efficient market hypothesis).
They would realize that gambling for fun, and fraud, are critical parts of the complete system. I'm afraid that the "efficient market hypothesis" is as valid in economic models as a "frictionless surface" is in physics. It allows some useful model creation, but it's not a complete model. It especially founders on phase delay: different information channels about prices have different transmission delays to different locations. It also founders very badly in terms of "chaos theory", where small, even unmeasurable changes in state cause systemwide and difficult to predict changes in the whole system.
There are things that high speed trading does well. It relies on what is effectively insider trading, the milliseconds advantage of having their FPGA circuitry on the fiber optics leaving the stock exchanges, to commit arbitrage before the rest of the stock market can see the information. The high speed response of such systems might, in theory, be tunable to detect cyber attacks and lock out suspicious traffic at the beginning of external cyber attacks and especially to block various denial-of-service attacks. But from what I've seen of high frequency trading, there is profound deceit at every level of it: I'd be very concerned about trusting the work from any company involved in it.
>> If I could catch out a competitors fraud or criminal practices I would report it to the authorities
The authorities, in general, do not care. It usually takes a civil suit to punish a copyright violator.
> Viewing competition as an "enemy" is simply sociopathic,
Many successful business practices are, including monopoly abuse, insider trading, and pyramid schemes. This does not make rare.
> Microsoft and google would both show you the door the second you handed them code belonging to another organisation
If the intellectual property is worth enough, the door they show you is a door to the senior management offices and, apparently, your own parking space. Microsoft in particular hired David Cutler to design their next operating system, and he brought core software and his old team from DEC to write NT.
Intellectual property theft is a way of life for many powerful companies. I'm afraid that Microsoft has, historically, been one of those. It's not all companies. Many of us strive to avoid such theft, partly because it damages the people who actually create technology. But it's startlingly commonplace among the small startup companies, many of whom had never had an original idea in their entire technology stack.
I'm afraid that rsync normally deletes the local file and replaces it with the new file, doing the replacment either bore the complete delivery (for certain options) or after completed delivery to a temp file. That breaks the hard link. Rsycing hardlinks is quite tricky if the hardlink exists on the _target_ filesystem, and not on the source filesystem, and does not happen if the hardlink leads outside the target rsync directory. "bind mounts" do not work for individual files in Linux filesystems, only for directories. So keeping individual symlinked files that may point elsewhere, to other attached filesystems, can be quite awkward.
I'm afraid that this kind of confusion is a common one. Developers and less experienced systems personnel believe that their casual familiarity with a tool applies to edge cases. It's when they have to actually do the work and deal with edge cases that they learn, sometimes quite painfully, that their original simple model can prove very complex to maintain, even proving incompatible with their other working tools.
I do apologize if I seem condescending about this: My experience with rsync and its limitations is hard-won, and its subtleties can be confusing.
Many, though not all, workplaces will work with you when you sign their employment contract to exclude company ownership of previous free software and open source software. Many, though not all, will also work with you to allow you to publish patches to the upstream owners of copyrighted free software, to avoid GPL confusion and to get the patches into the next official release. If your current workplace isn't clear about permitting such work, spend an hour with an attorney familiar with intellectual property law and do some personal, public work on something unrelated to your workplace.
This isn't always easy to do if you are a generalist in a consulting company: you can easily be called in for help because your work elsewhere is noticed. I've had good success protecting the intellectual property personally and with people working with or for me who had technical expertise outside our company's direct work.
You've a very good point that "rsync" provides options to handle symlinks differently. But those options are aimed at the correct replication of a symlink on the source side. The transfer of content on top of an existing symlink normally breaks the symlink on the receiving side, unless it is a matching symlink.
If you've seen a way to get it to consistently transfer plain file content from the resource side, on top of an existing symlink, leave the symlink untouched and publish the content to the target of the symlink, I'd be curious to see the combination of options you're using.
Also, one has to be _very_ careful how new data is incorporated to avoid breaking symlinks. Tools like "cp" or "tar" in the Linux and UNIX world will normally copy content on top of symlinks, and write changes to the target of the symlink. "rsync" will not, nor will any operation that copies a temporary file in place and moves it to replace the previously symlinked file.
I've had extensive difficulty with people using symlinks carelessly to move bulky content elsewhere, then wondering why they discovered difficulty when they copied over new content and broke the symlink.
That is because most of laptop drives today are "hard drive". They're flash. Flash is much better for laptops, partly because of the lack of mechanical components, and partly because it retains state so much better without using batter power in sleep mode. It's also generally much faster to search and retrieve data randomly stored or ordered data, without spending extensive time "optimizing" the filesystem. But it is much, much more expensive per GB of storage space.
> MacOS is by no means a descendant of FreeBSD. They grafted some stuff from FreeBSD onto NeXT Step.
According to Apple, much of the kernel is descended from FreeBSD.
* https://developer.apple.com/li...
I worked extensively with both MacOS and NeXT at an earlier point of my career, integrating various tools into several multi-platform environments for groups that hadn't been able to standardize on operating systems or base hardwrae. There are some philosophical and design structure similarities, but the amount of core kernel and OS underpinnings that came from NeXT seemed much smaller than that which came from FreeBSD.
The article this was quoted from, without credit, is at http://uncyclopedia.wikia.com/... . The last edit of that page was in 2013.
Oh. Oh, my. I'm sorry to say that that there is almost no paying work involving any of the BSD's, except for MacOS as a descendant of FreeBSD. Even the most casual search of job sites, whether hiring or looking for work, lists Linux over any or all of the BSD's by a ratio of hundreds to one.
The idea that they are a "go-to" operating system ignores that actual job listings involving the non-MacOS BSD's are almost entirely migration projects, to migrate from the BSD selected by a former technology architect, to a supportable and hardware compatible operating system. The individual BSD's can, and many do, have significant feature benefits over Linux. The lack of systemd is one of them, I can agree. But the featues you list have proven insufficient to gain market share compared to the ease of development, the ease of installation, and the broad usage of Linux.
There's a quite vocal contingent of the LGBTQ community that are insistent on the use of their preferred gender pronouns, and seek government restriction through the use of Title 9 funding, and who even demand civil prosecution for failing to use their desired pronouns. I recently attended a mandatory presentation with a business partner about just such gender identification issues. If we did not attend the seminar and sign agreement with the policies, we would not be permitted to work with that company.
I believe you failed to mention the theft of intellectual property when Microsoft hired David Cutler and his VMS team to write critical parts of Windows NT. That theft was part of the downfall of DEC. It was coupled with the wholesale theft of their hardware designs to create the Pentium chip.
>> This occurs for _any_ nation that invades Afghanistan.
> Ironically the Taliban are the only ones to ever stop opium production there.
May I disagree? I suggest that "not being at war" was the factor that curtailed opium production. I suggest that it wasn't merely that the Taliban were in charge, it was that food crops could be grown, harvested, and distributed legally, possibly even at a profit. For people in a war zone, short-term profit with smaller investment and more easily portable goods becomes critical.
I agree with you that managed legalization is a good step. But it does not seem to be an "approach that would eradicate the drug epidemic". It's not "eradicated" the problem for alcohol or tobacco, it's merely helped contain it.