I'm having trouble with the demo... registration and login flows both end in a screen that says "Select a Kyri service Manager account to login" but has no list of accounts. Email in profile if you don't want to troubleshoot this publicly.
1,241 karma · joined November 30, 2012
import base64 base64.b64decode('c3RlcGhlbnMuanNAZ21haWwuY29t')
Assuming I've got that right, do you know ballpark how badly the tax inefficiency hurts you relative to ETFs? (assuming a taxable account of course, doesn't matter in a 401k or IRA)
The method that GAAP chooses is to move the $9B from cash to goodwill (assuming a cash transaction), which is a transfer from one type of asset to another. The alternative that I think you're suggesting is to move it from cash to expenses for the period in question. There's not necessarily a right answer to this question, accounting conventions are subjective, but I think most people think that the market premium you pay in an acquisition is more like acquiring an asset that will yield future business profits than an expense which, now that you've paid it, will have no future utility to the business. And it's easy enough to look at it the other way if you care to: the goodwill is reported in the balance sheet, and the cash flow statement shows the huge outlay of cash.
Of the ones with details listed it seems most of them require intent to defraud or something similar in addition to possession of personal information. I think paying for the info could also be problematic, there are a few trafficking laws in that list.
In a similar vein, possession of the info with the intent to use it to hack into something would probably run afoul of the CFAA or other anti-hacking laws.
If you collect that info with the intent to submit it to haveibeenpwned I think you would probably be fine.
If you collect that info just for fun, but don't do anything with it, I suspect that's legal, but probably not well-advised, as I suspect cops/prosecutors/jurors would have trouble believing someone did that for fun, and would interpret it as evidence that you were up to something nefarious.
I don't think the stolen property angle is an issue. Digital information can't really be stolen: usually the problem is you've committed a copyright violation. In the US at least I doubt user names and passwords would qualify for copyright protection. (Generally, collections of facts do not qualify.)
Passports have an rfid chip inside them that does something like receive a challenge and respond with a signature over a hash of the passports biographical data combined with the challenge, along with the public key corresponding to the signing key, and a certificate signed by a government key to confirm the signing key is legit.
The government public keys are published, so anybody can verify that someone who claims to have possession of a particular passport really does. The weak point is that as far as I can tell the revocation list is not public, so you can't distiguish between a stolen and not stolen passport.
For single-file-no-project simplicity your best bet is dotnet-script: https://github.com/filipw/dotnet-script
For native code your best bet is NativeAOT: https://github.com/dotnet/runtimelab/tree/feature/NativeAOT
I'm not aware of anything that combines the two.
As to why: it's not so much that they've made it hard as they haven't made it easy. The reason they haven't made it easy is that it's a fringe use case. The main benefits of AOT are faster startup time, smaller storage requirements, and compliance with the iOS interpreted language ban. Most people who worry about those things don't mind having a project file.
They _have_ made some changes that may partly address your concerns. Visual Studio is no longer required to build C#; you can do it purely from the command line. There is also a new project file format. It's still XML, but much simpler. The HelloWorld example[0] from NativeAOT is a good example of how simple it can get. And the command line tools include an easy way of creating basic project files[1], so you don't have to memorize what little boilerplate remains.
[0] https://github.com/dotnet/runtimelab/tree/feature/NativeAOT/...
[1] https://docs.microsoft.com/en-us/dotnet/core/tools/dotnet-ne...
So if you haven't tried it, beware. If you HAVE tried it, what model is working well for you?
I would expect that getting rid of dependency injection would allow you to convert a virtual method call to a direct method call, and replace a constructor argument with a static field reference, but I don't see the connection to allocation.
Anybody understand this?
That said, in my experience it's very hard to get performance gains through inlining in C# because the compiler is very conservative about what it will inline, even if you instruct it to aggressively inline a method (there is no way to force inlining in C#). IIRC this was a conscious decision by the C# team after they did some experiments and found that the benefit of fewer function calls from inlining was outweighed by the negative impact of increased code size on the instruction cache hit rate in all but the most trivial functions.
That decision makes it very hard to get some of the huge inlining wins that you see sometimes in C++ where essentially the compiler can recognize that once you recursively inline a few layers of abstraction you're in a special case that is known at compile time and a ton of code can be eliminated.
With that kind of situation off the table, a virtual method call that always goes to the same implementation will not cost you very much compared to directly calling the implementation method. It amounts to the difference between a branch and an indirect branch in machine code, and modern hardware has indirect branch predictors that will do a very good job when the indirect branch always goes to the same implementation.
I believe it's still being litigated, so the legality hasn't been firmly established yet.
Again, no. The cap was in place before the floor, but was never binding: they did blackouts before the price hit the maximum, not after.
> As rolling blackouts where implemented by people paying wholesale rates they obviously have an incentive for excessive blackouts
The decision to do blackouts was made by ERCOT, not by transmission operators or power retailers. (Retailers are the only ones who have an incentive to do blackouts, though transmitters generally also have a retail operation.)
Not true.
Early in the crisis so much generation capacity went offline that there was no way that that it could meet all of the price-insensitive demand (most consumers pay a fixed price, regardless of wholesale prices). If you attempt to run the grid when demand exceeds supply it will damage generators, making the problem worse. To avoid that, regulators shut off power to people who still had a working connection to the grid and would have been happy to consume power at their contracted rates.
As generation came back online, prices dropped quite low because demand was artificially constrained. The regulators then overrode the market and set the price to the maximum allowed by the system to encourage all generators to come online, which would then allow them to start turning people's power back on.
It's very common for software to work correctly a high percentage of the time, but fail on rare input data. If, say, the software works correctly 999,999 times out of a million, you're going to be very unlikely to discover that error by throwing random samples at it, especially if you need a physical process (ie, drawing blood) in order to generate a test case.
On the other hand, once you have a known failing case (as you would if the defendant knows the result must be in error because he didn't commit the crime), it's often fairly straightforward to identify the error by reviewing the source and/or using a debugger to examine the progress of the algorithm.
I _really_ don't agree that if one of those things happen I will no longer care about accessing my digital possessions/accounts. If anything I need that access more than I did before it happened.
And home isn't really convenient enough for many people: I, for one, frequently create accounts at work and when traveling. This subset of people are going to be doing either #2 or #3.
For the folks that are still using the same password everywhere I think a password manager is a better recommendation than a security key. For one it helps them everywhere, not just the small number of sites that currently support U2F/Webauthn. For another, such a person is probably at high risk of making mistake #2.
(1) Store their backup key in a more convenient, but less secure location (likely their home), putting them at risk of losing both the primary and backup key to the same event.
(2) Enroll only their primary key when an account is created, putting them at risk of locking themself out if they forget to add the backup at some point.
(3) Only use security keys for the highest value accounts, which tend to be a small enough number that you have a chance of actually remembering to add the backup key every time you set one up.
Of these, #3 is the only one that doesn't pose what I consider an unacceptable risk of lockout to the average person, so that's what I recommend.
However, a good solution for this issue is finally in the works: https://www.yubico.com/blog/yubico-proposes-webauthn-protoco...
The plaintiffs don't care, nor should they. When I go to a restaurant and order a hamburger, if the server brings me a tuna melt I send it back. It doesn't matter why the server brought me a tuna melt. Facebook is essentially saying that even though they wrote hamburger on the menu, and accepted my order for a hamburger, I should have known they meant a 41% chance of a hamburger and a 59% chance of something else because taped underneath my seat is a 15,000 word Restaurant Use Agreement printed on microfiche.
The safety profile in the 0-2 month timeframe is very easy to understand: they tested it, so they have actual data. But it seems for longer than 2 or 3 months you would need to make an argument based on animal trials or just biological reasoning. But I can't find anyone talking about it at all.
In 1934, the Senate cited two men for contempt of Congress and sentenced them to 10 days in the DC jail. One, William P. MacCracken, Jr, fought the case in court, eventually losing in the Supreme Court case Jurney v. MacCracken of 1935. He served one night of his sentence in the home of the Senate Sergeant-at-Arms and another in the Willard hotel... I was unable to figure out if he ever actually ended up in the DC jail.