These are some of the worst designed charts. I had to download the CSV to figure out that the x-axis is age.
Once I figured it out the bottom right chart was chilling.
502 karma · joined September 14, 2011
Once I figured it out the bottom right chart was chilling.
An in-browser photo editor or 3D modeling software would be expected to run much better and apply complex effects or render models much faster on high-end hardware. It sort of works this way with WebGL content, but even there you're limited to feeding the render pipeline with a single thread.
I want the web as a platform to succeed. It is the only truly universal runtime and with some care it could offer very few performance trade-offs. I sincerely hope tools like servo and others unlock this potential.
This of course pales in comparison to the 478 million outstanding shares, so, you are correct: their shares don't appreciate nearly enough from the $15 billion surge in market cap to pay for the $13.7 billion purchase. However, to say "whatever the stock does has no impact on the company" is also inaccurate.
Of course more performance per watt is always better and I too hope Zen 2 can be even better. But right now, in certain scenarios, Ryzen is already leading in both performance per watt and per dollar.
The number of people affected are low. My Ryzen machine has only ever run linux and compiles a lot and has never exhibited this behavior. Also, most new platforms have issues, even new server platforms. These will be worked through during substantial validation server OEMs will go through.
Lastly, look up the errata list for any Xeon CPUs. Intel releases microcode updates for them several times a year to fix bugs. Modern CPUs are complex and will pretty much always have bugs. Luckily some combination of BIOS or microcode updates will almost always resolve them.
If the encryptor offers multiple inputs, one a dummy "sure, here is my password, officer" HTML and passphrase, the other the sensitive one this scheme could work. Hiding both in a single blob, plus some noise, could work in the browser too. Seems it might offer some degree of plausible deniability. Some investigation of the decrypted dummy HTML might reveal it isn't large enough to account for the size of the blob. This doesn't seem like an insurmountable obstacle though. If the tool hides an arbitrary number of inputs in blobs that are indistinguishable you'd seem to have a great deal of deniability.
System is overclocked (1700@3.8) and has been up and 100% solid for weeks now. 3.85 actually worked and tried to stress it by compiling a bunch of stuff. Didn't have any segfaults or other issues. Worked great.
Only after using an artificial stress tool (stress-ng) did I finally decide 3.85 was not 100% stable at stock volts. Backed off to 3.8 to avoid voltage increase for now. Haven't rebooted since.
The issues being reported do seem legitimate, however. Not sure if it's the memory controller having trouble with certain DDR4, the motherboards, or errata within the Ryzen CPU itself. All seem plausible. Hopefully AMD finds a resolution. In the meantime I'm glad I'm not affected.
Robert Riech makes good points but provides zero ideas how to solve them. Relying on the goodness of CEO's hearts isn't going to cut it. That won't help enough people. How do we incentivize the behavior of employee ownership? Right now the incentives are aligned against that, as Reich seems to make clear. He seems to be advocating against more "radical" approaches advocated by Bernie Sanders because there is this glimmer of hope some CEOs will be nicer. It seems like this article makes the point that structural changes are necessary but the author falls short of that conclusion and instead gives glowing praise to a single CEO in hopes it will inspire a few others. It might, but that won't help much.
That said, I love CoffeeScript and continue to use it to this day. It gets a lot of hate and I've been pushed to write a lot of ES6 these days, but CoffeeScript is still much more succinct.
> subject to all the abuse you can introduce
> might cause [...] problems
I've said a few things about the potential benefits, though I am not involved in the project. The actual authors offer the best list of benefits: https://github.com/pypa/pipfile#the-concept
They also point out this will eventually be built into pip, so it will have the benefits of all the existing workarounds like pip-tools without any setup. It does seem like a lot more than change for the sake of change, and along with it since there is so much change why not take the opportunity to adopt a flexible DSL built for future extension so there is less real change in the future.
I think this is the product of people who got to know both Python and Ruby very well and found Python lacking here. There are lots of things Ruby developers were gifted from people who also know Python and found Ruby lacking. Python is generally something I force myself through so I'm not one of those people but so glad they exist.
BTW, Ruby has tools similar to virtualenv: chruby, rbenv, and rvm all do basically the same thing.
I also find it a little odd since a destructive project author can still find ways to mess things up without any code executing during setup, right?
Since this is for project level dependencies it doesn't seem like the potential for abuse is too high since you'll likely have a single Pipfile per project and the project will control it.
I don't know that anything will prevent destructive developers from being destructive. I would hate to throw out all DSLs because of a few bad actors.
For what it's worth in Ruby even library dependencies are written using a ruby DSL that runs unprotected during install, as well as some post installation hook facilities. There have been minor abuses like annoyingly long post-install messages and other crap that has occurred, but through simple community pressure the offending libraries are eventually pushed back in line and it's not an issue Ruby developers regularly encounter. Communities are different but Python seems like a community that appreciates best practices and is maybe better at enforcing them than Ruby is, so I'm not sure preventing one minor way a terrible developer can bite you is worth hamstringing your build system.
Yes, an over-wrought DSL is not a prerequisite. You can do deterministic builds and even grouped dependencies without it. But complex platform specific dependencies, git based dependencies, and dependency edge cases we haven't yet envisioned are more easily captured in an extendible native DSL than a more static data format. The DSL also has the advantage of being "just Python" so it will be very easy to remember for Python developers.
Maybe the benefits aren't worth the trade-offs but don't be so quick to count potential or perceived trade-offs as actual ones until you try out the new build system and see how it impacts your workflow. I know you got burned but this isn't setup.py and potential for abuse isn't the same as abuse... yet.
There seem to be a lot of strange fears from python developers about this approach and my comment on age was an attempt to assuage those fears. Since ruby developers are quite happy with bundler (at least in comparison to other communities) and have been for some time it's a reasonable point and not the only one I made.
I'm not sure how pip plans to use the lock file for projects distributed via pip. They may very well have a solution planned for that.
However, for projects that are distributed by source (which are many) the lock file ensures deterministic builds, and requirements.txt generally doesn't without being pedantic with your versions.
Maybe my tone came across condescending. That wasn't the intent. It was meant in jest in hopes the reader would second guess the fear.
KISS is great, but this project is here because it's not already working for everyone. There is benefit to a flexible dependency system that keeps the concepts of "acceptable versions" separate from "actual versions last used" while also adopting an extendible DSL ready for edge cases that haven't been thought of.
Installing the project would cause it to be built from the lock file (assuming the Pipefile hasn't changed). This will mean your users won't get "some version" of a library you depend on between verion 1.0 and 2.0 or whatever range you specified. They'll get the exact package you last successfully used and checked in yourself, right down to the git commit if applicable.
Once you modify the Pipfile then pip will resolve your dependencies and try to make the specified changes by adding/removing/upgrading packages. If Pypa continues following bundler conventions this will be done by making the fewest changes possible from your existing versions in your lock file. You'll also have an upgrade mode where pip will rebuild you project from the Pipfile looking for the most recent versions of all libraries or a specified library within your specified version ranges. When done and your app/tests are working, check in the new version and you can ensure all your users/environments will be able to upgrade cleanly.
Don't be so scared. Ruby developers have been doing this for over 7 years now. Trust us, this is much better. Your Python friends at Pypa are copying Ruby because dependencies are less painful there than just about anywhere. They are still painful, but this will help.