I've been hosting dl at work for many years and it's filled our needs admirably. Simple, zero maintenance, just works.
It even has a useful Thunderbird extension that auto-uploads any large attachment using the FileLink API when composing a new mail, adding the dl URL in the email's body. Unfortunately the extension stopped working after the migration to WebExtensions.
Technology often starts out expensive and enthusiast only, but if Intel keeps throwing these wild punches in every direction, why wouldn't we see a steady migration to alternatives? AMD is definitely benefiting from Intel's recent decisions, I am sure Raptor is also starting to get more business. A few more years of shady Intel decisions combined with sufficient negative press and I am sure the market will gladly decide. There are surely plenty of large corporations who can afford the costs and would prefer being able to audit everything themselves. This seems like the perfect storm for competition to finally have a chance.
You cannot deliver competitive quality, performance and pricing right away, completely agree. But there's generally a threshold to how much more expensive it can be in the beginning, and more importantly, how much you benefit from it. The problem here is that only few people even understand the problems with what Intel does, and even fewer people care. My games still run fine so why should I care? HN is a real echo chamber in cases like this and easily give a false impression. As you also mentioned, AMD is the only realistic winner from all this, since it's also x86 so you can switch over and everything stays the same. But in general, remember that people are very good at forgetting, and at just accepting that "everything's fucked up" is the new normal. Intel only needs to keep delivering competitive performance and people will keep buying.
I'd really love to see a big shift to a new architecture, RISC V, OpenPOWER etc. get me really excited because as a nerd new technology in general is always interesting, but the above simply is my prediction of the future based on history. I mean, how long ago have the first serious Intel ME vulnerabilities been disclosed? What happened apart from a short shitstorm on tech websites and some small companies offering laptops with crippled down IME that only complete neck beards care about?
DL (http://www.thregr.org/~wavexx/software/dl/) allows users to upload files and send links out, or users to generate links ("tickets") that others can use to upload files.
My mod was less successful, and the colors are definitely off. Having done the mod myself and seen how cumbersome it is to get the LED strip perfectly oriented in the CCFL gutter, I'm not likely to try again.
Ah, that's a common misconception. Even with coroutines you still want explicit async calls and futures, otherwise if you restrict yourself only sync calls, you either have to artificially serialize operations or have to spawn artificial coroutines.
What do you do not want are explicit uses of 'future::then' and the required manual CPS transform. Instead you want a wait-for-{any,all} future operations.
Is there any compiler to date that has a fully developed and released parallel algorithms library? The last time I checked a lot of this work still looked like it was in the research stage.
I share your enthusiasm tho. It will probably introduce parallel code into everyday C++ projects faster then new special purpose parallel programming primitives will.
I'm quite annoyed by announcements like this. To be complete, you have to provide a complete solution. It's really annoying with GCC that you have to check in multiple places to see which features a given release supports.
You are right. The thing is though that you (or third parties) can implement missing library features that do not require compiler support [1], but for the language itself you have to wait for the compiler. For example, thanks to the hyperproductive STL [2], MSVC has always had a fairly up to date library, but the compiler lagged behind.
[1] For a long time libstdc++ lacked regex support, but people could get them from boost and mostly didn't care.
The solution to that is to use the IdentityFile directive in your ~/.ssh/config with username / hostname expansion.
I use:
Host *
# Disable SSHv1
RSAAuthentication no
# Only use a key explicitely provided by an IdentityFile directive
IdentitiesOnly yes
# %h expands to the hostname, and %u to the username
IdentityFile ~/.ssh/%h/%u.key
This ensures that at most one key is used, and prevents me from having to modify my config every time I generate a key for a new host.
