The use case for this is similar to the cold boot attack, e.g. disk is encrypted but memory is not. (And I don't know how encrypted DRAM works, but I wouldn't be surprised if some implementations put the key in SRAM that can be dumped using this technique.) Anyway, there may be valuable secrets that exist in SRAM but but not on disk.
I'm not a physicist, but I took a class on special relativity in college, and I still remember some of it ... If I'm remembering it right, we still have conservation of momentum and energy in special relativity, with the caveat that these are defined differently than in classical mechanics. Specifically, E = γmc^2 and p = mvγ, where γ = 1 / sqrt(1 - v^2/c^2) and m is the invariant mass (aka the "rest mass"). [1] Note that when v=0 (so γ=1), this equation for momentum is the same as the classical p=mv, which is generally a good approximation when v << c.
So, using those relativistic definitions for energy and momentum, I think you're exactly right, at least up to the part about "since the final object is at rest". However:
- As I understand it, invariant mass, aka "rest mass" (which is equivalent to "rest energy", aka "rest mass energy"), is invariant, and it's the same before and after the collision, so the kinetic energy doesn't get "converted into rest mass energy". Rather, if the final object is at rest, then all of its kinetic energy has been radiated away; kinetic energy (E_K) is is total energy (E) minus rest energy (E_0 = mc^2, where m is invariant mass)
- I have no idea whether gravitational waves are the only way for the kinetic energy to be radiated away. I imagine other forms of energy could also be emitted.
- In order to know that the final object is at rest/has no kinetic energy (in an inertial frame), I worry that we might need to have specified more in the original question. In particular, I don't know how to handle spin. (I know that black holes have some concept of "spin", but I don't know if this is like rotational spin, or more like quantum mechanical spin, or something else, and I don't know how it figures into the black holes' total energy.) If we change the original question to say that the black holes are not spinning, then I think we can ignore this (since the collision is head-on).
You think that the farther in the future you go, the less likely it is that any existing population will know how to fix what breaks? That strikes me as oddly pessimistic, and frankly unlikely.
I wouldn't be so sure, it's wildly common. Reverse engineering products to figure out how to make them again is its own sub-industry in every manufacturing field, especially anything tool & die.
There's an enormous chasm between when companies started mass producing things and the digitization of blueprints. More often than not it isn't even the original company, it's one of their customer's customers 50+ years after they went out of business.
Im more convinced we are heading that way every year. Certainly not anytime soon, but 100, 200, 1000 years from now? Seems plausible to me. Most people don't even know how their house electricity system is setup or works, or how their plumbing system works despite being incredibly simple, not to mention more advanced technologies. We are surrounded by internal combustion engines and yet less and less people actually understand them each day and it becomes more and more specialized knowledge. How many people know how a refrigerator works despite being incredibly simple technology and the basics necessary to understand it covered by atleast freshman highschool science class if not earlier?
We have built a disposable society so people most people never have to learn how anything works. They press a switch or button and it doesn't work? Throw it away and buy a new mass-produced model. And as time goes on we only need less and less people to understand a technology to mass produce it and sell it.
What a strange attitude. It certainly is not anyone else's job to maintain the home I own and live in. That is my job. If something breaks, I don't get to tell someone else that they have not done their job. I am responsible for fixing it. Yes, I can delegate a specific fix to a professional electrician or plumber, but that is a project-by-project choice.
If people want to approach life by hiring out every little thing, they can certainly do so, but those choices do not make my home maintenance someone else's job.
Yeah, but he is extrapolating something going from common knowledge to specialist knowledge as a step towards it being something that nobody knows, and that's just not what it is at all.
It's not that I think that future generations are dumb or anything like that, it's just that the longer an assumption is held, the less likely people are to be prepared for it being invalidated.
Many of the people who designed our electrical infrastructure are still alive. Far fewer are needed to keep it running. If we must rethink our priors, I'd rather have both groups in the room while we do it.
With the state of how the ai agents stuff already is, if you don't think that most tech jobs will be automated away in our lifetime, I don't what to tell you.
Within 10-15 years, AI research automates itself and no one ever has a software engineering job ever again.
I think sometimes of how crazy it would be if we could send GPT 4.5 in the past somehow, what effect that could have, just a magical almost all knowing being from the future
Computing power requirements and the fact that my subjective appraisal of the performance of these LLMs doesn't match the insane scaling curves that AI companies put out showing that their capabilities double every 6 months. Even if a 100x increase in computing power could equal a software engineer (and that's far from certain), that would be more expensive than a software engineer.
But really the burden of proof is on you here since you are making extraordinary claims of AI superintelligence replacing all jobs in 10-15 years. You are making the trillion pound baby argument, so you need to back it up.
It's not, this isn't a lawsuit, it's a casual discussion, and I don't really care whether I'm convincing you or not, I'm taking about this because I enjoy it. I can tell you though that DeepSeek R1 & RL approaches do have shown the power to scale coding and reasoning much further without increasing model size or data requirements much, & that new improvements come non stop in the field from the billions being ingested and all the minds being focused on this all day long as it's so obvious to everyone that it's powerful
I feel like you're coming from a place where GPTs value lies only in coding. I use it for planning all the time, saving me hours per week.
For example, the security team gave me a list of 100s of policies that need to be implemented. I was able to dump that list in and get a rollout plan over the next two months in a matter of minutes. This would easily have taken me half a day before GPT.
Isn't that a bit pessimistic? Assuming machine natural language understanding and general reasoning improves dramatically (which seems possible, based on recent history), it is likely that (given that we still have the data) at some point in the future anyone will have the ability to acquire these skills, or that machine agents will be skilled enough to guide human or other types of agents to do things.
The post is about solar events, good luck getting machine agents working in case this happens...
It is pessimistic yes, but what in recent history did happen to not have a pessimistic outlook on things?
As far as I am aware, the vast majority of electrical components will still function during an extreme solar particle event. The major risk is to electrical distribution, but, as you are surely aware, there are other ways to access electricity off grid.
It strikes me as too bad that this API is so imperative. You can see a pattern over and over in the README where they have `do` blocks, in which they clear some global state (`initialize-prolog`), then add some assertions back into that global state (via side-effectful API calls), and finally run a query (which is implicitly a query on the state that's been built up). Why not represent the knowledge base as a normal Clojure data structure, rather than as the effect of a sequence of API calls? Then it can be passed in by the caller alongside the query, instead of being stored as mutable state.
This isn't just a style thing, either; there are consequences. REPL-driven development loses a lot of its slickness when some expressions can only be eval'd in a special context.
Also, what am I supposed to do if two different parts of my program want to use Clolog? If I'm using Clolog, and one of my dependencies is using it too, will we end up trashing each other's global state? (The case of external dependencies is just an example. Let's say I have an application that sets up the Clolog state and runs a query. Part of the setup involves calls to other parts of my application. At the time the code was written, those other parts didn't use Clolog, but now they do, and there's a bug, because those other parts are trashing the Clolog state that their caller had set up, before it runs its query.) Of course, you could get around this by adding something like a dynamically bound variable that points to the instance of state to use, but at that point you're jumping through hoops to support a subpar (stateful) paradigm that Clojure developers expect to be free of.
> a sort of homoiconicity of code and data (hence JSON as a data format)
I get that "sort of" was an attempt to hedge, but really, this isn't even close. Homoiconicity here would be if all javascript source files were valid JSON documents. A weaker version would be if it were common to use JSON to represent an arbitrary javascript program, but I've never heard of that, either. (For a good explanation of this weaker sense of homoiconicity, this stackoverflow page [1] is pretty good.)
To use Clojure as an example of a language that is homoiconic, you can take any Clojure source file, send it to an EDN parser (EDN being Clojure's equivalent of JSON), and not only will parsing succeed, but the result will be a complete representation of the program (you could execute it if you wanted to). In contrast, if you try to send JS to a JSON parser, you'll get an error as soon as it hits a function definition, or a for loop, or an operator, or whatever.
I don't see it in the Android app either, and I find the original claim very hard to believe in the first place, since that would be a weird piece of information for Signal to reveal about a user.
Apologies for the mistake. I'm running a Signal fork called Molly[0]; the feature I mentioned seems to be unique to that fork, based on a search of the code.
However, it shows that the data is being provided to the client by the server, in some way. This is a guess, but it may be because sending clients have to encrypt with a key for each device.
A superellipse is only a squircle if a and b are 1. As with squares and rectangles, all squircles are superellipses but not all superellipses are squircles.
If a and b are equal* (not just 1). A circle is a special case of ellipse where a and b are equal and the eccentricity is 0. This is the same principle.
Does anyone else find it suspicious that the author was using so many workspaces on sway? I have to wonder if they're not making good use of sway's tabbed and stacked containers ...
> If you don't find yourself constantly swapping between fullscreen and non-fullscreen views and running out of workspaces, you don't have very many windows open. Don't even get me started on tabbed/stacked layouts with nested containers, the least ergonomic Band-Aid™ for the space issue I've ever seen.
On the contrary: I think this author really ought to get started on tabbed/stacking layouts! Constantly swapping between fullscreen and non-fullscreen views, like running out of workspaces, definitely sounds like an antipattern to me. I don't believe that the number of windows is the problem here.
If I'm deep into something, I might have 10 or more windows open, all on one workspace, on a 13" 1080p laptop panel. Of course, not all of the windows are visible at once. A common pattern for me is to have most of my screen taken up by a container split "horizontally" (meaning into a left side and a right side), where each side can be a tabbed container containing several windows. For example, I often have Emacs on the left, and several tabbed terminals (including man pages) on the right. Maybe some of those terminal tabs on the right are split "vertically" into a top and a bottom terminal (e.g. for a shell prompt on top and man page on bottom). Outside of this big left-right split container, which fills almost the whole screen when it's visible, I'll usually have some browser windows open. If it's just one browser window, I'll put it and the big-left-right-split (BLRS) in a stacking container. This way, you can think of the browser as being "above" the BLRS, and you can get there and back by moving the focus up and down again. It's like each stacked item (the browser and the BLRS) gets its own workspace, in that they each take up nearly the full screen when visible, but actually they're both on the same workspace, and the only cost is the loss of one title-bar's height of screen space. Then, if I want more browser windows, I can split the existing one into its own tabbed container. (I use both WM tabs and browser tabs, just like I used to use multiple browser windows on one workspace with Gnome.)
Basically, as my number of windows grows, things become (slightly!) more nested, rather than being ejected into surrounding workspaces. The trick to making this ergonomic is to choose what to stack vs tab so as to allow you to flip back and forth between (at least) any two windows with just a couple keys. (I also have two keybindings to split a container and immediately make it stacking or tabbed, and also two keybindings to focus parent-wards/child-wards. Then, you can easily jump from a window in the middle of a tabbed container on the right of the screen to the window on the left half of the screen---you just focus parent-wards then left (two keys). To get back, just focus right (one key).)
I should also add that I haven't really seen any problems with apps behaving badly when being resized, including Firefox. Maybe that's because my workflow mostly looks and feels like "slots" of a few different sizes (roughly full screen, half screen, quarter screen), and adding new windows to, or moving windows between, these slots is never going to change the size of the slots or the windows displayed in them. In fact, with traditional floating window managers, when has resizing a Firefox window ever caused me to lose my place in the page? Only when I make it super unusably narrow, or short, or both, and then expand it again. This is what would happen if you open a bunch of windows all in horizontal and/or vertical splits, with no stacking or tabbed containers! But why would you do that?
Well, if you remove the choice, that can actually sacrifice the ergonomics GP described, because of one of the important differences between stacked and tabbed: directionality.
Tabs are oriented along a horizontal axis; as with hsplits, you move through them by moving the focus left and right. Stacks are oriented along a vertical axis; as with vsplits, you move through them by moving the focus up and down. The reason you want the ability to choose between the two options is (to continue parent's quote of GP) "to allow you to flip back and forth between [relevant pairs of] windows with just a couple keys". To reuse (and better explain) the example from GP:
This is a root container whose two children are "Tabbed Browsers" and "hsplit of 'emacs' and 'a tabbed container with terminals'". (This root container is a stacking container, and the browsers' part only takes up about one title-bar-height on the screen because something in the hsplit has focus, so the hsplit gets all of the space and the actual content of the browser windows are not currently visible.) The reason it's stacking, and not tabbed, is because this way I can flip back and forth between any browser and any of the other windows with just one key per direction ("focus up" to get to whichever of the browsers was last focused, "focus down" to get back to whichever of the windows in the hsplit was last focused). Additionally, I can get back and forth between emacs and a specific tabbed term (the left-most one) with one key per direction ("focus right" and "focus left", of course), and I can get back and forth between emacs and any of the terms with 1+2=3 keys round-trip ("focus right" to get from emacs to whichever of the tabbed terms last had focus, "focus parent-wards then left" to get back to emacs). Critically, if you were to change any single one of the stacked containers in this layout to tabbed, or any of the tabbed containers to stacked, then you would be sacrificing at least one of these three properties.
So, the choice between stacking and tabbed matters. I'm not saying you can't have this choice in a scrolling tiling window manager. (Does Niri have stacking and tabbed containers? I hope so.) I'm also not saying that you or anyone else has to want to make that choice (it's okay to prefer a "simpler model" where you scroll around to get to all of your windows). What I am saying is that the author of TFA thinks that with traditional tiling window managers like sway, you can't have "very many windows open" without "constantly swapping between fullscreen and non-fullscreen views and running out of workspaces", and this is simply not true. (Perhaps worse, in the next sentence, they dismiss the solution out of hand by saying "don't get me started" on nested tabbed/stacking containers, because they're "the least ergonomic Band-Aid™ for the space issue I've ever seen", but it seems to me that declining to give a full treatment to that subject may actually be why the author's never seen it done ergonomically. But now I'm speculating.)
------
BTW, since anyone still reading is probably a completist: at the top, I said that directionality was "one of the" important differences between tabbed and stacking containers. The other one is how much space their title-bar areas take up vs. how many children they have. Stacking containers are O(n) in the number of children; tabbed containers are O(1). Interestingly, combining this with the directionality property yields an interesting result: in sway, there is a sort of asymmetry between the horizontal and vertical dimensions.
reply