It mostly works because the object you're sling-shotting with is moving relative to the initial origin of the probe - if you can line it up so the object is moving in the direction you want to accelerate in you can get it to "drag" your probe along a bit.
The end result is the probe isn't moving any "faster" leaving the slingshot object than it arrived from that object's point of view, but it may well be faster from the origin reference frame.
The thing is to remember that the bodies you're launching from, and then slingshotting against, are moving very fast relative to each other already. It's like throwing a bouncy-ball against a moving car - when it bounces off it may be moving faster relative to you than when you threw it, but it's actually a lower velocity relative to the moving car's reference frame.
Yeah, many of the theoretical solar sail ideas fall down on what I consider a useful "probe" is, and what it can mass. As mentioned in my other comment, if you define the "probe" to be "a single particle" we /already/ do this all the time in particle accelerators. But it's clearly not a useful "probe" I believe the original thought experiment implied. A few hundred grams of super thin solar sail material is still very much in the "Not A Probe" definition in my mind.
Plus even the best laser dispersion quickly gets significant at the distances required to give the sail the time to accelerate at such a low thrust.
It might help a bit, as you mentioned that Voyager is currently going about ~17km/s, so nearly 0.005% c, so it's already nearly 1/200th of the way there to our target of 1% c.
But then you're at a velocity so far beyond the escape velocity of most bodies you'd need to be skirting stars, then black holes to get anything more, and that's where it dives straight into "sci-fi" rather than anything even close to theoretically possible. How far away even if a body like that? Will this "probe" even survive such an encounter?
So even with that sort of slingshot it's well within the "Estimate Rough Error" of my intial numbers. They're "order of magnitude back-of-the-envelope calculations" of spherical spaceships in an already unrealistically biased to make the numbers smaller vacuum (just reaction mass, no thought of any mass of the engine or spacecraft body itself, or containing the reaction mass itself, or anything like that).
I probably should have stated my assumptions - in that "Can we accelerate a probe" I assumed that:
- The "probe" is a significant size - if we define a "probe" as a "Single Ion" then we already do that at CERN and similar pretty regularly - 1kg was my assumption of "Useful Probe Mass"
- "We" - in that "humans" as we know them today, preferably in the realisic age of civilizations as we know them, or even better within the lifetime of a currently living human.
Also there's different levels of "theoretical". VASIMIR has only ever been shown in lab settings, so still "theoretical" as a propulsion technology. something like Project Orion is "theoretical" in that it's never been built, but likely just an engineering effort. IKAROS showed solar sails are "possible", but so many orders of magnitude away from what would be required it'll still be a significant engineering and development effort to even show the same idea at the required scale is possible. Things like lasers as remote energy sources haven't really got off the drawing board. And then at the extreme we have "theoretical" ideas like fusion rockets, which are more "Not show to be /impossible/" rather than anything we could even start at really building today.
And each step along that "further out into theory" path means more risks, and more changes that method is shown to be less useful than really desired.
Space sails are super low thrust though, even lower than my VASIMIR example - so will take even longer to reach the desired speed - though they have the advantage of not having to carry the complex and heavy engine I ignored that in the rough estimates anyway.
So by the time they're theoretically close to the desired speed they'll be on the other side of the galaxy at least, even if it took millions of years to get there at the much slower average speed.
No, not even close. The issue is simply exhaust velocity and reaction mass, that leads us into the tyranny of the rocket equation - in that you have to carry that reaction mass with you and accelerate that mass too. Even if you had magic infinite energy - e.g. it's supplied externally by a laser or similar.
Using the theorized maximum of 31km/s exhaust velocity of project orion (much higher than any current high impulse propulsion technologies) you'd need to have thrown out something similar to 10^42 times the probe's mass out the back at that 31km/s velocity.
That means to accelerate a 1kg probe to 1%c you'd need to start with a spacecraft holding a reaction mass equivalent to a few trillion suns worth of mass.
Hardly seems worth it.
It's all about exhaust velocity - increase that and it scales down quickly. Using the theoretical max of 500km/s of VASIMIR for example means it's only 400x the mass of the probe of reaction mass - but that's still theory and max thrust limits means it'll take the order of millions of years to reach that sort of speed.
They're really simple - arguably the problem is people try to treat them as a single complex unit rather than just "5 junctions in a row". Trying to think of them as a whole is rather pointless and self defeating, as there's no real advantage to doing so.
Most people have no problems with the idea of a road network loop - such as around a block - but that's exactly the same thing from a driving point of view.
Even then the "reserved" section is a carve out guaranteed chunk to allow stuff that might need contiguous physical memory (display scan out buffers and page tables, for example) and similar.
The GPU can still happily use all the rest of the memory for other use cases - which tend to be the bulk of allocations anyway. Though there might be performance implications - for example "moving" buffer ownership to the GPU would need to evict CPU caches, and often 4k pages and tlb lookups can be a pretty inefficient situation for GPU-style accesses.
That's been pretty standard for any SoC for decades. And "differences" to apple's SoC are more implementation details.
Imgur were found to be in breach of the data collection laws before any "you must check IDs" laws were even discussed in parliament, let alone passed, where the guidance was pretty much "Don't get caught actively selling data you already know is from children". And even the punishment was pretty much writing a document of "we'll try not to do it quite so obviously next time", but they refused to do even that.
The "implied" link between their fines, them rejecting UK connections, and any new laws is very much a PR thing from imgur.
All the breathless online reporting seems to miss just how toothless the law was, and they still failed at following it.
Like I think the new verification laws are an unworkable mess at best, written by people with an idea similar to believing they could "ban one specific species of fish from UK territorial waters" by throwing the odd grenade in, but they're rather unrelated to what imgur actually did.
I find this amusing as Apple were the people I had direct interactions with that didn't run stuff like fuzzers or sanitizers as a matter of course - at least not in the situations I was involved with.
Though this was ~3 years ago now, and a lot of things have changed, but these tools were very much available and well known then - they aren't new. Though perhaps as they "knew" the project was coming to a close it wasn't a priority either?
It also might have fallen through the gaps due to the Apple internal/team culture - I worked for an external vendor, and we had to work against binary built framework dumps that didn't even allow us to enable things like address sanitizer completely either, and fuzzing difficult as you'd need to trace things through their opaque binary layers before it even reached our code.
Apple did have all our code though, it was very much an asymmetrical relationship, but if they were running such things as a matter of course in CI or similar you'd see that pattern in when they reported issues it caught, and the timings from time-of-bug-caused to time-of-report. It instead suggested any such runs were piecemeal and sporadic at best.
Though, it wouldn't really surprise me if they were being run and finding issues all the time, but they never actually got back to us. This certainly wouldn't be the first time we ran into "difficulties" due to the nature of the relationship and culture.
I remember this being a thing done a while back using linux's MTD/phram drivers - https://wiki.archlinux.org/title/Swap_on_video_RAM - not sure if that's still relevant though as I don't know how it'll interact with DRM and how it handles reserving some of the vram - the suggested limit using xorg.conf is probably pretty obsolete now.
That page also has a fuse filesystem implementation on top of opencl - https://github.com/Overv/vramfs - which may be more compatible.
A modern allocator with per-thread cache can satisfy some allocations in 20-30 cycles - dynamic dispatch can easily double that, even if the target is still in cache.
It's one of these things where it's extremely use case dependant - like many performance issues, you probably don't care about it - but when you do it matters.
And the ones who get the "payday" are just the ones we've heard of.
How many people didn't get media attention, don't have the ability (time/money) to sue, lost that case, and those where the intimidation and "punishment" was successful?
At some level the people doing this intimidation believe it'll be successful. Is that from experience?
But each new customer is still losing money. As I said, subsidized growth only matters if you can recoup those subsidies afterwards - and that's what I'm not sure will be true.
I think the idea of "all growth is good no matter the cost" has been taken to an extreme.
From what I've seen pretty much every company is limited by hardware supply, to the level where's there complaints from current customers about the speed of new customer growth is exceeding their ability to service them properly.
And "growth at all costs" makes sense if there's lock in and you can monetize those "now locked-in users" later - but that doesn't really seem true on the consumer side. It seems pretty trivial to switch out which model and provider on the consumer side.
Any "lock in" has then to be on the model or inference side, and that's still advancing in multiple areas from so many different sources I'm not sure I'm comfortable saying that will also be a "winner takes all" situation either.
My approach is generally "enjoy using it while it's cheap and subsidized, but understand that might not last forever". If it does remain cheap after the subsidies end, great, you can just keep using it. But if it doesn't and you've lost the ability to work without you'll be in for a world of hurt.
Get back to me when there's an AI company that's actually profitable and we can compare their service and pricing.
Claiming that there's some small subset of their services (like inference per token) that's "profitable" doesn't mean anything when it relies on everything else that company is still paying for. If you could make money from it at current prices - why aren't they?
Otherwise it's just "how much they're willing to subsidize".
For higher than audible frequency sample rates there's a good chance you can tell the difference. It often causes weird aliasing and harmonics in the more audible frequencies on "real" playback equipment. You can train yourself to recognize some of these and often pretty accurately identify the higher sample rate examples. You might even mentally associate those signs with "Higher Quality".
But it's arguably less accurate to the original recording.
Yeah, many of the things we consider part of what an "Operating System" provides to programs today were provided by DOS Extenders (or forwarded to something like windows if running under that).
DPMI was pretty much an "Operating System API/ABI".
While there's no central authority, both Oxford and Cambridge University press style guidelines recommend that.