Yeah, they *talked* about it, but that did not happen. No one wanted to be the fellow who wanted to throw their state's votes against the will of their voters. They wanted to grumble about what a terrible thing it was, but not actually have any consequences of those thoughts.
Much of the time, the revenue that the city 'loses' is revenue that otherwise wouldn't exist. A company either would pay, say 20 million in taxes under 'normal' rules, but arrange to only pay 3 million, it is said they 'gave' them 17 million dollars. However the alternative for the city was not 20 million, it was 0 (or maybe from alternative taxpayers, but for many of these places they got enough empty space that amazon does not exactly bump other more profitable companies out.
On top of the employment and immediately indirect benefits that the politicians like to tout, it's also a rationalization to get some public works spending through. I know that at least one of those metropolitan areas has been trying for many years to build some sane transit improvements, but the citizens never have the stomach and would rather sit in traffic two hours a day than see money spent to improve it. Amazon can become the justification to spend money on those projects.
Of course, this is all hugely unfair still and favors big businesses with leverage and is another way that economic power gets focused to a handful of leaders at a handful of companies. The consequences of capitalism exacerbated by technology that facilitates really fast information travel and logistics to make it feasible to consolidate to gigantic powerful companies that grind all competition to dust.
It can also be greatly disappointing. There was a small town that agreed basically to let a big datacenter take of residence basically without paying any taxes whatsoever, and in very real terms went into the red building infrastructure required by the company to make the deal. It was admittedly great for the construction companies in the short term, but as soon as everything was built, they became upset because that gigantic facility under normal conditions had maybe a dozen employees. They were imagining in their heads what a textile plant of that size would hire 30 years ago and instead got to be the suckers that happen to have a big datacenter that contributes nothing to the employment or economy of the area.
It wouldn't say "oh yeah, totally secure", but instead say "here's some data, and it's not particularly protected" much like it does for http today, but without the excessively scary "this site is insecure and going to steal from you!", click advanced, click add exemption, click yes I'm sure, click add to exemption list" or whatever dance. But instead maybe just say "this local site cannot have it's security verified, click to continue". Something less obnoxious, but still not going to be a viable channel for phishing..
-http:// should be at least as scary as self-signed cert, because a large contingent of users have no idea about the significance of that part of the url because they never had need to understand -If contending with a legitimately global domain name (even if it resolves to a private address) or globally valid ip, then let fly with the paranoid messages -If contending with 192.168/16, 172.16/12, or 10/8 (literally in the url given, not based on what DNS might resolve to), or a name that ends in.local or.test, behave more like ssh (that prompts, but makes it super easy to store that exemption). Firefox comes closest, but it nags you like crazy, it should be a single button that says 'add and continue'. Could also add fd::/8 to the list, though I'm doubtful that many folks are using IPv6 by ip in a browser url for 'quick and dirty' access to something.
There is a large part of the browser using population that never bothered to understand the significance of the url. Back 20 years ago, it was a pretty fundamental concept to know, nowadays they are hidden behind links, no one ever *types* https (they just hit a domain or google search), and url shorteners in twitter have trained people that urls are indecipherable. They even *hide* http:/// portion of url if not https:/// so that opens the door of hiding https:/// portion of url if the url is insecure.
I was saying specifically that browsers when they see '192.168.' or 'example.local' in https,, they should treat things differently, which would be home user.
Enterprises wanting to meaningfully protect '192.168' addresses would issue certs of their own domain (since certs don't care about IP, but about what is in the url). Even if that domain resolves to 192.168, it would not receive particularly different treatment so long as a normal looking dns name were used to specify it.
The question is what domain those embedded boxes are serving. You said yourself, they are never exposed to the internet. So if you *really* need to, you can add a reverse proxy that adds https to the session, with the endpoint being none the wiser. Also if they are never exposed to the internet, using a public CA certificate makes no sense, use a private one deployed to your employee systems. You can control expiry and all that. Or just let the insecure cert roll and use a browser like firefox that will store the exemption rather than requiring the gymnastics of having a CA certificate and managing all that stuff.
Of course, you may not need to, since this only applies to 'new features', which are not things that these devices (or even most web developers in general) will use.
Certificates from a technical perspective can facilitate a superset of key exchange strategies. The whole chaining to a third party down to a small root of public CAs is the sole feature focused on by some browsers, but ssh-style public key blessing is completely possible (and firefox at least manifests this as storing an exemption).
Or to treat private network ips or reserved dns different when it comes to the scary insecure dialogs that the user sees, even if it is still using https but cannot possibly validate a certificate. The key would be the text in the url, not the address so that enterprises can still manage meaningful certificates for RFC 1918 ip addresses.
As it stands, using https without a viable certificate means the user gets scared far more than just doing http. Treating private names/ip addresses running https more like http (no padlock, warnings on all form inputs about insecure submissions, etc) might not be so unreasonable
It is a valid point that https on embedded devices and for unmanaged local networks is pretty awkward, with no one really stepping up to make that use case a bit more friendly (even if it can't be made secure).
It's of course very weird that browsers treat unvalidated https as *worse* than http, in terms of scaring the user.
From a technical perspective and rational standpoint, that would seem the best course.
From a realistic business perspective, making cost of entry low, and then charging $60 per game works better. People are reluctant to say fork over 500 or 600 dollars in one go, but they will end up spending far more than that over the course of a few months if you hit them a chunk at a time.
Furthermore, for those homebrew things, if we are being honest with ourselves there are a plethora of products on the market that let you more easily access. the platform and cost about the same. Sure, the physical controller design is very nice as is the dock, but 7" tablets with approximately that much horsepower, HDMI out, and available bluetooth physical controllers exist.
The industrial design is certainly nicer and the way the controllers physically reconfigure is nice, but the big thing for Switch is the games. The Wii-U suffered from not getting games out, a confusing name, and a design that awkwardly combined the TV and the tablet and suggested games should use both screens at the same time, but only for one player having tablet screen and other players only using the TV.
I will say the async model frequently leads to a mess that's hard for most developers to wade through. It's ok when the flows have one or two step interactions, but as a flow involving IO gets more involved, it devolves to an indecipherable mess.
Pretty much this is the key issue. If Javascript and the browser runtime in general is really so flawed, then steps need to be taken to advance the runtime, rather than making the site code more and more bloated.
Either the state of browser runtime needs to advance or developers need to learn to work better with the hand they are given. The answer is likely in the middle.
This is essentially saying "yes, they have changed every six months, but *this* six month flavor is here to stay!".
Note that at every changing of the guard, a month later there are a lot of people eager to explain why *this* time is different and the change will endure, unlike all those previous flashes in the pan before it. Six months from now we will have people explaing how Vue and React were ultimately flawed concepts somehow and how *new* framework brings enduring sanity to the world.
Nexus supports NPM so this is an irrelevant problem.
No, npm is a a manifestation of the problem, the cause is developers looking to offload to upstream for efficiency, and continually assuming that upstream is 100% reliable every time.
In my search to explore your comments, the react page touting the vritaul DOM: "BTW. I myself managed to create a web page with a source of 5GB+. It wasn’t even that hard.
Consider a DOM made of thousands of divs. Remember, we are modern web developers, our app is very SPA! "
These are huge warning signs that the developer has an issue, regardless of whether the environment can handle it.
All that aside, I think the virtual DOM will be regarded in the near future as a needless over complication. It's trying to workaround a problem that will probably not be a problem a year or so from now. Most of the other facets are either quite sanely doable from Javascript, or else not a concept that you really need and you may be doing your users and fellow web developers a disservice by being overly fancy with something. Using Javascript without a framework is not rolling your own framework.
This is a good reason for web developers to be trained:
First and foremost, be mindful of HTML and use it correctly. Doing this fairly simple thing improves experience greatly, and renders accessibility easy.
Next up, up you want to be fancy, CSS can do almost all the sane visual sprucing up you can imagine, and can play nicely with accessibility.
If you have a need for Javascript, first consider what the language/runtime can do without a framework. This keeps your application a bit more straightforward to debug.
Framework should be the last resort.
Circumstances don't always allow for the no javascript way, but there are more tools than folks realize. For one site, others in my team were pushing for a bloated CMS that messes with daatabses on the fly server side and assembles the pages using javascript in the browser. I ultimately won that one and the site uses Jekyll and no javascript.
Yes, and as such, any scenario which should rationally tie the two things together should come together as one bill, rather than passing the very nice sounding bill first, thereby forcing your own hand to do the unpopular thing (and ultimately timing it conveniently around election years, in the hopes that the bad part *looks* like the fault of your opponents).
Tank tax revenue, then come in and say "oh look, we can't afford welfare, well shucks, guess we have to gut it".
Or conversely, "yay, dispersing money to everyone!", way to go" then "oh look, we are low on money, well shucks, guess we have to raise taxes" if that's your political leaning.
Any high profile politician that shows some outward signs of contending with nuance and compromise gets eviscerated in the general election by politicians pandering to the easy answers and painting the nuanced approach as weak and inconsistent with some simplistic party lne. So we end up hoping that for the sake of the government that the politician running is lying to make themselves look dumber and will conduct themselves with some degree of intelligence in office.
You have a married couple with one child. This means one child tax credit, 3 exemptions, and standard deduction of about 12k (formerly).
Let's say you previously could itemize to deduct 14k. So you take that plus your exemptions and you deduct a total of 26k. Child tax credit of 1k on top of that. A family of 4 would have deducted 30k, or 28k if it were the standard deduction.
Now under the new plan, the standard deduction is now 24k, which is well more than the 14k you could have deducted before, so you'll take that. However, in exchange for that bump, those personal exemptions go away. So your deduction is only 24k versus the 26k the previous year, and for the larger family, it goes from 28k-30k down to 24k.
Of course, the child tax credit doubles, which means that at least for children, the tax credit doubling is indeed worth more than the loss of the exemption. Of course if your exemptions include more than 1 adult for single or more than 3 total adults if married, you will see a big tax hike.
Really the big headline is that there is a lot of moving stuff around to sound impressive, without really changing the personal income tax for most people (except notably people contending with supporting extended families who are screwed in the deal). The only unambiguous winners are entities paying corporate taxes, which would be ok, except for that pesky huge hike in the deficit.
In trial runs of UBI, the participants know that the trial will end. So if *hypothetically* people would go lazy secure in the knowledge they will have a UBI, this won't prove anything as they won't be that secure in the income.
A negative result would be really discouraging, a positive result would be too ambiguous.
Many folks who itemized deductions will pay more. The standard deduction doubles, eclipsing the reason for most people to itemize, and that *sounds* good.
Except if your were a household of three or more, you are giving up exemptions. So before if you could itemize beyond 12k, you would be able to deduct more than 24k, since your itemized deductions combined with your exemptions pushed things over. The doubling of the standardized deductions render those itemized deductions moot. If you took standard anyway, it's a wash if it's 3, and worse if you have more, *deduction* wise.
If your dependents are kids, the doubling of that tax credit is likely to make up for any downsides and then some. If you have adult dependents... well you are screwed.
For me, it *should* in the long run be a little better (though my withholding actually increased a shade), at least for the temporary interval.
For single parents and parents of 2 or more kids, unless they know to go rework their withholding, they will probably be blindsided by increased withholding, though they will have big refunds unless they fix that. The old W4s didn't give the companies enough info to accurately set withholding. There is a chance they make an educated guess about exemptions as to whether they are children, but that could lead to another problem.
For folks with any dependent adults in their household that they are not married to, they lose exemptions and no child tax credit to make up for it. If a company mistakenly assumes adult dependents are children and set withholding accordingly, they will be in for a particulary nasty surprise come filing time. Either way, it's a bad tax plan for having an adult dependent.
The biggest problems are: -It's a shell game with the rates and standard deduction versus exemptions that end up with personal income taxes being about the same, despite all the rhetoric -All those shenanigans were an excuse to pass a rather gigantic and meangingful corporate tax cut -Signing up for a reduction of revenue to the tune of 1.5 trillion without any certainty of spending cuts is not exactly a fiscally responsible move. It's making things far worse, and then after making the mess using it as an excuse to go after medicare, medicaid, food stamps, and other 'entitlements', which will *really* hurt the lower class. If they had explicitly put those sorts of spending cuts as part of the tax bill, it wouldn't have passed, which says something about how obviously unpopular such a concept would be.
Sadly I don't have a citation, but I am told at least one of the ARM vendors took a similar optimization and as a result is in the same boat as Intel with respect to meltdown.
The story has been 'intel v. amd' but there are a lot of other players out there.
The optimization on the face of it doesn't seem *that* obvious of a bad idea: do the access check only if the result would issue, and in all cases you flush the obvious access points. The fact that something that is still inaccessible is in cache and not in main memory was not quite as obvious a threat as people like to pretend.
I don't think it requires all human vehicles to be out of the loop even to improve traffic flow (if it can improve traffic flow).
Autonomous cars must not require transponders for safe action. Even ignoring the bicycle problem. The other day there was someone pulled off to the side of the road working on their car. On the face of it, one could say he's safely out of the roadway so don't need to worry. However, he was clearly straining pulling on something with all his weight, his back to the road. So everyone did slow down and when that thing he was pulling on gave way, he fell backwards into the road, so it was a god thing the drivers were picking up on the consequence of a guy putting all his weight into pulling on something and knowing what happens when that succeeds. This is also something that doesn't play well into the ML strategy for training cars, because in over 20 years of driving, that's the one and only time I can recall seeing that situation, and you need large amounts of data to overcome the general dumbness of machine vision.
See that's getting way ahead of ourselves. It's not currently legal for full-on autonomous vehicle without a licensed operator able to intervene.
Additionally, such a product is needlessly curbing the viable market. People who want to dip their toes in but have reassurance of being able to take the wheel are going to be the overwhelming market for autonomous cars.
It may become a valuable thing to do if, say, laws emerge that allow people who cannot have a license to be the sole passenger in a vehicle, so long as it does not have any controls to allow manual intervention. At this stage it's just saying things to sound on top of the cutting edge even if it doesn't make practical sense yet.
Note all of this is completely independent on the *techincal* situation of whether this is feasible or not, this is *just* the human/regulatory factor surrounding it.
Even as networks have improved, remote graphical interaction has continued to suck royally due to at least the latency, if not generally the compression artifacts and general reliability issues.
Over the years I tried that again and again as I had access to servers with hundreds of GB of ram, 64 cores, but it just wasn't the same.
Now I have a 20 core workstation with 64 GB of ram and couldn't be happier.
The disk content I use seafile to synchronize, and I'm grateful for the server in that regard, but for running GUI applications, I just can't stand it.
Slashdot Mirror
Yeah, they *talked* about it, but that did not happen. No one wanted to be the fellow who wanted to throw their state's votes against the will of their voters. They wanted to grumble about what a terrible thing it was, but not actually have any consequences of those thoughts.
It is complicated.
Much of the time, the revenue that the city 'loses' is revenue that otherwise wouldn't exist. A company either would pay, say 20 million in taxes under 'normal' rules, but arrange to only pay 3 million, it is said they 'gave' them 17 million dollars. However the alternative for the city was not 20 million, it was 0 (or maybe from alternative taxpayers, but for many of these places they got enough empty space that amazon does not exactly bump other more profitable companies out.
On top of the employment and immediately indirect benefits that the politicians like to tout, it's also a rationalization to get some public works spending through. I know that at least one of those metropolitan areas has been trying for many years to build some sane transit improvements, but the citizens never have the stomach and would rather sit in traffic two hours a day than see money spent to improve it. Amazon can become the justification to spend money on those projects.
Of course, this is all hugely unfair still and favors big businesses with leverage and is another way that economic power gets focused to a handful of leaders at a handful of companies. The consequences of capitalism exacerbated by technology that facilitates really fast information travel and logistics to make it feasible to consolidate to gigantic powerful companies that grind all competition to dust.
It can also be greatly disappointing. There was a small town that agreed basically to let a big datacenter take of residence basically without paying any taxes whatsoever, and in very real terms went into the red building infrastructure required by the company to make the deal. It was admittedly great for the construction companies in the short term, but as soon as everything was built, they became upset because that gigantic facility under normal conditions had maybe a dozen employees. They were imagining in their heads what a textile plant of that size would hire 30 years ago and instead got to be the suckers that happen to have a big datacenter that contributes nothing to the employment or economy of the area.
It wouldn't say "oh yeah, totally secure", but instead say "here's some data, and it's not particularly protected" much like it does for http today, but without the excessively scary "this site is insecure and going to steal from you!", click advanced, click add exemption, click yes I'm sure, click add to exemption list" or whatever dance. But instead maybe just say "this local site cannot have it's security verified, click to continue". Something less obnoxious, but still not going to be a viable channel for phishing..
My suggestion:
-http:// should be at least as scary as self-signed cert, because a large contingent of users have no idea about the significance of that part of the url because they never had need to understand .local or .test, behave more like ssh (that prompts, but makes it super easy to store that exemption). Firefox comes closest, but it nags you like crazy, it should be a single button that says 'add and continue'. Could also add fd::/8 to the list, though I'm doubtful that many folks are using IPv6 by ip in a browser url for 'quick and dirty' access to something.
-If contending with a legitimately global domain name (even if it resolves to a private address) or globally valid ip, then let fly with the paranoid messages
-If contending with 192.168/16, 172.16/12, or 10/8 (literally in the url given, not based on what DNS might resolve to), or a name that ends in
There is a large part of the browser using population that never bothered to understand the significance of the url. Back 20 years ago, it was a pretty fundamental concept to know, nowadays they are hidden behind links, no one ever *types* https (they just hit a domain or google search), and url shorteners in twitter have trained people that urls are indecipherable. They even *hide* http:/// portion of url if not https:/// so that opens the door of hiding https:/// portion of url if the url is insecure.
I was saying specifically that browsers when they see '192.168.' or 'example.local' in https,, they should treat things differently, which would be home user.
Enterprises wanting to meaningfully protect '192.168' addresses would issue certs of their own domain (since certs don't care about IP, but about what is in the url). Even if that domain resolves to 192.168, it would not receive particularly different treatment so long as a normal looking dns name were used to specify it.
The question is what domain those embedded boxes are serving. You said yourself, they are never exposed to the internet. So if you *really* need to, you can add a reverse proxy that adds https to the session, with the endpoint being none the wiser. Also if they are never exposed to the internet, using a public CA certificate makes no sense, use a private one deployed to your employee systems. You can control expiry and all that. Or just let the insecure cert roll and use a browser like firefox that will store the exemption rather than requiring the gymnastics of having a CA certificate and managing all that stuff.
Of course, you may not need to, since this only applies to 'new features', which are not things that these devices (or even most web developers in general) will use.
Certificates from a technical perspective can facilitate a superset of key exchange strategies. The whole chaining to a third party down to a small root of public CAs is the sole feature focused on by some browsers, but ssh-style public key blessing is completely possible (and firefox at least manifests this as storing an exemption).
Or to treat private network ips or reserved dns different when it comes to the scary insecure dialogs that the user sees, even if it is still using https but cannot possibly validate a certificate. The key would be the text in the url, not the address so that enterprises can still manage meaningful certificates for RFC 1918 ip addresses.
As it stands, using https without a viable certificate means the user gets scared far more than just doing http. Treating private names/ip addresses running https more like http (no padlock, warnings on all form inputs about insecure submissions, etc) might not be so unreasonable
He did mention explicitly private addresses.
It is a valid point that https on embedded devices and for unmanaged local networks is pretty awkward, with no one really stepping up to make that use case a bit more friendly (even if it can't be made secure).
It's of course very weird that browsers treat unvalidated https as *worse* than http, in terms of scaring the user.
From a technical perspective and rational standpoint, that would seem the best course.
From a realistic business perspective, making cost of entry low, and then charging $60 per game works better. People are reluctant to say fork over 500 or 600 dollars in one go, but they will end up spending far more than that over the course of a few months if you hit them a chunk at a time.
Furthermore, for those homebrew things, if we are being honest with ourselves there are a plethora of products on the market that let you more easily access. the platform and cost about the same. Sure, the physical controller design is very nice as is the dock, but 7" tablets with approximately that much horsepower, HDMI out, and available bluetooth physical controllers exist.
The industrial design is certainly nicer and the way the controllers physically reconfigure is nice, but the big thing for Switch is the games. The Wii-U suffered from not getting games out, a confusing name, and a design that awkwardly combined the TV and the tablet and suggested games should use both screens at the same time, but only for one player having tablet screen and other players only using the TV.
I will say the async model frequently leads to a mess that's hard for most developers to wade through. It's ok when the flows have one or two step interactions, but as a flow involving IO gets more involved, it devolves to an indecipherable mess.
Pretty much this is the key issue. If Javascript and the browser runtime in general is really so flawed, then steps need to be taken to advance the runtime, rather than making the site code more and more bloated.
Either the state of browser runtime needs to advance or developers need to learn to work better with the hand they are given. The answer is likely in the middle.
This is essentially saying "yes, they have changed every six months, but *this* six month flavor is here to stay!".
Note that at every changing of the guard, a month later there are a lot of people eager to explain why *this* time is different and the change will endure, unlike all those previous flashes in the pan before it. Six months from now we will have people explaing how Vue and React were ultimately flawed concepts somehow and how *new* framework brings enduring sanity to the world.
Nexus supports NPM so this is an irrelevant problem.
No, npm is a a manifestation of the problem, the cause is developers looking to offload to upstream for efficiency, and continually assuming that upstream is 100% reliable every time.
In my search to explore your comments, the react page touting the vritaul DOM:
"BTW. I myself managed to create a web page with a source of 5GB+. It wasn’t even that hard.
Consider a DOM made of thousands of divs. Remember, we are modern web developers, our app is very SPA! "
These are huge warning signs that the developer has an issue, regardless of whether the environment can handle it.
All that aside, I think the virtual DOM will be regarded in the near future as a needless over complication. It's trying to workaround a problem that will probably not be a problem a year or so from now. Most of the other facets are either quite sanely doable from Javascript, or else not a concept that you really need and you may be doing your users and fellow web developers a disservice by being overly fancy with something. Using Javascript without a framework is not rolling your own framework.
This is a good reason for web developers to be trained:
First and foremost, be mindful of HTML and use it correctly. Doing this fairly simple thing improves experience greatly, and renders accessibility easy.
Next up, up you want to be fancy, CSS can do almost all the sane visual sprucing up you can imagine, and can play nicely with accessibility.
If you have a need for Javascript, first consider what the language/runtime can do without a framework. This keeps your application a bit more straightforward to debug.
Framework should be the last resort.
Circumstances don't always allow for the no javascript way, but there are more tools than folks realize. For one site, others in my team were pushing for a bloated CMS that messes with daatabses on the fly server side and assembles the pages using javascript in the browser. I ultimately won that one and the site uses Jekyll and no javascript.
Yes, and as such, any scenario which should rationally tie the two things together should come together as one bill, rather than passing the very nice sounding bill first, thereby forcing your own hand to do the unpopular thing (and ultimately timing it conveniently around election years, in the hopes that the bad part *looks* like the fault of your opponents).
Tank tax revenue, then come in and say "oh look, we can't afford welfare, well shucks, guess we have to gut it".
Or conversely, "yay, dispersing money to everyone!", way to go" then "oh look, we are low on money, well shucks, guess we have to raise taxes" if that's your political leaning.
Any high profile politician that shows some outward signs of contending with nuance and compromise gets eviscerated in the general election by politicians pandering to the easy answers and painting the nuanced approach as weak and inconsistent with some simplistic party lne. So we end up hoping that for the sake of the government that the politician running is lying to make themselves look dumber and will conduct themselves with some degree of intelligence in office.
You have a married couple with one child. This means one child tax credit, 3 exemptions, and standard deduction of about 12k (formerly).
Let's say you previously could itemize to deduct 14k. So you take that plus your exemptions and you deduct a total of 26k. Child tax credit of 1k on top of that. A family of 4 would have deducted 30k, or 28k if it were the standard deduction.
Now under the new plan, the standard deduction is now 24k, which is well more than the 14k you could have deducted before, so you'll take that. However, in exchange for that bump, those personal exemptions go away. So your deduction is only 24k versus the 26k the previous year, and for the larger family, it goes from 28k-30k down to 24k.
Of course, the child tax credit doubles, which means that at least for children, the tax credit doubling is indeed worth more than the loss of the exemption. Of course if your exemptions include more than 1 adult for single or more than 3 total adults if married, you will see a big tax hike.
Really the big headline is that there is a lot of moving stuff around to sound impressive, without really changing the personal income tax for most people (except notably people contending with supporting extended families who are screwed in the deal). The only unambiguous winners are entities paying corporate taxes, which would be ok, except for that pesky huge hike in the deficit.
In trial runs of UBI, the participants know that the trial will end. So if *hypothetically* people would go lazy secure in the knowledge they will have a UBI, this won't prove anything as they won't be that secure in the income.
A negative result would be really discouraging, a positive result would be too ambiguous.
Many folks who itemized deductions will pay more. The standard deduction doubles, eclipsing the reason for most people to itemize, and that *sounds* good.
Except if your were a household of three or more, you are giving up exemptions. So before if you could itemize beyond 12k, you would be able to deduct more than 24k, since your itemized deductions combined with your exemptions pushed things over. The doubling of the standardized deductions render those itemized deductions moot. If you took standard anyway, it's a wash if it's 3, and worse if you have more, *deduction* wise.
If your dependents are kids, the doubling of that tax credit is likely to make up for any downsides and then some. If you have adult dependents... well you are screwed.
For me, it *should* in the long run be a little better (though my withholding actually increased a shade), at least for the temporary interval.
For single parents and parents of 2 or more kids, unless they know to go rework their withholding, they will probably be blindsided by increased withholding, though they will have big refunds unless they fix that. The old W4s didn't give the companies enough info to accurately set withholding. There is a chance they make an educated guess about exemptions as to whether they are children, but that could lead to another problem.
For folks with any dependent adults in their household that they are not married to, they lose exemptions and no child tax credit to make up for it. If a company mistakenly assumes adult dependents are children and set withholding accordingly, they will be in for a particulary nasty surprise come filing time. Either way, it's a bad tax plan for having an adult dependent.
The biggest problems are:
-It's a shell game with the rates and standard deduction versus exemptions that end up with personal income taxes being about the same, despite all the rhetoric
-All those shenanigans were an excuse to pass a rather gigantic and meangingful corporate tax cut
-Signing up for a reduction of revenue to the tune of 1.5 trillion without any certainty of spending cuts is not exactly a fiscally responsible move. It's making things far worse, and then after making the mess using it as an excuse to go after medicare, medicaid, food stamps, and other 'entitlements', which will *really* hurt the lower class. If they had explicitly put those sorts of spending cuts as part of the tax bill, it wouldn't have passed, which says something about how obviously unpopular such a concept would be.
Sadly I don't have a citation, but I am told at least one of the ARM vendors took a similar optimization and as a result is in the same boat as Intel with respect to meltdown.
The story has been 'intel v. amd' but there are a lot of other players out there.
The optimization on the face of it doesn't seem *that* obvious of a bad idea: do the access check only if the result would issue, and in all cases you flush the obvious access points. The fact that something that is still inaccessible is in cache and not in main memory was not quite as obvious a threat as people like to pretend.
I don't think it requires all human vehicles to be out of the loop even to improve traffic flow (if it can improve traffic flow).
Autonomous cars must not require transponders for safe action. Even ignoring the bicycle problem. The other day there was someone pulled off to the side of the road working on their car. On the face of it, one could say he's safely out of the roadway so don't need to worry. However, he was clearly straining pulling on something with all his weight, his back to the road. So everyone did slow down and when that thing he was pulling on gave way, he fell backwards into the road, so it was a god thing the drivers were picking up on the consequence of a guy putting all his weight into pulling on something and knowing what happens when that succeeds. This is also something that doesn't play well into the ML strategy for training cars, because in over 20 years of driving, that's the one and only time I can recall seeing that situation, and you need large amounts of data to overcome the general dumbness of machine vision.
now gone
See that's getting way ahead of ourselves. It's not currently legal for full-on autonomous vehicle without a licensed operator able to intervene.
Additionally, such a product is needlessly curbing the viable market. People who want to dip their toes in but have reassurance of being able to take the wheel are going to be the overwhelming market for autonomous cars.
It may become a valuable thing to do if, say, laws emerge that allow people who cannot have a license to be the sole passenger in a vehicle, so long as it does not have any controls to allow manual intervention. At this stage it's just saying things to sound on top of the cutting edge even if it doesn't make practical sense yet.
Note all of this is completely independent on the *techincal* situation of whether this is feasible or not, this is *just* the human/regulatory factor surrounding it.
Even as networks have improved, remote graphical interaction has continued to suck royally due to at least the latency, if not generally the compression artifacts and general reliability issues.
Over the years I tried that again and again as I had access to servers with hundreds of GB of ram, 64 cores, but it just wasn't the same.
Now I have a 20 core workstation with 64 GB of ram and couldn't be happier.
The disk content I use seafile to synchronize, and I'm grateful for the server in that regard, but for running GUI applications, I just can't stand it.