There's more than technical merit to every product. There's the price, the licensing, the support, the market, plus all these factors applied to dependencies (e.g. hardware your software is meant to run on.)
Bad management can snuff the most superior technological merit.
Let's imagine a mod for your_newest_game: giving it anisotropic antialiasing x4. In your game, you can enter "Options", click "Graphics", "Advanced", and drag the anisotropic filtering slider to "x4". Then click "Apply" and it's saved in a config file in the game directory. Meanwhile, the mod finds the configh file and changes the line that reads "GFX_Anisotropic_Filtering=0" to 4.
Would you agree that's rather silly, considering this is within skill of about every user?
Well, now remove the option from game menu. Pack the game files with an obscure compression program. It took some smart modder to figure out the compression program and be able to create an automated tool that applies modifications inside the archive - without need to repack the multi-gigabyte archive. He released the tool, and another one that allows you to browse the game files, as if they were unpacked.
Now someone else finds the config file, and uses the program to change "GFX_Anisotropic_Filtering=0" to 4 within the archive. Anyone with access to the tools can do this. The actual modification of the game is completely trivial. It's just that even most trivial tweak to the game must be packaged in the same, complex tool as a mod.
Actually - not so much "modders" as "tweakers". Back in the day, it was editing an.ini file, and what they do is nothing else. They don't add external shaders, they don't add or replace any content, they just enable content that is there, in game, disabled by settings. The only reason this is done through mods and not plain config file edit is that the config file is buried within proprietary archive of the game, and can be modified only through a mod.
There's a problem with this claim. Similarly to file-sharers, they don't *actually* cost the transport companies any money.
1. It assumes they would pay if not the scheme. It doesn't assume they would take alternate transport medium.
2. It assumes all the income is from the tickets. It disregards both tax-funded subsidies (from 'freeloaders' tax money) and the punitive charges income (no matter if paid by given freeloader alone or from 'insurance')
3. It assumes cost scales linearly with the number of passengers.
Let me expand on that. The cost of operating a line is mostly a fixed value - amortization of the bus, salary of the driver, costs of operating the infrastructure. Fuel is only a minor part, and even then, then, take bus weight of 10 tons, passenger weight of 100kg, assuming (falsely) the fuel use increases linearly with number of passengers, the difference in cost between driving an empty bus and one with 1 freeloader would be 1%.
In other words, each freeloader in the absolutely worst case scenario adds 1% to the cost of operating a line. In more realistic scenario, this number will be over an order of magnitude smaller.
As effect - yes, the freeloaders do increase the costs for others. Assuming 10 of them per ride - by about 1%.
And one thing more. If they can't break even on the punitive charges, that means the controls are too infrequent. If $15/month suffices to cover $180/capture, that means one control per 14 months. Seriously? Make the average 1/month (still very little with people riding daily) and the 'insurance' will need to rise to $180/month. With $150/monthly pass, the problem will vanish.
Snow is iresome, making the ride uncomfortable, slower, and more risky. Even small amounts of ice make the ride practically impossible. During a turn on a bike there's a significant lateral stress against the tire. On slipery surface you just fall, period. With snow or mud the tire squeezes a track, keeping some traction. On ice it just slips.
As one who works with these currently, I can confirm. The main CPU has its software written in such a way, that you can't force green on two conflicting directions. Simply, the traffic program won't allow them, not through some emergency modes but just not starting a conflicting green until the prior one is lit and sufficient time after it went off was elapsed. You could try to override it, say, redefining signal color definitions, "green is the new red", or even try to short-circuit the wires. But that is detected by the hardware and then the supervising CPU kicks in and simply trips the contactor disabling power to the signal lights. No 'emergency mode' which could still light up green in case of short circuit, no trying to make output modules not to output any signals in case a triac is fried, just general power off through a mechanical switch. (also, any output module that reports some kind of fault and doesn't get a reply within 300ms, it trips the same contact.)
What the attacker -could- do is change the traffic program - redefine assignments of signal groups, change the collision matrix - making both processor simply not see two groups as colliding. But to do so, they would need access to some highly specialized software for generating traffic programs, or painstakingly reverse-engineer the file already present in the controller, not a small feat.
While not pushed by quotas, they are tempted by personal incomes directly proportional to in-game sales. Ther is always the incentive to grab more money, whatever it is. And single-player games can be (and frequently are) made equally hopeless money sinks in pursuit of progress in game, as opposed to advantage over other players. When a game requires you to spend three years to accumulate enough valuables through "free means" to avoid that one $30 payment required to progress (actual example), and this after you've invested about a month of your time to arrive at that point, this is no longer "pay if you want to gain advantage", this is "pay or GTFO."
Once again, this is not about what game companies may do to make these games competetive and fun. This is about the ugly reality of what they actually do, with few very rare exceptions. So, no wonder if a player sees a game announced as F2P, automatically labels it a scam. Because usually it is a scam.
Fact versus Belief. Even though giving it away would not affect CostCo's income adversely, the management is likely to believe the opposite would be the case. Even worse if *some* managers deemed the prior statements a valid risk, one that gave a "go ahead" to distribution would get in trouble. "Better safe than sorry", even though the actual risk was non-existent, the very likehood of belief for it to be real made it serious enough.
Formal proof of design correctness doesn't preclude technical flukes. On the contrary, do you know the technological process to produce CPUs with varied speed and varied number of cores in the same family? Make a single design. Manufacture exactly the same wafers. Test the built CPUs, stress-test their capacity to perform at varied speeds. Surprise: the results vary wildly from chip to chip, made with exactly the same design, machine, process. These made with less contaminants will perform better and be labelled higher speeds, these speeds tagged in firmware. These where all 4 cores work flawlessly will be sold as quad-core. These where 2 cores are definitely underperforming, will have them disabled in firmware and be sold as dual core. You can often make your CPU triple-core by enabling one of cores disabled by factory. And the bottom line is the process of testing depends on luck - on the fact that the fault surfaces during the tests, and not later. That it's frequent enough to be noticed by the QA. That it doesn't appear in conditions obscure enough to be overlooked in test cases. As result you receive a product that will perform correctly most of the time in conditions not too varied from test conditions. But it's full of potential faults, and bugs for which no software solutions exist - because they are unique to your singular issue of the CPU.
Of course there are bug-free CPUs. Manufactured with extreme redundancy, in a process suitable for CPUs of a thousandfold higher complexity. Except they are trivial too, each of the parts testable thoroughly. Modern Intels with byzanthine complexity of super-efficient optimizers built in, simply utilize every last nanometer of chip to fit more cache, more pipelines - they won't sacrifice half of the volume to features that will be used only during testing, to triple-check every single transistor.
Luckily, in this game the pasture is calculated in such a way, that the moment you introduce more cows than all neighbors combined, all cows die, including your own, and another neighbor introducing yet another cow actually improves the quality of the pasture.
Note this is not a blind theory. People who manufacture ASIC devices *sell* them for bitcoin already. They *could* run them themselves and would probably earn more BTC. But as result they would weaken bitcoin and the earned BTC would get cheaper in the long run! In essence, they take care so that the computational power is distributed.
Dumb miners *could* theoretically screw up like that. But achieving 51% is a very difficult task. To achieve 51% you need to be pretty smart - probably smart enough to understand achieving 51% would be self-destructive.
One exception: an institution bound on destroying bitcoin - say, the World Bank - could do this, precisely in order to destroy it.
Sorry but being a smart miner you will avoid the situation when 51% becomes possible. The moment it is, market plummets and all your hard-mined and double-spent bitcoins become worthless. In essence, 51% is not "earn a lot of money" attack, it's a "murder the network" attack. Miners don't want the network murdered.
What about BTC transfer delay? You're not guaranteed your transaction is included in the nearest block, nor even a block 6 hours from now. 6 hours is ages in the bitcoin market, and especially in times of panic the time increases. As result, you click "buy" on the item, copy the Overstock address to Bitcoin-QT, enter the desired amount, click "send" and... 3 hours later coinbase receives your bitcoin. And at that time the price doubled. Will Coinbase pay Overstock the price from 3 hours ago?
Where does Overstock get the coins to sell? From people who pay for their wares with these coins. Where do these people get their coins from?
- self-mined will be a small margin. - hoarders spending from their hoard, reintroducing frozen coin to the market, which is positive - people buying BTC. The same BTC that Overstock is selling.
The increase in sales of BTC from Overstock will be met with about equivalent increase in demand for BTC in order to purchase goods from Overstock.
First off, yes, that would happen IF the value dropped to 1/1000. Which it won't. Quite recently it jumped UP by an order of magnitude (around the time Baidu announced accepting BTC). and it's very unlikely to drop more than 2 orders of magnitude. For a time. Then it will climb back up.
The network size would not fall to 1/1000th with such a drop. It would halve at worst. With fewer players difficulty to mine drops and profitability for the rest increases, and as long as they barely break even there is no sense for them to stop operating. Many would even operate at loss, in hopes of bitcoin restoring its value over time, so whatever they acquire during the low time would gain value later.
Also note there are countless tiny players who simply don't look at the electricity costs. People living in dorms paying a fixed rent no matter what their electricity usage. People with illicit power links, stealing power from communal grid. People with own solar or wind power. Kids running GPU miners while their parents pay electricity bills. For them the threshold is way lower.
Essentially, even if the size would drop, it wouldn't drop enough to be vulnerable to the 51% attack.
And bitcoin gaining popularity gains price. Last "crash" almost halved its value - bringing it to roughly 5x the value from before the recent rush. The more value it gains the farther it would need to fall in order to make mining unprofitable.
The network is far from easy to take over because meaningful participation in mining requires a significant up-front investment and relatively small per-month cost, meaning the value would need to plummet not by half, but by 3 orders of magnitude for current players to quit the game, and the cost for new players to enter would NOT fall with bitcoin price drop. In other words, production (and as result risk of majority control) is relatively independent from price.
Yes, for a start-up coin small userbase may mean an up-front risk of 51% attack. Bitcoin userbase is currently too big for the 51% attack, and this situation is very unlikely to change.
----
OTOH, I agree its value is a problem for use as a normal currency. Imagine you have an on-line shop. You bought 100 gizmos for $60/pc in bulk, paying $6000 and offer them for sale for $100 or 1 BTC each, with current Bitcoin value oscillating around $100. Overnight Bitcoin plummets to $30. In matter of minutes your stock of gizmos is sold out, and you have 100BTC worth $3000. You can't restock your gizmos. You must wait and hope your 100BTC gets back to $100, which it may in half a year or never, and until then you have no money to restock your shop.
Any of these doable with $1000 tools budget and no specialized gunsmith tools? You get a drilled rifle blank, a standard lathe (no 1 rotation per ~16" gear or the likes, and $1000 budget for a generic hardware store with no gun stand or gunsmithing dept (that must cover both tools and materials). Can you rifle a barrel with that?
...the essence of this being that you can build pretty much anything, starting off with a hammer and building progressively more advanced tools. Ending with: to rifle a barrel you need pretty damn specialized tools, which sure you can build using generic tools, but that task is nowhere near simple; significantly more complex than rifling the barrel using these specialized tools and pretty high up the difficulty curve. We're off from cutting a groove in whatever steel the barrel is made of (not very hard), to creating a very specialized carbide blade and re-gearing a lathe. Not your average garage workshop task.
A normal inside-thread cutter is self-guiding thanks to very small step per rotation. You have some 100 blades on a single cutter, each cutting a minimal sliver of metal from the single thread it's creating, each turn is 4 blade passes through each part of the thread. There's about 1 turn per 1mm of travel. Each of the blades keeps the remaining blades aligned so you get very small tolerances despite the tool simply "screwing itself in". First 1-2 turns may be messed up before the cutter "gains traction" but the remainder is fine.
Bore has 4-8 separate grooves, each making maybe 4 turns per whole barrel length, often less. You NEED to guide its rotation. If you apply lateral (rotary) force, you'll simply cut a circle or break the blade. If you apply lengthwise force, you will get the same as with normal cutter: first 1-2 turns messed up before the cutter "gains traction". Except 1-2 turns is halfway down the barrel. Essentially, you need an external, mechanical guide that drives the cutter in the spiral needed for the rifling. Usually there is only one blade, oriented for downstroke (cutting when pulling it out, not when pushing it in) and a mechanism that drives it back and forth through the barrel, then rotates the barrel by desired angle to cut another groove. NOTHING like normal internal thread cutter.
Slashdot Mirror
There's more than technical merit to every product.
There's the price, the licensing, the support, the market, plus all these factors applied to dependencies (e.g. hardware your software is meant to run on.)
Bad management can snuff the most superior technological merit.
Let's imagine a mod for your_newest_game: giving it anisotropic antialiasing x4.
In your game, you can enter "Options", click "Graphics", "Advanced", and drag the anisotropic filtering slider to "x4". Then click "Apply" and it's saved in a config file in the game directory.
Meanwhile, the mod finds the configh file and changes the line that reads "GFX_Anisotropic_Filtering=0" to 4.
Would you agree that's rather silly, considering this is within skill of about every user?
Well, now remove the option from game menu. Pack the game files with an obscure compression program.
It took some smart modder to figure out the compression program and be able to create an automated tool that applies modifications inside the archive - without need to repack the multi-gigabyte archive. He released the tool, and another one that allows you to browse the game files, as if they were unpacked.
Now someone else finds the config file, and uses the program to change "GFX_Anisotropic_Filtering=0" to 4 within the archive. Anyone with access to the tools can do this. The actual modification of the game is completely trivial. It's just that even most trivial tweak to the game must be packaged in the same, complex tool as a mod.
Do you want pretty graphics or an excuse to keep griping about?
Actually - not so much "modders" as "tweakers". Back in the day, it was editing an .ini file, and what they do is nothing else. They don't add external shaders, they don't add or replace any content, they just enable content that is there, in game, disabled by settings. The only reason this is done through mods and not plain config file edit is that the config file is buried within proprietary archive of the game, and can be modified only through a mod.
"Get" stuttering? The mod actually managed to REMOVE stuttering from the original game.
There's a problem with this claim. Similarly to file-sharers, they don't *actually* cost the transport companies any money.
1. It assumes they would pay if not the scheme. It doesn't assume they would take alternate transport medium.
2. It assumes all the income is from the tickets. It disregards both tax-funded subsidies (from 'freeloaders' tax money) and the punitive charges income (no matter if paid by given freeloader alone or from 'insurance')
3. It assumes cost scales linearly with the number of passengers.
Let me expand on that. The cost of operating a line is mostly a fixed value - amortization of the bus, salary of the driver, costs of operating the infrastructure. Fuel is only a minor part, and even then, then, take bus weight of 10 tons, passenger weight of 100kg, assuming (falsely) the fuel use increases linearly with number of passengers, the difference in cost between driving an empty bus and one with 1 freeloader would be 1%.
In other words, each freeloader in the absolutely worst case scenario adds 1% to the cost of operating a line. In more realistic scenario, this number will be over an order of magnitude smaller.
As effect - yes, the freeloaders do increase the costs for others. Assuming 10 of them per ride - by about 1%.
And one thing more. If they can't break even on the punitive charges, that means the controls are too infrequent. If $15/month suffices to cover $180/capture, that means one control per 14 months. Seriously? Make the average 1/month (still very little with people riding daily) and the 'insurance' will need to rise to $180/month. With $150/monthly pass, the problem will vanish.
Snow is iresome, making the ride uncomfortable, slower, and more risky.
Even small amounts of ice make the ride practically impossible.
During a turn on a bike there's a significant lateral stress against the tire. On slipery surface you just fall, period. With snow or mud the tire squeezes a track, keeping some traction. On ice it just slips.
Considering the size and mass of these drones, comparing to toughness of other airborne objects, and comparing the amount of emotions they arouse...
why is existence of birds still legal?
As one who works with these currently, I can confirm.
The main CPU has its software written in such a way, that you can't force green on two conflicting directions. Simply, the traffic program won't allow them, not through some emergency modes but just not starting a conflicting green until the prior one is lit and sufficient time after it went off was elapsed.
You could try to override it, say, redefining signal color definitions, "green is the new red", or even try to short-circuit the wires. But that is detected by the hardware and then the supervising CPU kicks in and simply trips the contactor disabling power to the signal lights. No 'emergency mode' which could still light up green in case of short circuit, no trying to make output modules not to output any signals in case a triac is fried, just general power off through a mechanical switch. (also, any output module that reports some kind of fault and doesn't get a reply within 300ms, it trips the same contact.)
What the attacker -could- do is change the traffic program - redefine assignments of signal groups, change the collision matrix - making both processor simply not see two groups as colliding. But to do so, they would need access to some highly specialized software for generating traffic programs, or painstakingly reverse-engineer the file already present in the controller, not a small feat.
They *can*. But they *don't*.
While not pushed by quotas, they are tempted by personal incomes directly proportional to in-game sales. Ther is always the incentive to grab more money, whatever it is.
And single-player games can be (and frequently are) made equally hopeless money sinks in pursuit of progress in game, as opposed to advantage over other players. When a game requires you to spend three years to accumulate enough valuables through "free means" to avoid that one $30 payment required to progress (actual example), and this after you've invested about a month of your time to arrive at that point, this is no longer "pay if you want to gain advantage", this is "pay or GTFO."
Once again, this is not about what game companies may do to make these games competetive and fun. This is about the ugly reality of what they actually do, with few very rare exceptions. So, no wonder if a player sees a game announced as F2P, automatically labels it a scam. Because usually it is a scam.
Fact versus Belief.
Even though giving it away would not affect CostCo's income adversely, the management is likely to believe the opposite would be the case. Even worse if *some* managers deemed the prior statements a valid risk, one that gave a "go ahead" to distribution would get in trouble. "Better safe than sorry", even though the actual risk was non-existent, the very likehood of belief for it to be real made it serious enough.
Fill up the ATM with propane gas through the money slot.
Set up a fuse.
Pick up money and run.
Some photos.
Quite impressive, though the success ratio isn't too high.
"Please enter the amount."
700
"The amount entered is not divisible by 0. Please select:
[650]
[750]
[other]
[cancel]"
I choose "Cancel" just in case it applies similar mathematics to my actual payout.
Actually, that sounds like info muggers would find pretty valuable.
So, there's this bar, with "No Blacks Allowed" sign.
The owner takes down that sign. Everyone's welcome.
"Oh no! You're banning whites! You bastards!"
Formal proof of design correctness doesn't preclude technical flukes.
On the contrary, do you know the technological process to produce CPUs with varied speed and varied number of cores in the same family?
Make a single design. Manufacture exactly the same wafers. Test the built CPUs, stress-test their capacity to perform at varied speeds.
Surprise: the results vary wildly from chip to chip, made with exactly the same design, machine, process.
These made with less contaminants will perform better and be labelled higher speeds, these speeds tagged in firmware. These where all 4 cores work flawlessly will be sold as quad-core. These where 2 cores are definitely underperforming, will have them disabled in firmware and be sold as dual core. You can often make your CPU triple-core by enabling one of cores disabled by factory.
And the bottom line is the process of testing depends on luck - on the fact that the fault surfaces during the tests, and not later. That it's frequent enough to be noticed by the QA. That it doesn't appear in conditions obscure enough to be overlooked in test cases.
As result you receive a product that will perform correctly most of the time in conditions not too varied from test conditions. But it's full of potential faults, and bugs for which no software solutions exist - because they are unique to your singular issue of the CPU.
Of course there are bug-free CPUs. Manufactured with extreme redundancy, in a process suitable for CPUs of a thousandfold higher complexity. Except they are trivial too, each of the parts testable thoroughly. Modern Intels with byzanthine complexity of super-efficient optimizers built in, simply utilize every last nanometer of chip to fit more cache, more pipelines - they won't sacrifice half of the volume to features that will be used only during testing, to triple-check every single transistor.
Luckily, in this game the pasture is calculated in such a way, that the moment you introduce more cows than all neighbors combined, all cows die, including your own, and another neighbor introducing yet another cow actually improves the quality of the pasture.
Note this is not a blind theory. People who manufacture ASIC devices *sell* them for bitcoin already. They *could* run them themselves and would probably earn more BTC. But as result they would weaken bitcoin and the earned BTC would get cheaper in the long run! In essence, they take care so that the computational power is distributed.
Dumb miners *could* theoretically screw up like that. But achieving 51% is a very difficult task. To achieve 51% you need to be pretty smart - probably smart enough to understand achieving 51% would be self-destructive.
One exception: an institution bound on destroying bitcoin - say, the World Bank - could do this, precisely in order to destroy it.
Sorry but being a smart miner you will avoid the situation when 51% becomes possible. The moment it is, market plummets and all your hard-mined and double-spent bitcoins become worthless. In essence, 51% is not "earn a lot of money" attack, it's a "murder the network" attack. Miners don't want the network murdered.
What about BTC transfer delay?
You're not guaranteed your transaction is included in the nearest block, nor even a block 6 hours from now. 6 hours is ages in the bitcoin market, and especially in times of panic the time increases.
As result, you click "buy" on the item, copy the Overstock address to Bitcoin-QT, enter the desired amount, click "send" and... 3 hours later coinbase receives your bitcoin. And at that time the price doubled.
Will Coinbase pay Overstock the price from 3 hours ago?
Where does Overstock get the coins to sell?
From people who pay for their wares with these coins.
Where do these people get their coins from?
- self-mined will be a small margin.
- hoarders spending from their hoard, reintroducing frozen coin to the market, which is positive
- people buying BTC. The same BTC that Overstock is selling.
The increase in sales of BTC from Overstock will be met with about equivalent increase in demand for BTC in order to purchase goods from Overstock.
First off, yes, that would happen IF the value dropped to 1/1000. Which it won't. Quite recently it jumped UP by an order of magnitude (around the time Baidu announced accepting BTC). and it's very unlikely to drop more than 2 orders of magnitude. For a time. Then it will climb back up.
The network size would not fall to 1/1000th with such a drop. It would halve at worst. With fewer players difficulty to mine drops and profitability for the rest increases, and as long as they barely break even there is no sense for them to stop operating. Many would even operate at loss, in hopes of bitcoin restoring its value over time, so whatever they acquire during the low time would gain value later.
Also note there are countless tiny players who simply don't look at the electricity costs. People living in dorms paying a fixed rent no matter what their electricity usage. People with illicit power links, stealing power from communal grid. People with own solar or wind power. Kids running GPU miners while their parents pay electricity bills. For them the threshold is way lower.
Essentially, even if the size would drop, it wouldn't drop enough to be vulnerable to the 51% attack.
And bitcoin gaining popularity gains price. Last "crash" almost halved its value - bringing it to roughly 5x the value from before the recent rush. The more value it gains the farther it would need to fall in order to make mining unprofitable.
The network is far from easy to take over because meaningful participation in mining requires a significant up-front investment and relatively small per-month cost, meaning the value would need to plummet not by half, but by 3 orders of magnitude for current players to quit the game, and the cost for new players to enter would NOT fall with bitcoin price drop. In other words, production (and as result risk of majority control) is relatively independent from price.
Yes, for a start-up coin small userbase may mean an up-front risk of 51% attack. Bitcoin userbase is currently too big for the 51% attack, and this situation is very unlikely to change.
----
OTOH, I agree its value is a problem for use as a normal currency. Imagine you have an on-line shop. You bought 100 gizmos for $60/pc in bulk, paying $6000 and offer them for sale for $100 or 1 BTC each, with current Bitcoin value oscillating around $100. Overnight Bitcoin plummets to $30. In matter of minutes your stock of gizmos is sold out, and you have 100BTC worth $3000. You can't restock your gizmos. You must wait and hope your 100BTC gets back to $100, which it may in half a year or never, and until then you have no money to restock your shop.
Any of these doable with $1000 tools budget and no specialized gunsmith tools? You get a drilled rifle blank, a standard lathe (no 1 rotation per ~16" gear or the likes, and $1000 budget for a generic hardware store with no gun stand or gunsmithing dept (that must cover both tools and materials). Can you rifle a barrel with that?
...the essence of this being that you can build pretty much anything, starting off with a hammer and building progressively more advanced tools. Ending with: to rifle a barrel you need pretty damn specialized tools, which sure you can build using generic tools, but that task is nowhere near simple; significantly more complex than rifling the barrel using these specialized tools and pretty high up the difficulty curve. We're off from cutting a groove in whatever steel the barrel is made of (not very hard), to creating a very specialized carbide blade and re-gearing a lathe. Not your average garage workshop task.
"Not that different"?
A normal inside-thread cutter is self-guiding thanks to very small step per rotation. You have some 100 blades on a single cutter, each cutting a minimal sliver of metal from the single thread it's creating, each turn is 4 blade passes through each part of the thread. There's about 1 turn per 1mm of travel. Each of the blades keeps the remaining blades aligned so you get very small tolerances despite the tool simply "screwing itself in". First 1-2 turns may be messed up before the cutter "gains traction" but the remainder is fine.
Bore has 4-8 separate grooves, each making maybe 4 turns per whole barrel length, often less. You NEED to guide its rotation. If you apply lateral (rotary) force, you'll simply cut a circle or break the blade. If you apply lengthwise force, you will get the same as with normal cutter: first 1-2 turns messed up before the cutter "gains traction". Except 1-2 turns is halfway down the barrel.
Essentially, you need an external, mechanical guide that drives the cutter in the spiral needed for the rifling. Usually there is only one blade, oriented for downstroke (cutting when pulling it out, not when pushing it in) and a mechanism that drives it back and forth through the barrel, then rotates the barrel by desired angle to cut another groove. NOTHING like normal internal thread cutter.