Hacker Newsnew | past | comments | ask | show | jobs | submit | KolibriFly's commentslogin

It's strange how much attention novel psychedelic treatments get compared with older, less glamorous interventions that already help a lot of people

People have been self medicating with shrooms and salvia since prehistoric times, perhaps reconsider what is novel?

Yeah, super weird how people want to get away from the "less glamorous" intervention of deliberate brain damage.

Exactly. Just like paracetamol and autism. Like that's a difficult decision, duh.

My point exactly. I am not saying psychedelics do not help people, they clearly help some people with some problems. But the balance of research and general interest is not proportional to how promising both paths already look. For example, which treatments are safer long term? It's unclear. At the same time it's clear that there can be unwanted long term side effects. In one very particular case, pregnant women that unfortunately do need something, we already know from physics and data on anesthesia that ECT is the better choice.

Bring back lobotomy!

I read it less as "this only helps veterans" and more as "veterans are the group this particular research and funding path is centered on"

It feels promising, but also exactly the kind of treatment that should move through careful clinical trials

This is exactly why Proton feels like the pragmatic path. Native ports are nice in theory, but PC games are rarely just one clean executable anymore

I have stopped playing native ports and just prefer Proton when I have the choice. Many devs using Unity & co. just tick the "export to Linux" option and never try the build, which is often much slower or bug ridden.

I was playing Project: Gorgon recently, I was about to refund because it ran terribly on my machine (despite the low end graphics), when I noticed it was using the native build, switched to Proton and got a 200% FPS boost.

As long as I can play on Linux, I don't care what translation layer it goes through.


I'd argue that "native" is much more of a state of mind than a clear delineation anyways.

Among many game developer studios, the Steamdeck is increasingly becoming the defacto low-spec hardware target. Running their game on a Steamdeck becomes a core part of the QA process, because there's a few million Steamdecks out there actively playing games, and if your game runs on a Steamdeck you basically know it'll also run on a very wide range of hardware configs.

So while the game might be targeting a different API than the standard ones exposed on Linux machines, a lot of games now are directly designing their software to make sure they run well on a Linux handheld. Meanwhile, Linux is adopting more and more features to better support this non-standard API set.

At a certain point I think we can just call Proton/WINE a 'native' API for gaming on Linux, and say that games developed with Proton/WINE in mind are native games.

Perhaps we're not at that point yet, but we might be there soon.


Disagree. The word "native" in a software execution context has a very specific meaning—it means that the software is running on the target hardware with no emulation, translation layer or modification by any middleware. Games running through Proton/WINE will never be native, by definition.

I'm not super sold on Wine/Proton being the solution to Linux gaming as it still leaves Microsoft in control of the future, but the distinction is quite murky. A lot of "native" ports also use translation layers internally to various degrees.

x86 bytecode isn't the native instruction set on any real hardware you're running games on either, just one of the lowest-level publicly exposed interfaces.

if it's the lowest level available, then it's as close to "native" as we can get, so therefore it has to qualify, if we want to consider anything at all to be running "natively"

Isn’t that moving the goalposts? If an API isn’t exposed for native code then maybe we should just accept that we can’t write native code anymore instead of stretching the definition.

From that point of view, native software effectively does not exist, and was long gone before the Linux project even started.

And exactly why Apple's push for Mac gaming (which still puts native ports as the ultimate goal and treats things like GPTK, despite having made it, only as "ways for developers to preview how the port would end up" and not intended for general consumer use) is never going to work, no matter how much cash they throw at it.

EA's horrible launcher comes to mind.

Yeah, PC games are like console cartridges. You plug them into a compatible slot and they work.

What? Look, things have gotten much better, but pc gaming, esp via proton is no where near as seamless as playing on console.

In fact, I went with console + linux laptop for ages simply because that combo excelled at their respective roles, were cheaper together than a gaming pc, and it 'just worked'.

I did eventually cave and build another gaming pc, but that was after I acknowledged that I could push out on the price / perf curve to something less 'optimal' (and it let me play with local LLMs)


Not the ideal path though - that's still source ports.

This is such a neat historical parallel

Primary energy comparisons can make fossil fuels look more "irreplaceable" than they are, because so much of the input energy is lost as heat before it becomes useful work


Factory games are weirdly good at teaching the "shape" of these systems


That must be an incredible place to grow up around


The odor point is interesting. I think a lot of people mentally picture refineries as visibly dirty and smelly by default, but a plant near dense urban/residential areas probably has very strong incentives to be almost boringly well-contained


If people from Houston in this thread are to be believed, those incentives don't seem to be strong enough in some places.


What always strikes me about refineries is how "simple" some of the core ideas are in isolation


Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: