That's a job for fair queueing. They should also probably quit advertising such that they create the impression that each user gets the full bandwidth all the time. You can't blame the customers for falling for the ISP's fib.
I would strongly consider waiting. The performance you see now may drop considerably once all the patches (microcode, OS, and user applications) are in.
It is probably worth your time to research the latest generation AMD, especially if the software you will be using is multi-threaded. Historically, Intel has had better single thread performance, but AMD has provided more bang for the buck if you use all of the cores. The latest generation looks like it beats Intel single threaded as well, especially once the Meltdown patches are applied.
AMD and ARM have some similar flaws but they are harder to exploit and the performance costs of preventing exploitation are smaller.
Intel has more flaws and they are much more exploitable. Intel have put considerable effort into sewing confusion on that point, doing their best to leave the false impression that all CPUs are equally problematic.
Electricity isn't metered because it's a utility, it's metered because each KWh produced costs money due to fuel consumed.
ISPs don't have to pay any more for fully utilized connections than they do for idle connections. The only exception is paid transit, but in their volume, it's less than a dollar per Mbps and in many cases they avoid it by peering.
If they were that worried about uplink costs, they would take netflix up on their offer of colocated caching servers.
More correctly, the store lost the WHOLESALE cost. But they actually did have a loss since they can't just poof another one in to existence for nothing.
But when the "item" for sale is a digital copy, they DO just poof them in to existence. If you download a copy, they don't have to have a stock boy run to the back and get another one to put on the server.
Actually, SysV init can and did mount it, following my instructions to allow degraded mode. For the simple reason that SysV doesn't treat admin configuration as a suggestion.
On the other hand, how much value does gold have to someone who is starving? If the starvation is serious enough, the Jew or Muslim will eat the pork in order to live. Most vegetarians will as well.
Note, the OS is able to boot just fine without any of the involved system programs understanding REST or SQL. I would absolutely object to a system that won't even boot far enough to log in and debug without REST or SQL. Applications and non-system services are free to use SQL and REST as needed.
Overly complex dependencies result in brittle systems. There's a lot of good to be said for a system where if the kernel can manage to execute/bin/bash, the admin can do something useful.
Apparently La Liga believes everyone's smartphone is theirs to do with as they please. Are they really any better than the people who violate their copyrights?
At the same time, they are being dishonest when they claim that everyone who pirated would have paid for it if piracy wasn't an option. In fact, many would have just done without.
It sounds like you're trying to invent a scenario where there might be a problem. What is your use case where you can't simply ssh from one box to another and cut/paste into the ssh terminal?
If mining cost nothing, then there would be mining as long as a few were still interested. Since it does cost, it will stop when the value people place on bitcoin isn't enough to justify mining. There will be some people trying to transact when the last miner hits the off button.
While my own informal observations lack rigor (since I haven't the time or money to make more rigorous observations), it's not necessarily harmful to people, but when the "milk" production is boosted, there is a noticable "watered down" quality to the milk.
Then with no one mining, losses (forgot wallet key, etc.) slowly push the price back up. It should not normally be possible for the bitcoin price to fall below the cost of electricity used to mine it, except very briefly.
In fact, no. With no one mining, bitcoin is dead. Nobody can buy, sell, or trade it because transactions can't happen.
But you can only change the systemd tool for a clone of that tool.
As for the systemd test, NOW it has been moved to the initramfs NOT running systemd. That is a kludge to make it work. You could say that systemd accidentally developed a dependency on the old SysV init. But it was definitely systemd, that's why the cylon followed by the emergency shell. But systemd won't do any better for a non-root volume and NOW, the plan was always to use something else in the initramfs. And we have always been at war with Eastasia.
In fact, if nobody is mining it, it becomes impossible to transact in it at all. The process of mining is what commits transactions to the blockchain.
The number of miners has to be sufficient that no individual or group has the ability to decide what transactions become part of the blockchain and which ones don't (a 51% attack).
My test case (in a VM) was configured to allow mounting degraded. Then I failed one of the drives in the VM and booted. Systemd wouldn't even attempt to mount the volume, just the cylon followed by the emergency shell. After digging around in the twisty mess of configuration filed, I found there is no way to make systemd just try the mount command as an imperitive. It decided the volume couldn't come up and so it wasn't going to try.
Of course, since degraded mode was configured, issuing the mount command manually in the emergency shell mounted it up with no issue at all.
Meanwhile, remember the Apr fools joke COMEFROM command? Systemd actually implements it.
In general, systemd isn't all that flexible. If you have an unusual situation, you'll have to use something other than systemd to bring it up. Unfortunately, systemd doesn't play nice with others so that means replacing systemd. Unfortunately, systemd has it's tenticles embedded into everything, so that's going to be a much harder task than it should be, involving a lot of recompiling. Hope you didn't want to use Gnome in that configuration.
The systemd project would have developers write daemons with dependencies on systemd. ("come into my parlor" said the spider to the fly). DON'T DO IT! Your project, like Gnome will end up as part of a vendor lock-in that way.
In the long term, that's bad for Linux. There's no reason that everything systemd does couldn't have been done the Unix way with smaller interchangeable tools that could inter-operate.
Slashdot Mirror
That's a job for fair queueing. They should also probably quit advertising such that they create the impression that each user gets the full bandwidth all the time. You can't blame the customers for falling for the ISP's fib.
I would strongly consider waiting. The performance you see now may drop considerably once all the patches (microcode, OS, and user applications) are in.
It is probably worth your time to research the latest generation AMD, especially if the software you will be using is multi-threaded. Historically, Intel has had better single thread performance, but AMD has provided more bang for the buck if you use all of the cores. The latest generation looks like it beats Intel single threaded as well, especially once the Meltdown patches are applied.
In part.
AMD and ARM have some similar flaws but they are harder to exploit and the performance costs of preventing exploitation are smaller.
Intel has more flaws and they are much more exploitable. Intel have put considerable effort into sewing confusion on that point, doing their best to leave the false impression that all CPUs are equally problematic.
Electricity isn't metered because it's a utility, it's metered because each KWh produced costs money due to fuel consumed.
ISPs don't have to pay any more for fully utilized connections than they do for idle connections. The only exception is paid transit, but in their volume, it's less than a dollar per Mbps and in many cases they avoid it by peering.
If they were that worried about uplink costs, they would take netflix up on their offer of colocated caching servers.
Not always. If you and some other guy are starving and help is weeks away, good luck buying the last burger from him with your gold.
More correctly, the store lost the WHOLESALE cost. But they actually did have a loss since they can't just poof another one in to existence for nothing.
But when the "item" for sale is a digital copy, they DO just poof them in to existence. If you download a copy, they don't have to have a stock boy run to the back and get another one to put on the server.
Actually, SysV init can and did mount it, following my instructions to allow degraded mode. For the simple reason that SysV doesn't treat admin configuration as a suggestion.
On the other hand, how much value does gold have to someone who is starving? If the starvation is serious enough, the Jew or Muslim will eat the pork in order to live. Most vegetarians will as well.
Note, the OS is able to boot just fine without any of the involved system programs understanding REST or SQL. I would absolutely object to a system that won't even boot far enough to log in and debug without REST or SQL. Applications and non-system services are free to use SQL and REST as needed.
Overly complex dependencies result in brittle systems. There's a lot of good to be said for a system where if the kernel can manage to execute /bin/bash, the admin can do something useful.
Now that everyone knows what they're doing, yes. Many are doing just that.
What I'm saying is that people who live in glass houses shouldn't throw stones.
I am not streaming La Liga at all.
Apparently La Liga believes everyone's smartphone is theirs to do with as they please. Are they really any better than the people who violate their copyrights?
At the same time, they are being dishonest when they claim that everyone who pirated would have paid for it if piracy wasn't an option. In fact, many would have just done without.
Or both devices ssh to a device running an ssh server. Or they use mDNS. Or a text message, or a WhatsApp or Bluetooth, or....
It sounds like you're trying to invent a scenario where there might be a problem. What is your use case where you can't simply ssh from one box to another and cut/paste into the ssh terminal?
It's one thing to depend on a fundamental API of Unix, quite another to kitchen sink an entire API and support subsystem in as a dependency.
But what really happens is the average internet user buys an AP/router, gets the teen next door to plug it in for them, and done.
SSH
If mining cost nothing, then there would be mining as long as a few were still interested. Since it does cost, it will stop when the value people place on bitcoin isn't enough to justify mining. There will be some people trying to transact when the last miner hits the off button.
"Get rid of" - eliminate. No longer possess. Sell to the highest bidder
UhOh
While my own informal observations lack rigor (since I haven't the time or money to make more rigorous observations), it's not necessarily harmful to people, but when the "milk" production is boosted, there is a noticable "watered down" quality to the milk.
Meanwhile, the FDA is hardly infallible.
I was addressing:
Then with no one mining, losses (forgot wallet key, etc.) slowly push the price back up. It should not normally be possible for the bitcoin price to fall below the cost of electricity used to mine it, except very briefly.
In fact, no. With no one mining, bitcoin is dead. Nobody can buy, sell, or trade it because transactions can't happen.
But you can only change the systemd tool for a clone of that tool.
As for the systemd test, NOW it has been moved to the initramfs NOT running systemd. That is a kludge to make it work. You could say that systemd accidentally developed a dependency on the old SysV init. But it was definitely systemd, that's why the cylon followed by the emergency shell. But systemd won't do any better for a non-root volume and NOW, the plan was always to use something else in the initramfs. And we have always been at war with Eastasia.
In fact, if nobody is mining it, it becomes impossible to transact in it at all. The process of mining is what commits transactions to the blockchain.
The number of miners has to be sufficient that no individual or group has the ability to decide what transactions become part of the blockchain and which ones don't (a 51% attack).
My test case (in a VM) was configured to allow mounting degraded. Then I failed one of the drives in the VM and booted. Systemd wouldn't even attempt to mount the volume, just the cylon followed by the emergency shell. After digging around in the twisty mess of configuration filed, I found there is no way to make systemd just try the mount command as an imperitive. It decided the volume couldn't come up and so it wasn't going to try.
Of course, since degraded mode was configured, issuing the mount command manually in the emergency shell mounted it up with no issue at all.
Meanwhile, remember the Apr fools joke COMEFROM command? Systemd actually implements it.
In general, systemd isn't all that flexible. If you have an unusual situation, you'll have to use something other than systemd to bring it up. Unfortunately, systemd doesn't play nice with others so that means replacing systemd. Unfortunately, systemd has it's tenticles embedded into everything, so that's going to be a much harder task than it should be, involving a lot of recompiling. Hope you didn't want to use Gnome in that configuration.
The systemd project would have developers write daemons with dependencies on systemd. ("come into my parlor" said the spider to the fly). DON'T DO IT! Your project, like Gnome will end up as part of a vendor lock-in that way.
In the long term, that's bad for Linux. There's no reason that everything systemd does couldn't have been done the Unix way with smaller interchangeable tools that could inter-operate.