And extracting that methane by hydraulic fracking.
Don't get me wrong, I'm not against fracking per se. I think we could probably do it safer, but then again I think virtually everything that humanity does, even the good stuff, could probably be better in some way. But instead we just get a shouting match between banning fracking altogether and letting companies get away with substandard engineering./rant
First, that might be a good reason to turn off automatic updates for Java only. Not a great one because of security fixes, but OK.
Second, what happens when you have two of these programs that require specific and different versions? Or when one upgrades and the others don't. Or who knows.
Finally, I searched for "multiple concurrent java versions" and got a number of results for all OSes on how to keep them all sorted. So having a single bespoke version of Java for your one finicky program and then keeping the global/system one up to date seems most logical.
That may be accurate, but isn't useful for determining if the new version is worth downloading.
Reading through release notes to see if a new version is worth downloading? Ain't nobody* got time for that!
This is the 21st century, I expect no less than that every every software component automatically and silently updates itself in an unobtrusive manner. Android, iOS and even Windows Mobile figured this out ages ago -- figure out what times of the day the user doesn't use their phone for hours at a time, wait for both power & WiFi and substantial inactivity, then go do it. Windows 10 very visibly flubbed it by missing the 'inactivity' part (oh well), but lots of projects do it well and you don't notice. Chrome is exemplary in this respect: no one every talks about Chrome updates because they just silently happen, correctly and without interrupting the user.
There is no reason that the device can't figure this out without my help.
* OK, fine, there should certainly be some setting somewhere where you can put it on full-manual mode for all updates. Why anyone would want that is totally beyond me, but here's to constructive differences.
The rate at which companies are churning out phones is roughly equal to the rate at which consumers voluntarily chose to exchange money for phones. Sure they pay for slick marketing campaigns, but that's just the point -- they have to convince the masses who, ultimately, have the last word.
That's the concurrently liberating-and-frustrating thing about living in a free world -- by decentralizing decision making we've also diffused responsibility. If we all cared deeply about e-waste, then we would collectively move towards replacing phones and laptops less frequently and buying larger and sturdier ones. Maybe we already have, in the sense that if tomorrow we removed the concern about e-waste, we'd buy a bunch more. Maybe we haven't, and that experiment wouldn't move the dial at all.
So if you think there should be 'some effort' here, it's on the part of those buying devices to consider the e-waste story in their purchases.
[ Note: There is a parallel philosophical debate about whether "what people want" is legitimately evidence of The Good or when/whether it should yield to more enlightened formulations. Both sides are fraught with difficulties, and we are surely not going to resolve them here on/.
There's also a debate about whether "what people want" is best described by what they say they want or what they demonstrate they want through actions, at least when those things contradict one another. That's another deep one unsuited for a technology story comment section. ]
The researcher shows that the phone unlocks when presented with his face, but it doesn't show the enrollment or training phase.
For the sake of transparency, it would be nice to see that enrollment was done on his normal face without using any part of the mask or other shenanigans. And since the scanner apparently 'learns' from failed scans where you immediately enter the (correct) passcode, that's another route by which he could corrupt the enrolled data -- he could scan the mask and then enter his passcode enough times that it 'learns' the wrong thing.
If either of those are true, it only shows that the authorized user can enroll data that's close enough to both his real face and a mask that both unlock it.
If I may, let me ask a possibly silly question: Why do these companies always have to be interviewed by some Congressional committee? What's the point? I mean, the damage is already done, nothing Congress can do to change that. If a crime has been committed, those responsible should be prosecuted. If civil damages occurred, they should be sued. What's the point of the grandstanding by Congresscritters?
I'll agree to to the charge of grandstanding, but Congress absolutely should interview lots of relevant people before writing new law. Maybe in the case of ignorant-seeming CEOs they should discount that testimony as self-serving or willfully-obtuse. But there's nothing wrong with listening and considering what he's willing to say about it.
And on the gripping hand, depending on how something is hacked, "at rest" encryption may just be totally useless. It will protect you if someone gets a raw copy of your database, but if they have access to your application infrastructure, that infrastructure will happily decrypt the data for them, because that's what it does. Meanwhile, you will take a *huge* performance hit on a lot of database operations. Really, I have trouble imagining the small additional security being worth the cost in performance. But maybe I'm not familiar with enterprise-scale operations - anyone who is care to comment?
It's not a silver bullet, but encryption at rest helps in a number of ways. It forces the attacker to continue to work from within your infrastructure, which at least opens the possibility you might detect what's going on. It allows you to partition credentials so that applications have least privilege and can only decrypt data for which they have a business need to access. It's an excellent place to design in reporting so that red flags are raised when all of a sudden every row in the DB is requested when normally they don't operate at such volume. Rate-limiting can suspend a service if it blows through its decryption quota, which is a very good way to get attention that something is amiss.
In short, encryption at rest enables (but doesn't magically provide in and of itself) the ability to have a single source of policy that is enforced cryptographically --- you must satisfy the policy in order to see sensitive data. It should be viewed as a building block to that end.
Of course if you are just interested in buzzwords and box-ticking, you can encrypt everything and then just have a dumb decryption service that lets any application decrypt as much data from any domain and with no logging and no limits. Then you're right -- it's no better than having it in plain.
You are confusing "what people say they want" with "market demand".
It's really easy to figure out the former -- you look at what's available and how well it's selling and there you go. Market research focuses on answering, "would people want this if we put it on the market", in advance.
Companies focus exclusively on market demand -- what people would buy if it were offered to them.
Most of the GOP tax plan is a give away to the rich and the very rich. Complaining about the loss of a credit for a car that costs 2x the median income might not be the best way to say on message.
What's the harm in reducing emissions? If we're not causing it then cutting emissions can't hurt. If we are causing it, then cutting emissions will help. Seems like a win-win to me.
Of course it can hurt -- it's more expensive to build fuel efficient cars. It's less comfortable to live in a house heated to 68F rather than 72F in the winter, or cooled to 78F instead of 75F in the summer. It's nice to fly over oceans to visit other continents, to eat a nice steak or drive a fast car.
I'm not saying that we can't live without those things, but holy hell it will surely hurt to reduce emissions. And if I didn't fully believe in climate change, there's no way I could support any of these proposals to lower our standard of living or to put more of these amenities out of reach of the lower classes.
So even as an avid believer in climate change, what you wrote is completely bonkers. My support for reducing carbon emissions is absolutely contingent on the facts. If I were convinced tomorrow that facts were different (quite unlikely, I believe that these things are known with significant certainty) then I would of course have different policy preference.
Or maybe, I can rephrase it another way: if you would still advocate for the same policy irrespective of the underlying facts, then that is the definition of unscientific reasoning because it's not falsifiable. Every scientific belief necessarily has to come "built in" with some kind of a statement like "I would not believe this to be true if _____" or else it's not science, it's faith.
We know how to make artificial lakes that we can use for pumped storage hydroelectric, but the environmentalists get (justifiably) nervous when we talk mass-scale rearrangement of waterways in the hills/mountains above sensitive ecosystems.
That's as good a battery as you'll ever get -- 75% efficiency, scales into GW. It doesn't help the teenaged libertarian fantasies about a fully decentralized power system, though. So depending on your political slant, it might not be the right option.
Without arguing over your statement about whether it's justifiable to build a nuclear power plant, it is absolutely bonkers to idle an already constructed and operational nuclear power plant.
How many, exactly, is "many of us"? Have you done quantitative market research? Who exactly is the 'us' that you sampled? Did you make an effort to adjust your findings to match the demographic profile of phone purchasers?
I mean, I'm not arguing that anything on your list is good or bad, but your 'us' seems like it might just be the like-minded technologically-knowledgable people that you surround yourself with and not any kind of 'us' that represents the broader purchasing market. Companies spend huge sums developing products, and they get severely punished if consumers don't want them. As an epistemological statement, I would bet they are right more often than you are on (even if not always).
More broadly, computing is no longer the domain of the knowledgable. Democratizing tech has made its benefits more widely available but it also means that the opinions and attitudes of the masses rarely more weight. We can deny the facts, we can sulk over it, or we can accept that tech is no longer the domain of techies even though we were 'here first'.
Yeah, and "move fast and break things" is contingent on the fact that for some well-structured computer systems you can always roll things back to a previously good state and try again -- nothing lost but time. This is why we have version control and what I always try to teach newbies so that they feel free to break things.
Or maybe another way to phrase it -- the speed at which you should move and break stuff is inversely proportional to how much work it is to back your changes out. If you are writing some CSS, this is basically instant. If you are a DB admin, you should probably be careful and have a mock environment, but you have backups in case of disaster. (I hope). If you are taping out silicon and sending it to the foundry, uh, good luck!
So the problem here isn't the 'move fast and break things', since that seems to be the appropriate model for a an app. It's that Android broke the fundamental tenet of app development: which is that if you fuck up, the worst you can do is have to uninstall the app and maybe lose all your local app data. That is, the contract was for a low-cost-to-back-out environment and instead it tanked the entire thing.
Pay the salaries or stop complaining that you lose all your talent. We should be devoting at least a few percent of GDP to pure research.
We are, it's just moved away from universities and into the private sector.
My $0.02 (STEM PhD with ~10 published articles, now I work for a big tech co in Silicon Valley): if you want to do better research, stop organizing university research into tiny little fiefdoms. Directors should be able to hire and supervise senior faculty. Senior faculty should be be able to hire and supervise junior faculty as well as grad students. There should be enough program management to get organizations with 100-500 total researchers on the same page and working together towards a common goal. Researchers should be free to actually switch groups instead of being shackled to a grant.
The current structure is literally a hold over from the Middle Ages. Because everyone is in charge, no one is charge and the brilliance is squandered instead of focused.
Commonly-used software has bug(s), users impacted, company investigating fix. That story, and your local weather, right after this word from our sponsors.
There are two separate things: knowing what a framework does and knowing how it does it. In order to roll your own, you need to know both. But if things are documented right, the former is really enough.
Let me give a overly-trivial example (Python for simplicity, hardly matters): from ecdsa import VerifyingKey vk = VeryifyingKey.from_pem( VK_KEY_DATA ) assert vk.verify(signature, message):
What I would absolutely expect an engineer working on this code to understand is as follows: (1) Elliptic Curve come in private/public pairs, the system depends on the authenticity of the public key and the confidentiality of the private key (2) It is guaranteed that the message could only have been signed by the entity holding the private counterpart to VK_KEY_DATA. (3) The verify function provides no guarantee on when this signature was produced. If you need proof of liveness, you need to compose this. (4) The verify function provides no guarantee that a third party did not capture a valid signature, message tuple and pass it along.
What I would not require, by contrast, is an understanding of the mathematics of how EC curves provide these properties. That's may nice to have, but it really isn't necessary. So long as the engineer understands exactly what guarantees they get, the knowledge of how it's made is optional.
[ Of course, this is trivial example because ECDSA is a nearly perfect abstraction and its guarantees are very easy to understand and grok in their totality. Real frameworks/libraries are usually leaky and difficult to document precisely because they aren't formally specified. ]
You'd have to RTFA to find out. Or I'll help you: there is a little animation and so the second "+" doesn't register. It's as if you hit "1 + 23".
Every input device on planet earth has some maximum rate at which it can process events. If yours is slow, that's a performance problem -- in this case it looks like it was pretty crappy because the animation had to complete before you could enter the next thing.
If Tesla fired a bunch of workers for being pro-union, the union would file a complaint.
If Tesla fired a bunch of workers that were low performers, the union would file a complaint.
If Tesla fired a bunch of workers that were low performers but the reviews were {1%, 10%, 50%, 90%, 99%} biased against unionizers, the union would file a complaint.
There is literally no information to go on here besides our own biases. Of course, actually digging through hundreds of personnel files with dozens of performance reviews, correlating it with what the company thought, seeing if there are emails of improper motives, that would take a while and be fought. Best to stick to your gut instinct about evil companies or slacker workers or . . .
Certainly the total GHG potential of what you released by fracking NG and then burning it for heat/power is less than the end-to-end GHG potential of the equivalent in coal.
The energy of gravitational binding is necessarily negative. That is you say, if you have two objects near one another, you would have to inject positive work in order to separate them to infinity.
The most likely answer to the question about the 1st law of thermodynamics is that the entire universe is net zero energy, with the positive contributions from mass balanced out by the negative gravitational binding energy. Current cosmological calculations are consistent with this hypothesis, although it remains to be proven conclusively.
Slashdot Mirror
And extracting that methane by hydraulic fracking.
Don't get me wrong, I'm not against fracking per se. I think we could probably do it safer, but then again I think virtually everything that humanity does, even the good stuff, could probably be better in some way. But instead we just get a shouting match between banning fracking altogether and letting companies get away with substandard engineering. /rant
First, that might be a good reason to turn off automatic updates for Java only. Not a great one because of security fixes, but OK.
Second, what happens when you have two of these programs that require specific and different versions? Or when one upgrades and the others don't. Or who knows.
Finally, I searched for "multiple concurrent java versions" and got a number of results for all OSes on how to keep them all sorted. So having a single bespoke version of Java for your one finicky program and then keeping the global/system one up to date seems most logical.
Sure, I said we should have allowance for the minority of folks that want full manual control. Every operating system allows this, more power to you.
Just don't complain about getting pwned when the vulnerability was patched ages ago and you never took the update.
That may be accurate, but isn't useful for determining if the new version is worth downloading.
Reading through release notes to see if a new version is worth downloading? Ain't nobody* got time for that!
This is the 21st century, I expect no less than that every every software component automatically and silently updates itself in an unobtrusive manner. Android, iOS and even Windows Mobile figured this out ages ago -- figure out what times of the day the user doesn't use their phone for hours at a time, wait for both power & WiFi and substantial inactivity, then go do it. Windows 10 very visibly flubbed it by missing the 'inactivity' part (oh well), but lots of projects do it well and you don't notice. Chrome is exemplary in this respect: no one every talks about Chrome updates because they just silently happen, correctly and without interrupting the user.
There is no reason that the device can't figure this out without my help.
* OK, fine, there should certainly be some setting somewhere where you can put it on full-manual mode for all updates. Why anyone would want that is totally beyond me, but here's to constructive differences.
The rate at which companies are churning out phones is roughly equal to the rate at which consumers voluntarily chose to exchange money for phones. Sure they pay for slick marketing campaigns, but that's just the point -- they have to convince the masses who, ultimately, have the last word.
That's the concurrently liberating-and-frustrating thing about living in a free world -- by decentralizing decision making we've also diffused responsibility. If we all cared deeply about e-waste, then we would collectively move towards replacing phones and laptops less frequently and buying larger and sturdier ones. Maybe we already have, in the sense that if tomorrow we removed the concern about e-waste, we'd buy a bunch more. Maybe we haven't, and that experiment wouldn't move the dial at all.
So if you think there should be 'some effort' here, it's on the part of those buying devices to consider the e-waste story in their purchases.
[ Note: There is a parallel philosophical debate about whether "what people want" is legitimately evidence of The Good or when/whether it should yield to more enlightened formulations. Both sides are fraught with difficulties, and we are surely not going to resolve them here on /.
There's also a debate about whether "what people want" is best described by what they say they want or what they demonstrate they want through actions, at least when those things contradict one another. That's another deep one unsuited for a technology story comment section. ]
You would not imagine my shock when my partner got a job at a (major, high-level) hospital and was issued a pager.
It defaults you to use 6-digit and doesn't make the UI to decline obvious, but if you are persistent you can make it accept a 4-digit passcode.
The researcher shows that the phone unlocks when presented with his face, but it doesn't show the enrollment or training phase.
For the sake of transparency, it would be nice to see that enrollment was done on his normal face without using any part of the mask or other shenanigans. And since the scanner apparently 'learns' from failed scans where you immediately enter the (correct) passcode, that's another route by which he could corrupt the enrolled data -- he could scan the mask and then enter his passcode enough times that it 'learns' the wrong thing.
If either of those are true, it only shows that the authorized user can enroll data that's close enough to both his real face and a mask that both unlock it.
If I may, let me ask a possibly silly question: Why do these companies always have to be interviewed by some Congressional committee? What's the point? I mean, the damage is already done, nothing Congress can do to change that. If a crime has been committed, those responsible should be prosecuted. If civil damages occurred, they should be sued. What's the point of the grandstanding by Congresscritters?
I'll agree to to the charge of grandstanding, but Congress absolutely should interview lots of relevant people before writing new law. Maybe in the case of ignorant-seeming CEOs they should discount that testimony as self-serving or willfully-obtuse. But there's nothing wrong with listening and considering what he's willing to say about it.
And on the gripping hand, depending on how something is hacked, "at rest" encryption may just be totally useless. It will protect you if someone gets a raw copy of your database, but if they have access to your application infrastructure, that infrastructure will happily decrypt the data for them, because that's what it does. Meanwhile, you will take a *huge* performance hit on a lot of database operations. Really, I have trouble imagining the small additional security being worth the cost in performance. But maybe I'm not familiar with enterprise-scale operations - anyone who is care to comment?
It's not a silver bullet, but encryption at rest helps in a number of ways. It forces the attacker to continue to work from within your infrastructure, which at least opens the possibility you might detect what's going on. It allows you to partition credentials so that applications have least privilege and can only decrypt data for which they have a business need to access. It's an excellent place to design in reporting so that red flags are raised when all of a sudden every row in the DB is requested when normally they don't operate at such volume. Rate-limiting can suspend a service if it blows through its decryption quota, which is a very good way to get attention that something is amiss.
In short, encryption at rest enables (but doesn't magically provide in and of itself) the ability to have a single source of policy that is enforced cryptographically --- you must satisfy the policy in order to see sensitive data. It should be viewed as a building block to that end.
Of course if you are just interested in buzzwords and box-ticking, you can encrypt everything and then just have a dumb decryption service that lets any application decrypt as much data from any domain and with no logging and no limits. Then you're right -- it's no better than having it in plain.
You are confusing "what people say they want" with "market demand".
It's really easy to figure out the former -- you look at what's available and how well it's selling and there you go. Market research focuses on answering, "would people want this if we put it on the market", in advance.
Companies focus exclusively on market demand -- what people would buy if it were offered to them.
Most of the GOP tax plan is a give away to the rich and the very rich. Complaining about the loss of a credit for a car that costs 2x the median income might not be the best way to say on message.
What's the harm in reducing emissions? If we're not causing it then cutting emissions can't hurt. If we are causing it, then cutting emissions will help. Seems like a win-win to me.
Of course it can hurt -- it's more expensive to build fuel efficient cars. It's less comfortable to live in a house heated to 68F rather than 72F in the winter, or cooled to 78F instead of 75F in the summer. It's nice to fly over oceans to visit other continents, to eat a nice steak or drive a fast car.
I'm not saying that we can't live without those things, but holy hell it will surely hurt to reduce emissions. And if I didn't fully believe in climate change, there's no way I could support any of these proposals to lower our standard of living or to put more of these amenities out of reach of the lower classes.
So even as an avid believer in climate change, what you wrote is completely bonkers. My support for reducing carbon emissions is absolutely contingent on the facts. If I were convinced tomorrow that facts were different (quite unlikely, I believe that these things are known with significant certainty) then I would of course have different policy preference.
Or maybe, I can rephrase it another way: if you would still advocate for the same policy irrespective of the underlying facts, then that is the definition of unscientific reasoning because it's not falsifiable. Every scientific belief necessarily has to come "built in" with some kind of a statement like "I would not believe this to be true if _____" or else it's not science, it's faith.
We know how to make artificial lakes that we can use for pumped storage hydroelectric, but the environmentalists get (justifiably) nervous when we talk mass-scale rearrangement of waterways in the hills/mountains above sensitive ecosystems.
That's as good a battery as you'll ever get -- 75% efficiency, scales into GW. It doesn't help the teenaged libertarian fantasies about a fully decentralized power system, though. So depending on your political slant, it might not be the right option.
Without arguing over your statement about whether it's justifiable to build a nuclear power plant, it is absolutely bonkers to idle an already constructed and operational nuclear power plant.
How many, exactly, is "many of us"? Have you done quantitative market research? Who exactly is the 'us' that you sampled? Did you make an effort to adjust your findings to match the demographic profile of phone purchasers?
I mean, I'm not arguing that anything on your list is good or bad, but your 'us' seems like it might just be the like-minded technologically-knowledgable people that you surround yourself with and not any kind of 'us' that represents the broader purchasing market. Companies spend huge sums developing products, and they get severely punished if consumers don't want them. As an epistemological statement, I would bet they are right more often than you are on (even if not always).
More broadly, computing is no longer the domain of the knowledgable. Democratizing tech has made its benefits more widely available but it also means that the opinions and attitudes of the masses rarely more weight. We can deny the facts, we can sulk over it, or we can accept that tech is no longer the domain of techies even though we were 'here first'.
Yeah, and "move fast and break things" is contingent on the fact that for some well-structured computer systems you can always roll things back to a previously good state and try again -- nothing lost but time. This is why we have version control and what I always try to teach newbies so that they feel free to break things.
Or maybe another way to phrase it -- the speed at which you should move and break stuff is inversely proportional to how much work it is to back your changes out. If you are writing some CSS, this is basically instant. If you are a DB admin, you should probably be careful and have a mock environment, but you have backups in case of disaster. (I hope). If you are taping out silicon and sending it to the foundry, uh, good luck!
So the problem here isn't the 'move fast and break things', since that seems to be the appropriate model for a an app. It's that Android broke the fundamental tenet of app development: which is that if you fuck up, the worst you can do is have to uninstall the app and maybe lose all your local app data. That is, the contract was for a low-cost-to-back-out environment and instead it tanked the entire thing.
Pay the salaries or stop complaining that you lose all your talent. We should be devoting at least a few percent of GDP to pure research.
We are, it's just moved away from universities and into the private sector.
My $0.02 (STEM PhD with ~10 published articles, now I work for a big tech co in Silicon Valley): if you want to do better research, stop organizing university research into tiny little fiefdoms. Directors should be able to hire and supervise senior faculty. Senior faculty should be be able to hire and supervise junior faculty as well as grad students. There should be enough program management to get organizations with 100-500 total researchers on the same page and working together towards a common goal. Researchers should be free to actually switch groups instead of being shackled to a grant.
The current structure is literally a hold over from the Middle Ages. Because everyone is in charge, no one is charge and the brilliance is squandered instead of focused.
And we literally completely lost "literally" as well.
Maybe it's time for some new leadership in the Grammar Nazi camp?
Commonly-used software has bug(s), users impacted, company investigating fix. That story, and your local weather, right after this word from our sponsors.
There are two separate things: knowing what a framework does and knowing how it does it. In order to roll your own, you need to know both. But if things are documented right, the former is really enough.
Let me give a overly-trivial example (Python for simplicity, hardly matters):
from ecdsa import VerifyingKey
vk = VeryifyingKey.from_pem( VK_KEY_DATA )
assert vk.verify(signature, message):
What I would absolutely expect an engineer working on this code to understand is as follows:
(1) Elliptic Curve come in private/public pairs, the system depends on the authenticity of the public key and the confidentiality of the private key
(2) It is guaranteed that the message could only have been signed by the entity holding the private counterpart to VK_KEY_DATA.
(3) The verify function provides no guarantee on when this signature was produced. If you need proof of liveness, you need to compose this.
(4) The verify function provides no guarantee that a third party did not capture a valid signature, message tuple and pass it along.
What I would not require, by contrast, is an understanding of the mathematics of how EC curves provide these properties. That's may nice to have, but it really isn't necessary. So long as the engineer understands exactly what guarantees they get, the knowledge of how it's made is optional.
[ Of course, this is trivial example because ECDSA is a nearly perfect abstraction and its guarantees are very easy to understand and grok in their totality. Real frameworks/libraries are usually leaky and difficult to document precisely because they aren't formally specified. ]
You'd have to RTFA to find out. Or I'll help you: there is a little animation and so the second "+" doesn't register. It's as if you hit "1 + 23".
Every input device on planet earth has some maximum rate at which it can process events. If yours is slow, that's a performance problem -- in this case it looks like it was pretty crappy because the animation had to complete before you could enter the next thing.
Did you watch the same video I watched? Seemed pretty fascist to me.
If Tesla fired a bunch of workers for being pro-union, the union would file a complaint.
If Tesla fired a bunch of workers that were low performers, the union would file a complaint.
If Tesla fired a bunch of workers that were low performers but the reviews were {1%, 10%, 50%, 90%, 99%} biased against unionizers, the union would file a complaint.
There is literally no information to go on here besides our own biases. Of course, actually digging through hundreds of personnel files with dozens of performance reviews, correlating it with what the company thought, seeing if there are emails of improper motives, that would take a while and be fought. Best to stick to your gut instinct about evil companies or slacker workers or . . .
Per BTU? Practically nothing.
Certainly the total GHG potential of what you released by fracking NG and then burning it for heat/power is less than the end-to-end GHG potential of the equivalent in coal.
The energy of gravitational binding is necessarily negative. That is you say, if you have two objects near one another, you would have to inject positive work in order to separate them to infinity.
The most likely answer to the question about the 1st law of thermodynamics is that the entire universe is net zero energy, with the positive contributions from mass balanced out by the negative gravitational binding energy. Current cosmological calculations are consistent with this hypothesis, although it remains to be proven conclusively.
Or, as more commonly stated, the entire universe is a free lunch.