"SpaceX expects its own latencies to be between 25 and 35ms, similar to the latencies measured for wired Internet services. Current satellite ISPs have latencies of 600ms or more, " https://arstechnica.com/inform.... Possibly dated information. But one has to wonder, even if you've fixed a latency issue, how is packet collision handled when ground stations can't hear each other? There's only so much bandwidth allocated. Should be interesting.
Just the same as satellite phones and other "internet over satellite" (with uplink) providers... Time-division multiple access.
Ground stations have to allocate some time/frequency space over a "management slot" before they are allowed to transmit their normal data.
A lot of people are criticising how cheaply made these drones were, but simplicity is genius... The amount spent by the Russians to shoot these drones down must have vastly exceeded the cost to build and launch the drones, not to mention the cost of repairing/replacing anything that the drones managed to hit. If you can spend $50 and cause your enemy to waste $500 repelling your attack then you've achieved a successful result.
Only if you have at least 10% of the resources of your enemy available... otherwise you will run out of steam before the enemy, which is not a successful result.
Is it asymmetric? If they have a whole cloud of drones, you can defend against it with your own cloud of drones. And if you build your own cloud of drones, that cloud can also be used for offense. Asymmetric, as I understand it, is when you have to spend a lot on defense and it doesn't buy you any offense. This is more symmetric because it is really just like equalizing soldiers on a battlefield. If they have 10 drones and you have 10 drones, you can fight them to a standstill. But if you have 100 drones, you can overpower their numbers. Defense is achieved by spending the same amount of money that your opponent spent... that's symmetry.
if you don't have a "front line" with well defined "battle zones" an attacker with an easy to transport weapon system has always an advantage. Defending against swarms as in the video would require the defender to have "defense swarms" everywhere... while the attacker can drive his swarm close to the destination to launch a concentrated attack.
Yes. In addition to this, this might even be a good step towards getting rid of DRM.
Currently everyone who wants DRM use DRM... they either use flash/silverlight (turing-complete stuff that can mess up your whole browser) or deploy special Apps (which lock out browsers completely).
Now the move goes into using a standardized API with their DRM behind, an API that can ONLY be used for media decoding.
This makes it much easier to sandbox the DRM and make sure it doesn't do things beyond handling the video/audio content. It also moves the infrastructure of the content distributors much closer to a "non-DRM" HTML5-based delivery... which means the economic incentive to drop DRM (more customers versus costs to reach this customers) gets better.
The other band-aid is that the potatoes which would have been on the ship would have been treated with a chemical (chlorpropham or maleic hydrazide) to prevent them from budding.
The potatoes were of the botanic experiments planned for Mars (remember, Mark was a Botanist), so it is very unlikely they would not be ably to bud.
You don't place it exactly at L1, you place it slightly out of L1 so the pressure of the solar wind will be countered by a gravity pull towards the Sun.
Of course you need some "thrusters" to keep the thing at the right place, but this should be easy to do by changing the shape of the magnet field, using the solar wind itself to move the shield around.
It is a quite interesting thing being able to "re-watch" a Supernova from the beginning because the light has multiple paths towards Earth so we got a "warning" when it will happen.
The problem with a lot of Supernova explosions is that we often don't know what happened in the early phase (until it became bright enough to be noticed in wide-field pictures). It is most likely "a little bit" too far away to learn what type of star has exploded, but it still a great opportunity.
There is only ONE reason why Helium-3 fusion could be good... it doesn't produce neutrons, which means all byproducts can be captured by magnetic fields and we don't produce radioactive waste...
BUT (as quite a few people here said) a) we don't have a working fusion reactor (no matter what reaction) b) He3 fusion is a lot harder to do than D-T fusion c) He3 on Earth is practically non-existent. He3 exists in low concentrations in the Lunar Dust...
so lets first get the current energy problems resolved with existing tech (solar, wind, water,...), then lets get D-T fusion running, then lets colonize the Moon (and maybe a couple of other planets)... and when we arrive at Jupiter and Saturn, we can think about He3 fusion again.;)
How's it going to protect crew (and equipment) from hard radiation? Seems to me that getting all that (lots of) extra mass to escape velocity would make it *way* more expensive than.
Would it be more practical to build a habitat in one of those caves that the Moon is supposed to have?
Maybe they could build a spacestation into an asteroid that they pulled into the Lagrange point. A few meters of nickel-iron would be a good protection.
Or is there a good reason why this is in fact more difficult than Mars-colonisation which I've just overlooked?
Natural resources (we might get these from asteroids too) and an atmosphere that protects you from asteroid impacts maybe? And the chance to terraform parts of Mars (or all of Mars) with time?
I am still using voyage linux (.hk) and that is optimized for embedded use, such as audio. but they are still stuck on a way WAY old version of grub (grub1, not even grub2) and they boot ext2fs and that's it. not even ext3, afaik.
and yet, I do build kernels that support the latest audio (and dsd) drivers.
so, your theory is blown. some distros are still old but that does not mean the kernel has to be.
duh!
Yes, but the change should not matter that much for you.
You can still use an ext3 partition format... the kernel ext4 module can read and write this format fine.
This only works if Debian can guarantee the integrity of the development tool chain. See this >30 year old talk/paper by Ken Thompson describing the problem. Once inserted, the malware is persistent and invisible. Re-compiling your compiler and applications from known-good versions doesn't help.
The problem got a lot more complicated for the attacker today... Thompsons attack works well if there are only a few architectures and only a single compiler. But the attack complexity grows exponentially in the presence of multiple architectures (that can be used to cross-compile each other) and multiple compilers (that can compile each other).
Now you need a compiler virus that not only compiles on all architectures well, it also needs to detect all kind of compilers that are there and works on all versions of them.
The "reproducible build" system makes it even worse for the attacker, because its easier to to compare the results.
1. Designed or modified to use “cryptography” employing digital techniques performing any cryptographic function other than authentication, digital signature or the execution of copyprotected “software”, and having any of the following:
Technical Notes:
1. Functions for authentication, digital signature and the execution of copyprotected “software” include their associated key management function.
2. Authentication includes all aspects of access control where there is no encryption of files or text except as directly related to the protection of passwords, Personal Identification Numbers (PINs) or similar data to prevent unauthorised access.
a. A “symmetric algorithm” employing a key length in excess of 56 bits; or
Technical Note:
In Category 5 — Part 2, parity bits are not included in the key length.
b. An “asymmetric algorithm” where the security of the algorithm is based on any of the following:
1. Factorisation of integers in excess of 512 bits (e.g., RSA);
2. Computation of discrete logarithms in a multiplicative group of a finite field of size greater than 512 bits (e.g., DiffieHellman over Z/pZ); or
3. Discrete logarithms in a group other than mentioned in 5A002.a.1.b.2. in excess of 112 bits (e.g., DiffieHellman over an elliptic curve);
It is a new "keyboard app".
Don't expect to add features like this in the coming "core OS" versions of Android... Google is busy getting things out of the core so they can update them independently.
Slashdot Mirror
"SpaceX expects its own latencies to be between 25 and 35ms, similar to the latencies measured for wired Internet services. Current satellite ISPs have latencies of 600ms or more, " https://arstechnica.com/inform.... Possibly dated information. But one has to wonder, even if you've fixed a latency issue, how is packet collision handled when ground stations can't hear each other? There's only so much bandwidth allocated. Should be interesting.
Just the same as satellite phones and other "internet over satellite" (with uplink) providers... Time-division multiple access.
Ground stations have to allocate some time/frequency space over a "management slot" before they are allowed to transmit their normal data.
A lot of people are criticising how cheaply made these drones were, but simplicity is genius...
The amount spent by the Russians to shoot these drones down must have vastly exceeded the cost to build and launch the drones, not to mention the cost of repairing/replacing anything that the drones managed to hit. If you can spend $50 and cause your enemy to waste $500 repelling your attack then you've achieved a successful result.
Only if you have at least 10% of the resources of your enemy available... otherwise you will run out of steam before the enemy, which is not a successful result.
Is it asymmetric? If they have a whole cloud of drones, you can defend against it with your own cloud of drones. And if you build your own cloud of drones, that cloud can also be used for offense. Asymmetric, as I understand it, is when you have to spend a lot on defense and it doesn't buy you any offense. This is more symmetric because it is really just like equalizing soldiers on a battlefield. If they have 10 drones and you have 10 drones, you can fight them to a standstill. But if you have 100 drones, you can overpower their numbers. Defense is achieved by spending the same amount of money that your opponent spent... that's symmetry.
if you don't have a "front line" with well defined "battle zones" an attacker with an easy to transport weapon system has always an advantage. Defending against swarms as in the video would require the defender to have "defense swarms" everywhere... while the attacker can drive his swarm close to the destination to launch a concentrated attack.
That said, "only 11 lightyears away" is worth a good chuckle.
Hey, the Ross 128 spaceport is only two hyperspace jumps away from Earth when you lift off for the first time.
Yeah, good old time... has it already been 24 years?
Yes. In addition to this, this might even be a good step towards getting rid of DRM.
Currently everyone who wants DRM use DRM... they either use flash/silverlight (turing-complete stuff that can mess up your whole browser) or deploy special Apps (which lock out browsers completely).
Now the move goes into using a standardized API with their DRM behind, an API that can ONLY be used for media decoding.
This makes it much easier to sandbox the DRM and make sure it doesn't do things beyond handling the video/audio content. It also moves the infrastructure of the content distributors much closer to a "non-DRM" HTML5-based delivery... which means the economic incentive to drop DRM (more customers versus costs to reach this customers) gets better.
The other band-aid is that the potatoes which would have been on the ship would have been treated with a chemical (chlorpropham or maleic hydrazide) to prevent them from budding.
The potatoes were of the botanic experiments planned for Mars (remember, Mark was a Botanist), so it is very unlikely they would not be ably to bud.
You don't place it exactly at L1, you place it slightly out of L1 so the pressure of the solar wind will be countered by a gravity pull towards the Sun.
Of course you need some "thrusters" to keep the thing at the right place, but this should be easy to do by changing the shape of the magnet field, using the solar wind itself to move the shield around.
Not easy, but technically possible
It is a quite interesting thing being able to "re-watch" a Supernova from the beginning because the light has multiple paths towards Earth so we got a "warning" when it will happen.
The problem with a lot of Supernova explosions is that we often don't know what happened in the early phase (until it became bright enough to be noticed in wide-field pictures). It is most likely "a little bit" too far away to learn what type of star has exploded, but it still a great opportunity.
There is only ONE reason why Helium-3 fusion could be good... it doesn't produce neutrons, which means all byproducts can be captured by magnetic fields and we don't produce radioactive waste...
BUT (as quite a few people here said)
a) we don't have a working fusion reactor (no matter what reaction)
b) He3 fusion is a lot harder to do than D-T fusion
c) He3 on Earth is practically non-existent. He3 exists in low concentrations in the Lunar Dust...
so lets first get the current energy problems resolved with existing tech (solar, wind, water, ...), then lets get D-T fusion running, then lets colonize the Moon (and maybe a couple of other planets)... and when we arrive at Jupiter and Saturn, we can think about He3 fusion again. ;)
How's it going to protect crew (and equipment) from hard radiation? Seems to me that getting all that (lots of) extra mass to escape velocity would make it *way* more expensive than.
Would it be more practical to build a habitat in one of those caves that the Moon is supposed to have?
Maybe they could build a spacestation into an asteroid that they pulled into the Lagrange point. A few meters of nickel-iron would be a good protection.
Or is there a good reason why this is in fact more difficult than Mars-colonisation which I've just overlooked?
Natural resources (we might get these from asteroids too) and an atmosphere that protects you from asteroid impacts maybe? And the chance to terraform parts of Mars (or all of Mars) with time?
disagree.
I am still using voyage linux (.hk) and that is optimized for embedded use, such as audio. but they are still stuck on a way WAY old version of grub (grub1, not even grub2) and they boot ext2fs and that's it. not even ext3, afaik.
and yet, I do build kernels that support the latest audio (and dsd) drivers.
so, your theory is blown. some distros are still old but that does not mean the kernel has to be.
duh!
Yes, but the change should not matter that much for you. You can still use an ext3 partition format... the kernel ext4 module can read and write this format fine.
They don't have to, but for a fee, they will.
This is the problem with encryption, unlike safes, which can all be broken into, encryption cannot.
This is not the problem, this is the FEATURE of encryption.
This only works if Debian can guarantee the integrity of the development tool chain. See this >30 year old talk/paper by Ken Thompson describing the problem. Once inserted, the malware is persistent and invisible. Re-compiling your compiler and applications from known-good versions doesn't help.
The problem got a lot more complicated for the attacker today... Thompsons attack works well if there are only a few architectures and only a single compiler. But the attack complexity grows exponentially in the presence of multiple architectures (that can be used to cross-compile each other) and multiple compilers (that can compile each other). Now you need a compiler virus that not only compiles on all architectures well, it also needs to detect all kind of compilers that are there and works on all versions of them. The "reproducible build" system makes it even worse for the attacker, because its easier to to compare the results.
But then they would have no reason to complain about the encryption... which is the whole point of the issue.
The best jokes are the one that are true... Relevant link from CGP Grey: "Is Pluto a planet?" https://www.youtube.com/watch?...
Java Applets at the same time. Or maybe mandate a domain whitelisting for applets.
... that 512 bit elliptic curve cryptography is still quite good. :D
Okay, it is worse... I found some concrete data: http://www.comlaw.gov.au/Detai... (section 5A2)
1. Designed or modified to use “cryptography” employing digital techniques performing any cryptographic function other than authentication, digital signature or the execution of copyprotected “software”, and having any of the following: Technical Notes: 1. Functions for authentication, digital signature and the execution of copyprotected “software” include their associated key management function. 2. Authentication includes all aspects of access control where there is no encryption of files or text except as directly related to the protection of passwords, Personal Identification Numbers (PINs) or similar data to prevent unauthorised access. a. A “symmetric algorithm” employing a key length in excess of 56 bits; or Technical Note: In Category 5 — Part 2, parity bits are not included in the key length. b. An “asymmetric algorithm” where the security of the algorithm is based on any of the following: 1. Factorisation of integers in excess of 512 bits (e.g., RSA); 2. Computation of discrete logarithms in a multiplicative group of a finite field of size greater than 512 bits (e.g., DiffieHellman over Z/pZ); or 3. Discrete logarithms in a group other than mentioned in 5A002.a.1.b.2. in excess of 112 bits (e.g., DiffieHellman over an elliptic curve);
... that 512 bit elliptic curve cryptography is still quite good. :D
Exactly... astonomers love objects like this because that is a chance to learn something new.
It is a new "keyboard app". Don't expect to add features like this in the coming "core OS" versions of Android... Google is busy getting things out of the core so they can update them independently.