Also... they DID sell that seat. To the person that bought it, and paid for it, and then didn't use it. They didn't cost the airline any money. They paid for the seat. They don't get the money back for the seat they don't use. The airline keeps the money for it, while not incurring the costs of filling it.
Not quite. Yes, they show that superluminal (faster than light) warp drives still require negative energy, though dramatically less than previously calculated, which is what your quote refers to.
However, TFA featured on HN focuses on a different finding in the same paper - that positive-energy warp drive solutions exist, that still warp spacetime, but are necessarily sub-lightspeed. This is still useful, because it's still a potential avenue on how to actually approach accelerating something to some large fraction of c. These also solve a lot of the immediate objections to prior art, such as being delicately between event horizons of a black/white (ish) hole pair, the accompanying hawking radiation, and causality paradoxes.
The “warp shell allows one to modify the state of spacetime inside it…the time in the inner region may go faster or slower than it would go without the shell” [1]. Being “internally moving shells of normal or exotic matter,” these warp shells “do not have any natural way of changing their velocities. They are just like any other types of inertially moving objects. Similarly, just like for any other massive object, achieving a certain velocity for a warp drive requires an externally applied force or, more practically, some form of propulsion.”
Subliminal warp drives let a timelike passenger compress the subjective experience of the journey. It doesn’t change the journey’s propulsion requirements. Think: cryosleep benefits from science fiction, not Star Trek-esque warp.
Would a sub light warp drive be much different performance wise from, say, a fusion torch engine with insane iSP like the fictional Epstein drive from The Expanse?
Of course if we figured out how to build a sub light warp before figuring out how to build a fusion torch wouldn’t that be interesting?
So many more questions. Would you experience time dilation? When you kicked off the drive what would your momentum be relative to your destination? Would speeds like 99.99999% the speed of light be possible with enough energy? Of course you would probably be energy limited just like with crazy high iSP drives.
It’s possible that sub light warp drives are possible but FTL still just isn’t, or would require ludicrous “convert the mass of Jupiter into raw energy” levels of power.
Also if anything like this is possible it makes the Fermi paradox even more “real.” Right now the crazy difficulty of interstellar flight with reaction drives provides a solid chunk of a default explanation. If you could hit even say 20% light speed (effective velocity) you could hop between stars in practical lengths of time.
If someone builds any kind of working warp drive I’m going with either we are alone in at least our galaxy or UFOs are aliens, not much middle ground.
> Would a sub light warp drive be much different performance wise from, say, a fusion torch engine with insane iSP
Yes.
The “warp shell allows one to modify the state of spacetime inside it…the time in the inner region may go faster or slower than it would go without the shell” [1]. It is not a system of propulsion.
That said, the paper does hint at forming “a region within a subliminal warp drive which is similar to ergospheres of spinning black holes” for use “as an efficient energy storage” and “wherein black hole-like regions of the spacetime may be used to produce accretion power” for “both a source of energy and a source of propulsion.”
> Would you experience time dilation?
Theoretically, not sure. Practically, yes: you would appear to an outside observer to be travelling subliminally.
> When you kicked off the drive what would your momentum be relative to your destination?
Whatever it was immediately before.
> Would speeds like 99.99999% the speed of light be possible with enough energy?
Makes sense. Humans are really bad at perceiving the environmental noise floor. Our brains just tune it out, but it is has a huge impact on your perception of the loudness of fans that you've strapped to your face.
I can certainly see things like this causing a lot of unintended consequences. "It speeds up when I play loud music" is going to confuse many who don't know about this "feature".
Raivo OTP (written by security researcher Tijme Gommers, who really should know better, or just didn't care) got sold to Mobime (some guy in Morocco as far as I can tell).
I'm in the exact same situation. I'm still on 7 (the last fully local version) but the cracks are starting to show. I can forgive them for iOS forcing you onto their update treadmill but they've intentionally crippled the Firefox extension for this version too, and it flat doesn't work on windows anymore and it's not like Windows or Firefox are deprecating their APIs all of the time.
Feels like people calling bad scrolling and other jitter "janky" to just mean that it's a bit crap and people deciding that "jank" is a technical term. No buddy jank just means jank and slop just means slop. This isn't a "new term".
For something user facing sure but trying to debug why _sometimes_ my grep job hangs with large data dumps because my popen3 didn't know to consume from stderr because of your whimsicle message would be pretty rage inducing
Pretty much your fault entirely for choosing to use my tool but not reading at least the README.md, which would explicitly state that there might be achievement texts on stderr. Anyway why output that stuff on the standard streams anyway when every modern OS has a perfectly fine window popup functionality with associated sound effects.
If you've got Python, you shouldn't be running grep within it, just open the file with Python and search through it in the usual ways. Far less flaky than a subprocess.
Shouldn't, sure. But people use software in all kinds of sub-optimal ways, and it would behoove an author to make sure that it doesn't fail dramatically when this happens.
I'm not even sure it's suboptimal to shell out to grep instead of writing a bespoke search in Python. It would depend on the amount of data I'm sifting through.
You misunderstand entirely how much the author of any software with "achievements" cares about whether it works well in shell scripts and/or from python.
I love the fancy modern type systems and all of the superpowers that they give you. But this is an area that I feel isn't adequately explored.
If you call a function that calls a function that has side effects, or that closes the file descriptor you're using, or could panic, or that needs global shared state, or spins up a thread, or allocates, we don't have a good way to deal with that. There are some partial and underutilised solutions like monadic IO and linear/affine types and, uh, not having panics. I have some (bad) ideas but I think this is a space that's worth playing in.
isnt this the whole point of what rust is trying to accomplish? i havent yet worked with rust but from what i hear they make it very hard (impossible?) to have memory issues and things like deadlocks. sounds great in theory but no idea if this is the reality of using it
I had the same thought years ago, I think some people have looked into it a little, but nothing popular yet.
Imagine if you could look at a function, and know, undeniably - this, and anything it can call, absolutely cannot alter the file system directly or make a network call or spawn a process. Maybe instead of just types, you need to supply capabilities (much like interfaces on classes). Sounds like it could be a real pain. Would make auditing easier though.
I've been waiting for functional programming to have its day for more than 20 years. It just seems fundamentally at odds with how most people want to work.
You can make individual functions pure in any language, but do many languages enforce this at a core level? Or we have to behave ourselves and hope nothing we call is changed by another programmer later?
Capabilities help a lot if you just want to permit/deny the action. But maybe I want to know more than "can it allocate", I also want to be able to pass in an arena to make it allocate in a particular place and I might want that to be different in different parts of the code. Generics sort of help here if you want to explicitly thread your allocator all over the place like Zig but allocation is so common in normal code that ergonomically I want it to be invisible in the common case and controllable in the uncommon case
How about a spawning a separate process and using seccomp, or having the child process run as a different user perhaps?
There are a couple of advantages to doing it through the OS. For one thing, the implementation is shared across programming languages. For another thing, it's potentially more secure against an attacker trying to inject code.
I guess the disadvantage of doing it at the OS level is that you might have to write OS-specific code.
I think that mostly works (as an aside, last time I looked at this in Windows, we couldn't do something like sudo reliably because there was no secure way to provide the password without user interaction - it seems they've just released sudo for Windows in Feb this year). The OS can support this like how a mobile OS limits the capabilities of apps, which is more secure from a final standpoint.
But I was also thinking of the development and refactoring side of things. Guarantees and assurances. Sometimes I know the generic code I wrote is 'OK' but the C# compiler says no - you're not being specific enough, I can't cast that - so I have to do better. A while ago I was trying to track down programs that loaded data from certain network shares, and it was a bit rough because these calls were all very deep, and very occasional. Traces (or blocks) of system calls only work when the code fires, but my task was to find and replace them all, so we could delete the share (for various reasons string searches only got part of the way). If 'network access' was tagged at a high level, I could follow the trail to see what we actually access and report on that. We had a similar issue identifying jobs that called out to external APIs. We left a log running for a while to catch some, but some only run a few times a year and we didn't have that long. Adding a firewall exception later could take days and these jobs have turnaround times.
I don't know if this is at all feasible. It's just some thoughts I had back then.
There have been papers that limit the capabilities of a program within a certain context (i.e., within a function), some of which were implemented at the OS level and enforced with hardware protection (e.g., address space isolation).
The difficulty is that doing this sensibly requires new OS abstractions. It's one thing to put one in a research paper, but it's really tough to get this kind of thing into an OS nowadays. Another difficulty is OS level abstractions, with a few exceptions, cannot be used without a system call, which is cheaper than it used to be but much more expensive than just a function call.
A third problem is just that the programming language has a lot more semantic information, or at least it _can_ have a lot more semantic information, than can be fluently transmitted to the OS. There are approaches to deal with this (like having a richer OS / user land interface, almost impossible to get into an OS). In general, plugging into and extending the type system of some user land is probably going to be much easier route to take.
If the research world worked differently than it does, I'd have loved to continue previous explorations on OS / userland interfaces.
