It isn't a Second Amendment case, it's First Amendment, very similar to Bernstein v US DoJ .
I don't see why this is even an issue. If a state wants to prevent this, they should pass their own laws, as some have done.
In most states, it is perfectly legal to make your own gun, it does not need to be registered or have a serial number, and you can't transfer it to anyone.
It isn't legal to make an undetectable gun regardless of how you make it. There are easier ways to make an untraceable gun. Putting "3-D printer files" (or CNC milling files) on the internet shouldn't be legally different from publishing a book on how to make your own gun out of stuff you can buy at the hardware store with ordinary household tools.
If someone is going to make their own illegal guns and sell them, restricting the distribution of plans, even if 3-D printers become much cheaper, easier to use, and more capable, isn't going to slow them down at all.
Restricting the plans for the parts that aren't even controlled seems even more clear.
I don't own any guns. I just think this is a dangerous precedent.
If there's no work, it's because efficiency has gone so high that very few people need to work in order to provide for all.
Rather than leave all the wealth (= control of resources) in the hands of the lucky few who ended up on top, a UBI ensures everyone can participate. There's still plenty of room for people to excel, and through hard work be rewarded. It's very much a free market idea, without the coercion of "you'll do this shitty job for low pay because we can make you miserable or dead if you don't", or the "congratulations, you were born rich, you can be a total zero and still have a great life" inequity that's an alternative.
There's a difference between "cheap government housing" and "free government housing".
Cheap government housing should still require people to pay an actual cost, it shouldn't be subsidized housing, but paid for out of each person's UBI. An argument can also be made for access to food, communication, education, libraries, health care. Some should be universal, some should be by choice to spend some of your UBI on the cheap option or spend more on a "better" option.
If someone has an addiction or mental health issue, there still might need to be some level of intervention, but I don't need you telling me what I can use my UBI for, based on your concepts of what I "should" be doing.
A UBI can be funded with a flat tax combined with a VAT, and can be gradually implemented (e.g. at 5% implementation of a 50% flat tax, 25% VAT, $2000/month UBI, you'd have a 2.5% flat income tax, pay 95% of your regular income tax, pay 1.25% VAT, receive $100/month in UBI (not taxed), receive 95% of other benefits, minimum wage reduced to 95% of original value. Raise it to 15% implementation, then 25%, then 50%, 75%, and 100% once every 2 years, tuning numbers as necessary.
A $2000/month UBI, with $800 for dependent children, funded through a 45-50% flat income tax plus about 25% VAT approximately balances (includes Universal Health).
Phase in by starting with 5% and 2.5%, reducing the current income tax by the same percentage, and a UBI of $200/month; increase it each year for 10 years.
Reduce minimum wage and safety net support by the same amount.
I've always assumed the point of "blockchain technology" is that you'd commit a block of transactions, authenticated by a digital signature of whoever is attesting that the information is correct. It's "blockchain" because each new entry includes a reference to the previous entry's hash code. Each new entry locks in all the previous entries. In that sense, it's just a variant of git. If you change an earlier entry, it's made obvious because the hash code doesn't match or the signature doesn't validate, at some point in the chain.
If the entire database can be downloaded by anyone, then multiple copies of it will exist. The only thing needed to validate the entire chain is the hash code of the last entry. If that entry disappears (i.e. the hash code changes), then everyone knows that something is up, and one of the copies can be checked to see where the discrepancy is. If you want to archive a particular transaction, you can simply save the block(s) that it appears in, which proves that it existed in that form at some point in time.
The only way to change a previous entry without setting off alarms is to put in an amended entry as a new transaction.
You'd still have a normal database with all the current data, for fast lookup, but that database can be verified against the chain by anyone.
I don't know that's what people tossing around buzzwords mean, but that's how I'd use "blockchain technology". Note that it doesn't use "mining" in any sense, everything can go through one central point, the transparency comes from the publication of the chain so that at all times it can be verified. It only relies on the security of the hash code algorithm and the signing algorithm.
Depends on what time stamps you're talking about and how the files were transferred. There are many methods of transferring files that will preserve time stamps; depending on the OS and file system, not all time stamps are preserved, or time stamps on enclosing folders might leak more information than the files themselves. I was assuming that the last modified time was being preserved on files, but not necessarily other time stamps. You'd get such behavior if you used cpio to copy the files but not the directory information, for example.
Could have also been zipped before transfer, the time stamps are just how long it took to unzip and write the files. Seriously, that was a conspiracy theory? Lame...
You don't even need to update the scene more often, just go from low resolution to high resolution in that one small patch. I'd think updating the scene and doing a low resolution rendering every 8 ms would be plenty fast. If the stuff being done with ray tracing works out, the high resolution patch might even be done that way.
I'm guessing you'd do this with direct updates to groups of pixels on the screen, with no reference to a scan frequency, just how fast it takes to update 600x600 pixels.
The low resolution image does need to be there, the brain needs a target to track towards, but peripheral vision is really quite low resolution, and gets lower the farther you are from the foveal area, from around 1 pixel per minute to about 1 pixel per degree at the far edges. However, the eye can track VERY fast, so the resolution would need to be high enough not to cause tracking problems as you move towards the edge.
Foveated rendering? That would add further savings but I doubt it's practical. You would need a ridiculously low latency, I don't believe in it.
What kind of ridiculously low latency do you think you could get if you only render a 600x600 image? How long do you think it takes for a saccade to track and stabilize?
I'd imagine you'd have two rendering paths, one for a low-resolution overall image, one to track the eye and render that 600x600 image at the predicted point that the eye will be looking at in the next millisecond. Update about 1000 times per second.
Overall it sounds similar, but incredibly more complex, than a way to structure it that I was working on.
Slightly simplified, fixed Universal Income (I used 2000/month for adults, plus 800/month for dependent children), 45-50% flat tax on income, 25% VAT. Universal Health, elimination of most other forms of "welfare", elimination of minimum wage.
At the time, I just left the corporate tax structure alone. Dividends, interest, capital gains, gift taxes eliminated.
All personal taxes taken out before you get the money, no tax forms to fill out at all unless you're self-employed.
Charitable donations dealt with by matching donations at the tax rate (so for every $100 received from individuals, receive another $45 from government, $35 for each $100 from corporations, or whatever the tax rate is), no deductions from the donors taxes obviously.
Eliminate all deductions, replace with other incentives, e.g. instead of motgage interest deduction, simply reduce the interest rate directly by providing support from the government.
Tax rate automatically adjusted based on spending, with the flat tax and VAT set to each provide 50% of the required revenue.
Blockchain embedded messages have been around for pretty much the entire history of Bitcoin.
There are proselytizing messages, random weird stuff, links to what was probably child porn (by this time, probably all dead links). I don't remember ever seeing any actual image data, that would have been a bit large to add to a block.
Even if there was, it wasn't in any format that you could view, so it would be hard to say it was an image at all. Since with enough manipulation, plus enough additional data, any chunk of bytes can be turned into any other chunk of bytes, there has to be a limit to what can be held to be "illegal" content. If it's never turned into objectionable pixels on a screen, is it even an image?
You might be able to get by with a much smaller hi-res area if it can be projected onto the retina using high speed MEMS mirrors, using the same tracking you'd already be doing.
Even if not, foveated rendering will significantly reduce GPU requirements which would enable extremely high resolutions with much wider FOV and very low latency.
I think people underestimate the potential raw resolution that would be required to have a true full FOV display that would effectively be indistinguishable from reality (not even getting into color gamut issues). With a typical resolution of about one arcminute and a FOV around 160-175, you need around 10K x 10K, but only within the central 2-5 degrees. Some people can resolve down to 20 arcseconds or so, increasing it to 30K x 30K.
With one arcminute and 2 degrees, you only need to render at 120x120 within about a millisecond, which is less than 640x480@60, so you can easily go a bit larger and higher resolution without pushing any limits. 5 degrees and 30 arcseconds in a millisecond would be close to 2560x1440@120.
Note that you don't need to render at 1000 fps, the 1 millisecond is about the latency you'd want as you track the eye, so it needs to be fast but has lower power requirements than if it was rendering continuously.
You don't even need to install XCode. Just open a terminal window and type gcc or make or some other command that's not installed by default, a prompt will come up to download and install a fairly complete command-line environment. Not a large download, doesn't take up all that much space. Now you can do C/C++, Tcl/Tk, Python, Java, PERL, awk/sed, bash, bc, etc. I think they even include units by default. That's enough to download, compile and install most source packages, or you can add various package-manager/build systems on top of it (ports and equivalent).
If you later install XCode to do GUI app programming, everything keeps on working, you just add the IDE and support for building Mac and iOS apps.
No, fractions of a second don't end up as floats. They end up as some number of smaller units of time unless you're doing it wrong. Typically you'll measure in units of milliseconds, microseconds, nanoseconds, picoseconds, depending on the accuracy of the underlying hardware clock and the number of bits you can easily work with, but measuring time as number of frames also works fine - you just convert time by multiplying and dividing.
If you use 64 bits (either as a single nanosecond value, or as a pair of 32-bit second/nanosecond values), you can measure relative time much more accurately than needed for video frame rates. A nanosecond is approximately the pixel clock for a 4K video at 120Hz.
64 bits of nanoseconds will last a bit less than 600 years. 32 bits of seconds, with nanoseconds being a second 32 bits, will last 136 years. The gettimeofday() Unix call (and others using the timeval structure) measure time in microseconds. The newer clock_gettime() calls using the timespec structure which measures time in nanoseconds. With 128 bits, you can measure time in femtoseconds and still have a range of a million billion years (or "only" 100 billion years if you use two 64-bit values and measure in attoseconds). However, for measuring elapsed time over a period under a year, you can simply use 64 bits and measure in picoseconds.
If you measure frame times in nanoseconds, you'll be off for any given frame rate by at most.5 nanoseconds per frame. Let's look at 120Hz video, the actual frame time is 8333333.33... nanoseconds. If you actually play it at 8333333 nanoseconds, after 120 frames (which should be 1 second) you'll be off by 40 nanoseconds. After about 29 minutes, you'll be off by one frame, approximately. If you instead use picoseconds (which you might as well, since you're already using more than 32 bits with either nanoseconds or Flicks for any time longer than about 4-6 seconds), you can still measure elapsed time for more than 200 days, and you'd be off by no more than 1 frame every 13 days.
However, there's nothing that says you need to play at 8333333 nanoseconds per frame. Take the frame number, divide by 120, multiply by 1000000000, and that's the specific nanosecond that frame should start playing, and you won't ever be off by more than.5 nanoseconds, which is most likely significantly more accurate than your clock.
So, unless you have a hardware clock that ticks at that rate, you'll have to convert from nanoseconds to Flicks anyway, so you really aren't saving anything (and you make it less convenient to convert to a real time duration, e.g. in seconds).
Except the whole point is to avoid needing to micro-manage everyone's income, investigate how much they have in savings and investments, regulate gift giving, and so on. With a flat tax, you don't have to do weird things with withholding when someone has multiple jobs. You just take it out, simple. Then you just pay it out as a UBI, just as simple. For anyone not running a business, you don't even need a postcard, you literally don't need to file a tax return at all.
With welfare, unemployment, disability, there are negative incentives to work. A UBI eliminates that, and eliminates the shaming of people who are unable to work, or are unable to find work. Yes, some people will be useless slugs, but anyone who is content with that probably shouldn't be working anyway. For everyone else, it will represent tremendous freedom.
What you're talking about is just another welfare scheme.
This article is about a UBI. What you're talking about isn't. U means Universal, everyone gets it with no means testing, no income testing.
The UBI is offset by higher taxes for those people with high incomes. A flat tax of 45-50%, offset by a UBI of $2000 per adult, is not regressive as a straight flat tax would be. Add in a VAT, and you're also getting taxes from people with wealth even if they have no "income" (and again, the UBI makes up for the regressive nature of a VAT).
With a UBI of $2000 per adult, $800 per dependent child, it would be possible to do with a 45-50% flat tax on all income (other than the UBI itself) and a 25% VAT, PLUS providing a Universal Health Care system.
The part you linked to is talking about FAA cooperation for unmanned aircraft sense and avoid technology (something the FAA has already been working on, search for "UAS ADS-B regulations", for example).
The part being discussed isn't showing up in the version you linked to, which is odd (it's the "as passed" text), the "enrolled" version has the relevant section (search for "Restoration Of Rules").
(d)Restoration Of Rules For Registration And Marking Of Unmanned Aircraft.—The rules adopted by the Administrator of the Federal Aviation Administration in the matter of registration and marking requirements for small unmanned aircraft (FAA-2015-7396; published on December 16, 2015) that were vacated by the United States Court of Appeals for the District of Columbia Circuit in Taylor v. Huerta (No. 15-1495; decided on May 19, 2017) shall be restored to effect on the date of enactment of this Act.
The regulations being restored only affect flight, not ownership. It also seems that those regulations can not be made more restrictive (with respect to hobby/recreational use) without additional legislation from Congress, since the original law exempting non-commercial light unmanned aircraft is still in effect, and the court case still stands. As written, this legislation ONLY restores the original exact regulations, which means the FAA can't change them.
You register once, not for each aircraft (until they get larger). You don't need to register paper airplanes under 250gm (that would be pretty much all of them), nor ones that are not remote controlled.
You're required to fly it with visual contact (direct visual, naked eye), either the actual operator or a spotter, regardless of any video or data links.
Slashdot Mirror
It isn't a Second Amendment case, it's First Amendment, very similar to Bernstein v US DoJ .
I don't see why this is even an issue. If a state wants to prevent this, they should pass their own laws, as some have done.
In most states, it is perfectly legal to make your own gun, it does not need to be registered or have a serial number, and you can't transfer it to anyone.
It isn't legal to make an undetectable gun regardless of how you make it. There are easier ways to make an untraceable gun. Putting "3-D printer files" (or CNC milling files) on the internet shouldn't be legally different from publishing a book on how to make your own gun out of stuff you can buy at the hardware store with ordinary household tools.
If someone is going to make their own illegal guns and sell them, restricting the distribution of plans, even if 3-D printers become much cheaper, easier to use, and more capable, isn't going to slow them down at all.
Restricting the plans for the parts that aren't even controlled seems even more clear.
I don't own any guns. I just think this is a dangerous precedent.
If there's no work, it's because efficiency has gone so high that very few people need to work in order to provide for all.
Rather than leave all the wealth (= control of resources) in the hands of the lucky few who ended up on top, a UBI ensures everyone can participate. There's still plenty of room for people to excel, and through hard work be rewarded. It's very much a free market idea, without the coercion of "you'll do this shitty job for low pay because we can make you miserable or dead if you don't", or the "congratulations, you were born rich, you can be a total zero and still have a great life" inequity that's an alternative.
There's a difference between "cheap government housing" and "free government housing".
Cheap government housing should still require people to pay an actual cost, it shouldn't be subsidized housing, but paid for out of each person's UBI. An argument can also be made for access to food, communication, education, libraries, health care. Some should be universal, some should be by choice to spend some of your UBI on the cheap option or spend more on a "better" option.
If someone has an addiction or mental health issue, there still might need to be some level of intervention, but I don't need you telling me what I can use my UBI for, based on your concepts of what I "should" be doing.
A UBI can be funded with a flat tax combined with a VAT, and can be gradually implemented (e.g. at 5% implementation of a 50% flat tax, 25% VAT, $2000/month UBI, you'd have a 2.5% flat income tax, pay 95% of your regular income tax, pay 1.25% VAT, receive $100/month in UBI (not taxed), receive 95% of other benefits, minimum wage reduced to 95% of original value. Raise it to 15% implementation, then 25%, then 50%, 75%, and 100% once every 2 years, tuning numbers as necessary.
Actually, it's a good way to phase in a UBI.
A $2000/month UBI, with $800 for dependent children, funded through a 45-50% flat income tax plus about 25% VAT approximately balances (includes Universal Health).
Phase in by starting with 5% and 2.5%, reducing the current income tax by the same percentage, and a UBI of $200/month; increase it each year for 10 years.
Reduce minimum wage and safety net support by the same amount.
I've always assumed the point of "blockchain technology" is that you'd commit a block of transactions, authenticated by a digital signature of whoever is attesting that the information is correct. It's "blockchain" because each new entry includes a reference to the previous entry's hash code. Each new entry locks in all the previous entries. In that sense, it's just a variant of git. If you change an earlier entry, it's made obvious because the hash code doesn't match or the signature doesn't validate, at some point in the chain.
If the entire database can be downloaded by anyone, then multiple copies of it will exist. The only thing needed to validate the entire chain is the hash code of the last entry. If that entry disappears (i.e. the hash code changes), then everyone knows that something is up, and one of the copies can be checked to see where the discrepancy is. If you want to archive a particular transaction, you can simply save the block(s) that it appears in, which proves that it existed in that form at some point in time.
The only way to change a previous entry without setting off alarms is to put in an amended entry as a new transaction.
You'd still have a normal database with all the current data, for fast lookup, but that database can be verified against the chain by anyone.
I don't know that's what people tossing around buzzwords mean, but that's how I'd use "blockchain technology". Note that it doesn't use "mining" in any sense, everything can go through one central point, the transparency comes from the publication of the chain so that at all times it can be verified. It only relies on the security of the hash code algorithm and the signing algorithm.
Depends on what time stamps you're talking about and how the files were transferred. There are many methods of transferring files that will preserve time stamps; depending on the OS and file system, not all time stamps are preserved, or time stamps on enclosing folders might leak more information than the files themselves. I was assuming that the last modified time was being preserved on files, but not necessarily other time stamps. You'd get such behavior if you used cpio to copy the files but not the directory information, for example.
Could have also been zipped before transfer, the time stamps are just how long it took to unzip and write the files. Seriously, that was a conspiracy theory? Lame...
You don't even need to update the scene more often, just go from low resolution to high resolution in that one small patch. I'd think updating the scene and doing a low resolution rendering every 8 ms would be plenty fast. If the stuff being done with ray tracing works out, the high resolution patch might even be done that way.
I'm guessing you'd do this with direct updates to groups of pixels on the screen, with no reference to a scan frequency, just how fast it takes to update 600x600 pixels.
The low resolution image does need to be there, the brain needs a target to track towards, but peripheral vision is really quite low resolution, and gets lower the farther you are from the foveal area, from around 1 pixel per minute to about 1 pixel per degree at the far edges. However, the eye can track VERY fast, so the resolution would need to be high enough not to cause tracking problems as you move towards the edge.
Foveated rendering? That would add further savings but I doubt it's practical. You would need a ridiculously low latency, I don't believe in it.
What kind of ridiculously low latency do you think you could get if you only render a 600x600 image? How long do you think it takes for a saccade to track and stabilize?
I'd imagine you'd have two rendering paths, one for a low-resolution overall image, one to track the eye and render that 600x600 image at the predicted point that the eye will be looking at in the next millisecond. Update about 1000 times per second.
Isn't blockchain with no mining just git?
Overall it sounds similar, but incredibly more complex, than a way to structure it that I was working on.
Slightly simplified, fixed Universal Income (I used 2000/month for adults, plus 800/month for dependent children), 45-50% flat tax on income, 25% VAT. Universal Health, elimination of most other forms of "welfare", elimination of minimum wage.
At the time, I just left the corporate tax structure alone. Dividends, interest, capital gains, gift taxes eliminated.
All personal taxes taken out before you get the money, no tax forms to fill out at all unless you're self-employed.
Charitable donations dealt with by matching donations at the tax rate (so for every $100 received from individuals, receive another $45 from government, $35 for each $100 from corporations, or whatever the tax rate is), no deductions from the donors taxes obviously.
Eliminate all deductions, replace with other incentives, e.g. instead of motgage interest deduction, simply reduce the interest rate directly by providing support from the government.
Tax rate automatically adjusted based on spending, with the flat tax and VAT set to each provide 50% of the required revenue.
Blockchain embedded messages have been around for pretty much the entire history of Bitcoin.
There are proselytizing messages, random weird stuff, links to what was probably child porn (by this time, probably all dead links). I don't remember ever seeing any actual image data, that would have been a bit large to add to a block.
Even if there was, it wasn't in any format that you could view, so it would be hard to say it was an image at all. Since with enough manipulation, plus enough additional data, any chunk of bytes can be turned into any other chunk of bytes, there has to be a limit to what can be held to be "illegal" content. If it's never turned into objectionable pixels on a screen, is it even an image?
You might be able to get by with a much smaller hi-res area if it can be projected onto the retina using high speed MEMS mirrors, using the same tracking you'd already be doing.
Even if not, foveated rendering will significantly reduce GPU requirements which would enable extremely high resolutions with much wider FOV and very low latency.
I think people underestimate the potential raw resolution that would be required to have a true full FOV display that would effectively be indistinguishable from reality (not even getting into color gamut issues). With a typical resolution of about one arcminute and a FOV around 160-175, you need around 10K x 10K, but only within the central 2-5 degrees. Some people can resolve down to 20 arcseconds or so, increasing it to 30K x 30K.
With one arcminute and 2 degrees, you only need to render at 120x120 within about a millisecond, which is less than 640x480@60, so you can easily go a bit larger and higher resolution without pushing any limits. 5 degrees and 30 arcseconds in a millisecond would be close to 2560x1440@120.
Note that you don't need to render at 1000 fps, the 1 millisecond is about the latency you'd want as you track the eye, so it needs to be fast but has lower power requirements than if it was rendering continuously.
Your understanding is wrong.
You don't even need to install XCode. Just open a terminal window and type gcc or make or some other command that's not installed by default, a prompt will come up to download and install a fairly complete command-line environment. Not a large download, doesn't take up all that much space. Now you can do C/C++, Tcl/Tk, Python, Java, PERL, awk/sed, bash, bc, etc. I think they even include units by default. That's enough to download, compile and install most source packages, or you can add various package-manager/build systems on top of it (ports and equivalent).
If you later install XCode to do GUI app programming, everything keeps on working, you just add the IDE and support for building Mac and iOS apps.
No, fractions of a second don't end up as floats. They end up as some number of smaller units of time unless you're doing it wrong. Typically you'll measure in units of milliseconds, microseconds, nanoseconds, picoseconds, depending on the accuracy of the underlying hardware clock and the number of bits you can easily work with, but measuring time as number of frames also works fine - you just convert time by multiplying and dividing.
If you use 64 bits (either as a single nanosecond value, or as a pair of 32-bit second/nanosecond values), you can measure relative time much more accurately than needed for video frame rates. A nanosecond is approximately the pixel clock for a 4K video at 120Hz.
64 bits of nanoseconds will last a bit less than 600 years. 32 bits of seconds, with nanoseconds being a second 32 bits, will last 136 years. The gettimeofday() Unix call (and others using the timeval structure) measure time in microseconds. The newer clock_gettime() calls using the timespec structure which measures time in nanoseconds. With 128 bits, you can measure time in femtoseconds and still have a range of a million billion years (or "only" 100 billion years if you use two 64-bit values and measure in attoseconds). However, for measuring elapsed time over a period under a year, you can simply use 64 bits and measure in picoseconds.
If you measure frame times in nanoseconds, you'll be off for any given frame rate by at most .5 nanoseconds per frame. Let's look at 120Hz video, the actual frame time is 8333333.33... nanoseconds. If you actually play it at 8333333 nanoseconds, after 120 frames (which should be 1 second) you'll be off by 40 nanoseconds. After about 29 minutes, you'll be off by one frame, approximately. If you instead use picoseconds (which you might as well, since you're already using more than 32 bits with either nanoseconds or Flicks for any time longer than about 4-6 seconds), you can still measure elapsed time for more than 200 days, and you'd be off by no more than 1 frame every 13 days.
However, there's nothing that says you need to play at 8333333 nanoseconds per frame. Take the frame number, divide by 120, multiply by 1000000000, and that's the specific nanosecond that frame should start playing, and you won't ever be off by more than .5 nanoseconds, which is most likely significantly more accurate than your clock.
So, unless you have a hardware clock that ticks at that rate, you'll have to convert from nanoseconds to Flicks anyway, so you really aren't saving anything (and you make it less convenient to convert to a real time duration, e.g. in seconds).
Except the whole point is to avoid needing to micro-manage everyone's income, investigate how much they have in savings and investments, regulate gift giving, and so on. With a flat tax, you don't have to do weird things with withholding when someone has multiple jobs. You just take it out, simple. Then you just pay it out as a UBI, just as simple. For anyone not running a business, you don't even need a postcard, you literally don't need to file a tax return at all.
With welfare, unemployment, disability, there are negative incentives to work. A UBI eliminates that, and eliminates the shaming of people who are unable to work, or are unable to find work. Yes, some people will be useless slugs, but anyone who is content with that probably shouldn't be working anyway. For everyone else, it will represent tremendous freedom.
What you're talking about is just another welfare scheme.
This article is about a UBI. What you're talking about isn't. U means Universal, everyone gets it with no means testing, no income testing.
The UBI is offset by higher taxes for those people with high incomes. A flat tax of 45-50%, offset by a UBI of $2000 per adult, is not regressive as a straight flat tax would be. Add in a VAT, and you're also getting taxes from people with wealth even if they have no "income" (and again, the UBI makes up for the regressive nature of a VAT).
With a UBI of $2000 per adult, $800 per dependent child, it would be possible to do with a 45-50% flat tax on all income (other than the UBI itself) and a 25% VAT, PLUS providing a Universal Health Care system.
The part you linked to is talking about FAA cooperation for unmanned aircraft sense and avoid technology (something the FAA has already been working on, search for "UAS ADS-B regulations", for example).
The part being discussed isn't showing up in the version you linked to, which is odd (it's the "as passed" text), the "enrolled" version has the relevant section (search for "Restoration Of Rules").
(d)Restoration Of Rules For Registration And Marking Of Unmanned Aircraft.—The rules adopted by the Administrator of the Federal Aviation Administration in the matter of registration and marking requirements for small unmanned aircraft (FAA-2015-7396; published on December 16, 2015) that were vacated by the United States Court of Appeals for the District of Columbia Circuit in Taylor v. Huerta (No. 15-1495; decided on May 19, 2017) shall be restored to effect on the date of enactment of this Act.
The regulations being restored only affect flight, not ownership. It also seems that those regulations can not be made more restrictive (with respect to hobby/recreational use) without additional legislation from Congress, since the original law exempting non-commercial light unmanned aircraft is still in effect, and the court case still stands. As written, this legislation ONLY restores the original exact regulations, which means the FAA can't change them.
If it restores the regulations that were struck down, no, it only requires registration if it's flown, and the FAA has no jurisdiction indoors.
I don't see the specific language referring to this in what you linked, where does it say "do something"?
You register once, not for each aircraft (until they get larger). You don't need to register paper airplanes under 250gm (that would be pretty much all of them), nor ones that are not remote controlled.
You're required to fly it with visual contact (direct visual, naked eye), either the actual operator or a spotter, regardless of any video or data links.
As long as you don't fly it outside, you don't have to register.