Yes, but were those other login attempts using the actual password that was correct when my account was active? I'm probably just being paranoid... of course FB deleted my account and all its details.
Voice chat. It is superior to any other platform on this aspect other than TeamSpeak. We regularly have 40+ people in voice channels without people suffering from connection issues, bad audio quality, and lot's of noise.
It is super easy with dotnet core. The new CLI is pretty simple, you use it as a package manager and compiler. Visual Studio also uses the CLI to run and debug dotnet core projects.
https://docs.microsoft.com/en-us/dotnet/core/tools/
Is it possible to create a single, stand-alone, self-contained .exe?
(I'm fine with only building for a single platform - Mac/Win/Linux)
Needing to run my programs (which show up as .dll's) using dotnet just feels weird (and it doesn't match my intuition for 'how programs are run' in Windows cmd/etc).
I'd be fine with an .exe that's not self contained but at least I run it like a 'normal' exe. :)
Yes that is possible, you can produce an .exe which contains your application's assemblies but relies on the appropriate .NET runtime being present on the user's computer. You can also build a .exe which has the .NET runtime bundled, but it can be quite big. I made a simple program that wrote "Hello World" to the console [1] and it was between 46-78MB: https://blog.mclemon.org/no-this-is-what-peak-hello-world-lo...
Wow! Yeah indeed there's a few impractical steps required to go all the way to 8kb, but trimming down to a couple of MB is definitely a huge improvement. I somehow never looked into CoreRT before, I'm gonna need to do so. Thanks for sharing this!
You have to set up "dotnet publish" for the project that makes the executable.
It then makes a stub loader "your program.exe" which looks and behaves normally. You can then make it "self contained", which bundles the assemblies for you and transparently unpacks them.
You can have different publish profiles for the different targets.
.NET 5.0 can now create true single file that doesn't need any unpacking on first run (except on Windows where the Jit and GC dlls will live or be unpacked separately; but that should be resolved in .NET 6.0)
But I want it to produce a single EXE and that's it... like the C# compiler has always been capable of doing. Sorry I neglected to mention that part (kind of assumed it was a given).
Also, the whole thing is still a stateful operation revolving a .csproj file, which (again) is XML I have to create (sure, it's just one command) and manage/deal with every time. Even to compile a tiny C# file from my editor now I need to make a project for it. With a normal C# or C++ compiler I can just invoke csc.exe or cl.exe and produce the executable in one command from my editor... no intermediate state or project file management required. That's kind of what I was getting at with it being "simple". I didn't just mean the syntax, I also meant the structure of the solution.
You can still just invoke csc.exe, no project file required - I'm not sure what you are getting at? But it's probably going to be easier to just dotnet new console and get the project file for free. They tried migrating away from csproj but there is just too much ecosystem around it. The XML sounds bad, but in reality they added file globbing and other things to make it so you rarely even have to change it. That and to be honest it just works and is quite readable even though it's the "evil" XML.
No, it's always compiled to MSIL. You've always had to use a separate tool (such as NGen or dotnet publish) to do AOT compilation. But there are tradeoffs and AOT doesn't always mean faster performance.
But again, if you use the dotnet CLI you can just dotnet publish to create a AOT version of your exe. Just remember it still has the runtime and GC. You are just reducing the work of the JIT. Also AOT does not guarantee you will not JIT and still contains the MSIL. It's just a performance optimization where pre-compiled code will be used when possible.
Yes, I'm already aware of all this? I'm confused why you're explaining all this background—I'm well-aware of all this and my previous comments were already in response to these.
Because the markets wants to trade on it. Going with the assumption that crypto will "succeed" in the future, any business or bank not trading on it would be loosing out to businesses that are capable to do both.
That is circular. BTC will succeed as an investment because it will supplant other systems for banking. BTC will supplant other systems for banking because it succeeds as an investment.
It would be solved in the same way those problems are solved today, through court. Not following court orders ultimately leads to enforcement through force. You'd end up arrested and jailed at some point.
>> If we are not a bitcoin miner, then how will we get the funds to begin with? Right now I can trade fiat for it, but in the future my children would not be able to trade fiat for it (assuming it's as good as you say it is). So, they will become indentured servants to the bitcoin miners.
I don't quite understand the point you are trying to make here? Cash just don't magically appear today either. Why wouldn't they be able to trade fiat for crypto in the future?
> You'd end up arrested and jailed at some point.
- assuming they didn't flee
- assuming they didn't spend the bitcoin
- assuming they didn't transfer the bitcoin, and then claim it was stolen/lost.
With fiat controlled by banks, most liquid assets are frozen during these sorts of disputes for the above reason. A threat of jail in the future also doesn't really help the other person during that timeframe.
Cash does magically appear, actually. It's printed by mints and released via monetary control.
Civil forfeiture has become a controversial issue lately. It's not clear that the ability of financial institutions to do that is actually a net positive for society.
Consider how it'd be easier to catch criminals without the fourth and fifth amendment, but it is thought to be more important that we provide protections against government overreach.
Cash doesn't, but money does. The principal function of central banks is controlling the rate of money creation to ensure that the money supply supports economic activity.
>> But there is still this very common belief that we get ill by getting cold in a physical sense, while e.g. being outside with not warm enough clothes.
This is kinda true, the body produce mucus (snot) in the nasal passages. Microbes sticks to this, and when swallowed are neutralized by our stomach acid. But cold air slows down this process, so our first line of defence doesn't work as well during winter.
There are also factors such as behaviour changes like spending more time indoors, closed windows and a lot of other stuff that also likely helps spread infections.
I think there are multiple factors, each of which only increases R by a little bit, but when combined produce a noticeable increase.
Lack of ventilation is certainly a major factor. The temperature difference between indoors and outdoors is much larger in the winter, so people are more reluctant to let in fresh air.
We also don't wash winter clothes as often as we do summer clothes, so viruses that stick to fabric might have more chances to get into our bodies. Homes and public spaces get cleaned less often, too, as they don't feel as sticky and smelly as they do in the summer. Ditto for our own hands, which is probably more important that any of the other factors mentioned here.
In the United States, two of the largest mass migration and shopping events of the year take place in the early to mid-winter: Thanksgiving and Christmas. In China, COVID-19 began to spread in earnest outside of Wuhan around Chinese New Year. Even societies that don't have a special holiday in the wintertime might be impacted by cascading infections from those that do.
For me the usefulness of a ORM depends a lot on the language I'm working with. In the .NET world the choice is easy, Linq and EntityFramework is a killer combination. It's so much faster, and better than writing your own queries. I don't feel any of the normal arguments I hear against ORM's apply to the Linq + EF combo. For Python and JS, I kinda can releate to some of the common arguments, but still feel that ORM's have a use.
It depends on how you use Tor. For browsing you will essentially remain anonymous forever unless you do something that can connect you between sessions, like logging into some user account. This excludes side-channel attacks and an adverse which controls a large number of nodes, or is able to listen to a lot of the global network traffic.
It's different for people who operates hidden services. They are always online, and it is easy to tie one session to another, because the session will always be tied to the service they are running. This means that over time, you will be able to identify the service even with control over a small subset of services. You can read more about the different ways this can be done here: https://www.hackerfactor.com/blog/index.php?/archives/896-To...
