5) God does exist but the reason there is literally no evidence is that he wants to test us and will punish those who believe in something with no evidence and with send to heaven all those who don't believe in him.
Seriously. Pascal's wager is the dumbest wager I've ever heard.
Cloud 9 and Eclipse Che are different beasts. The primary difference is around the definition of a workspace. Eclipse Che workspaces have an encapsulation that include their runtimes and a self-hosted IDE. This, then, allows you to run Eclipse Che as a workspace server on any server or desktop. And since the workspaces are defined with configuration files you can move workspaces from one server to another.
The SDK is entirely open source - with no restrictoins, so there is a development model for how to customize both the IDE and the workspace.
Since workspaces embed their own runtimes, you can use Dockerfiles to create completely customized stacks. And we'll be supporting composefiles shortly.
We built Che this way to encourage ISVs to adopt for ucsotmization while also providing a simple IDE for developers. Codenvy uses Che to build out a distributed system that they host at beta.codenvy.com and also is installable by customers behind their firewall.
Cloud 9 is primarily a fully hosted SaaS with their IDE. The IDE features are similar but different, with C9 having more work around collaboration of users within the shared environment.
There is more details beyond this - but this is the essence.
You'd need the sphere to be more than massive enough to collapse under its own gravity, into a black hole; such a structure wouldn't be hypothetically possible. Building black holes with anything other than stars or giant gas clouds (in the early universe) turns out to be hard; your black hole generators inevitably keep collapsing into black holes or at least neutron stars.
> You'd need the sphere to be more than massive enough to collapse under its own gravity, into a black hole; such a structure wouldn't be hypothetically possible.
I don't think that's technically true. You could build a bunch of catapults on the edge of the sphere, and when they all launch rocks at the center of the sphere, they would eventually form a black hole. The catapults could be arbitrarily far from each other as the radius of the sphere increases, such that they would not really do much to each other gravitationally. You'd just have to wait a real long time for the rocks to hit the middle.
> Building black holes with anything other than stars or giant gas clouds (in the early universe) turns out to be hard;
Well yes, galaxy-sized intelligently designed structures don't really happen.
I think by "Black hole generator" the other person meant a device which could create black holes remotely through some kind of process, not just a mass that collapses under its own gravity. In that sense, if you could find an old, spun-down neutron star (and man wouldn't that be a fun search! Massive, but tiny and dim...) then as you say, you could just keep adding mass until crush.
Any black hole generator that doesn't itself become a black hole is essentially throwing part of itself in the black hole (Yay conservation laws!). You can replace the catapults with lasers or plasma guns or whatever.
Sure, but I think the original commentator was imaging a massive sphere that could emit such powerful and precise gravitational waves, that you could create more black holes as a result. My point was just that any mass capable of achieving that, even hypothetically, would have long since collapses into a black hole.
I take your point however, that you could coordinate in some way separated masses, but at some point you'd probably run into issues with the aforementioned galactic-scale of engineering.
I looked into this a while back, and they're able to get 50%+ thermal efficiencies by using their own modified thermodynamic cycle that promotes more complete fuel combustion, as well as arranging the engine components in such a way that the engine has low heat rejection qualities. Nearly doubling the efficiency of the typical ICE setup and doing so with large weight reductions far outweighs any issues with rotary seals. These things are so compact and simple that it would be feasible to simply drop an entirely new engine into your car and melt down the old one when the seals wear out. Not that it would come to that, but those are the kind of economics we're dealing with here. This is a legitimately nifty invention.
Trying to understand what is different and found this:
"The basic idea is similar to a Wankel rotary, but turned on its head. Where the rotor holds the seals in a normal Wankel, the housing does that job in the X1 engine. This allows significant reduction in oil consumption over a regular rotary motor. Other enhancements include direct injection, a high compression ratio at 18:1, and a dramatic change to the geometry of the combustion chamber, which maintains a constant volume during ignition. This change means the air-fuel mixture auto-ignites like a diesel, and can be burned much longer than normal. The result is a more complete combustion ending in low emissions and very high chamber pressures. This high pressure is allowed to act on the rotor until it reaches nearly atmospheric pressures, so almost all the available energy is extracted before the exhaust is physically pushed out. Again, this is different than a normal internal combustion engine, which releases very energetic, high-pressure exhaust gas."
Just doing a brief visual comparison from https://www.youtube.com/watch?v=0e785YnDmq0, the most immediate difference is the inversion of the housing and rotor shapes. Instead of a dorito shaped rotor like the wankel, it has a jelly bean shaped rotor. And instead of a jelly bean shaped housing, it has a dorito shaped housing.
Also, my memory of the workings of the wankel is a bit rusty, but I believe it is inherently balanced, so no counterbalance is necessary, but this one requires a counterbalance. On the other hand, unlike the wankel's one combustion chamber, this one has 3, so it doesn't need to deal with asymmetric heating issues. The combustion chambers themselves are very interesting. Due to the dorito shaped nature of the wankel rotor, there seems to be an inherent limit to the compression ratio because of the planar sides of the rotor can't get any closer to the wall of the housing. But on this one, the rotor can get completely flush with the housing, allowing more direct control over the compression ratio. Definitely an intriguing design.
Several of the visualizations use data from ACS summary tables and the axis in several of the visualizations reflect the underlying buckets provided by the Census Bureau.
I realized I was heading down that path, and just went full into. I use https://kanboard.net/ to manage a couple todo lists (projects) like upcoming purchases, bills, chores. It's worked out amazing so far.
Usually it's other way around: patches are released on the day of the disclosure.
Without firm date, companies have little to no incentive to fix the bug sooner (cough Adobe cough).
Some people even managed to figure it out before the patches; doesn't mean we should expedite the release of exploits. Its gonna take more than a day for everyone to get patched.
No. As an admin I'd rather have the details so I can make sure even my non-standard, non-patchable, fleet is safe. (Where I might need to implement custom firewall rules to inspect data for bad patterns, etc.) Once my coworkers and I protected our ISP's customers against a worm at the external boundary. If we'd only had the patch and some sanitized information to work from that would have rattled around our system for months until we'd harassed every customer to update and would have caused tons of harm in the meantime.
I understand that in a make-believe scenario it'd be good to make sure bad-guys don't hear the info, but in a real-world scenario where you don't get to choose it's far better that the good guys have all the info even if a few more bad guys do to. And I say a few more because it's almost 100% certain that for every bug found there were attackers who knew about it beforehand.
Also, as others have mentioned, for anyone skilled a patch reads like a changelog. When I see security patches I often read the patched code or do a bindiff/disassemble and try to spot the issue and I'm only a hobbyist. We might as well level the field and give everyone the info, not just the reverse-engineers. (Who disproportionally are on the "other" side.)
It makes the "hair on fire" nature of critical security vulnerabilities unavoidable. It's much easier to sell an outage to management if you can more easily demonstrate that anyone could have this exploit (which is true regardless).
