[HN Gopher] AAA Gaming on Asahi Linux
___________________________________________________________________
AAA Gaming on Asahi Linux
Author : 6a74
Score : 877 points
Date : 2024-10-10 14:16 UTC (1 days ago)
(HTM) web link (rosenzweig.io)
(TXT) w3m dump (rosenzweig.io)
| psanford wrote:
| I'm a little sad that this has seemingly taken precedence over
| all other hardware support. M3 support, dp-alt mode, making the
| microphone work are all things that I was hoping were going to
| land in the past year.
| floydnoel wrote:
| I'm aware of no better way to see your desired features land in
| open source than to build them yourself. That is the power of
| open source, nobody can stop you!
| pbasista wrote:
| I understand the sentiment. But the people who could work on
| the Asahi Linux graphics stack are generally not the same as
| the people who could e.g. bring up Asahi Linux on M3 chips.
|
| I would not consider the lack of activity in some Asahi Linux
| areas to be a conflict of priorities. It is in my opinion
| mostly a result of these lacking areas naturally attracting
| less developers capable of moving them forward.
| porphyra wrote:
| The M3 GPU is a lot different and has a bunch of new features
| like ray tracing, so the super talented team working on the
| Asahi Linux graphics stack might have a lot of work ahead of
| them to support the M3's GPU fully as well.
|
| God I wish I was smart enough to help out with Asahi Linux...
| nxobject wrote:
| Chipping into their Patreon helped me feel at peace with
| not being smart enough!
| talldayo wrote:
| It's an Apple chip with no documentation and zero existent
| driver code to reference. You _have_ to set realistic
| expectations here, and acknowledge that not every contributor
| is going to have the domain-specific knowledge required to make
| everything work. It 's nothing short of a divine miracle that
| it has working Vulkan drivers you can download within a half-
| decade of it's release.
|
| If you want more, you'll have to take it up with Tim Cook or
| God (both have a nasty habit of ignoring us little guys). Also
| an option: not using a laptop that treats Linux as a threat to
| it's business model.
| WD-42 wrote:
| I'm not sure why you are being downvoted. This is the truth
| people who buy Apple hardware need to hear.
| dadoum wrote:
| Alyssa Rosenzweig already talked a bit about that on her
| Mastodon. She said that after having worked to implement a GPU
| drivers, it was annoying that she never had the time to quite
| finish them. On each device release, she had to support the new
| device instead of polishing what she got.
| vincentpants wrote:
| AFAIK the M3 is going to take a lot longer as the asahi team
| leverages apple silicon in their CI which means mac mini
| servers and the M3 generation never got their mac mini. Of all
| the generations to finally take the plunge into apple silicon,
| I had to choose the weird one... (typing this on an M3 mbair
| and not on linux sigh)
|
| Ah yeah, here's the post:
| https://social.treehouse.systems/@marcan/112277289414246878
| WD-42 wrote:
| Good grief what an uphill battle. It's amazing there are any
| devs willing to put up with Apple hardware at all.
| opan wrote:
| Have you considered selling your machine and getting an M2 of
| some sort?
| WD-42 wrote:
| I mean this is the nature of the beast with arm and apple. It's
| a closed system. There are some devs that are going to be
| willing to go through the effort just for the challenge of it,
| but most are just going to use x86/linux because you don't have
| to actively fight against the vendor.
| anotherhue wrote:
| Incredible work. May I also interest you in retrowin32
| https://github.com/evmar/retrowin32/blob/main/README.md
|
| Which is an attempt to collapse the stack so that fewer
| translation and virtualisation stages are needed.
| bni wrote:
| This is great, hope it takes off
| bee_rider wrote:
| The M-series chips from Apple have some special hardware to help
| emulate x86 with near-native performance, right? I wonder if they
| take advantage of those features (actually I forget exactly what
| the features were).
|
| I mean this is an incredible achievement either way. _Everything_
| is emulated, but they are still running AAA games. Wow.
| captn3m0 wrote:
| Rosetta 2:
| https://en.wikipedia.org/wiki/Rosetta_(software)#Rosetta_2
| vyskocilm wrote:
| I believe libkrun is the tech behind.
|
| https://fosstodon.org/@slp/113283657607783321
|
| Sergio Lopez has more info in his blog
|
| https://sinrega.org/2024-03-06-enabling-containers-gpu-macos...
|
| https://sinrega.org/2023-10-06-using-microvms-for-gaming-on-...
| saagarjha wrote:
| No reason they can't.
| bee_rider wrote:
| If every layer of abstraction and emulation is set up to
| allow it to pass through. It still seems really impressive to
| me, like lining up a bunch of targets and shooting an arrow
| through to get multiple bullseyes or something, haha.
| dontdoxxme wrote:
| Hardly, the benefit of binary is if everything lines up
| once, it always will. It's not an analog world with pesky
| things like wind resistance.
| thfuran wrote:
| Maybe if you happen to own the control stack from
| hardware, OS, drivers, to client software and are willing
| to never change any of it once you get things lined up.
| saagarjha wrote:
| It's not really all that hard
| ramon156 wrote:
| Would you say this is not impressive work? Or how come
| you're saying it's not hard?
| rowanG077 wrote:
| Why not? In fact they are using it right now.
| bee_rider wrote:
| I think the comment was saying "there isn't any reason they
| can't." Which is true in theory, but in the practice it
| seems to be a lot of stuff to line up.
| sumuyuda wrote:
| They are using it:
|
| Other than the page size issue, FEX and Rosetta are comparable
| technologies (both are emulators, despite what Apple marketing
| might have you believe). Both FEX and Rosetta use the unique
| Apple Silicon CPU feature that is most important for x86/x86_64
| emulation performance: TSO mode. Thanks to this feature, FEX
| can offer fast and accurate x86/x86_64 emulation on Apple
| Silicon systems.
|
| From: https://docs.fedoraproject.org/en-US/fedora-asahi-
| remix/x86-...
| spease wrote:
| This is super cool.
|
| So, wait, does this mean that gaming is _better_ on Linux, on a
| Mac?
| ojdon wrote:
| Yeah it has been for a while. The steam deck runs Linux out of
| the box.
|
| Valve and open source devs have put a lot of effort over the
| years on projects like Photon which is a translation layer for
| Windows games.
| brookman64k wrote:
| Proton, not Photon. ;-) Here is a list with games and their
| support status: https://www.protondb.com/
| zdragnar wrote:
| The question was "better on Linux _on a Mac_ ", meaning
| specifically Asahi Linux.
|
| The correct answer is no, not yet anyway.
|
| Linux running on x86 with proton is still the bee's knees for
| most games though.
| spease wrote:
| > on a Mac
|
| Right. It sounds like the Asahi devs have implemented APIs
| which aren't available under stock MacOS.
|
| Back when I was actively developing for Freespace, we had a
| Linux port that had a better framerate than Windows (the
| game's original platform).
| fl0id wrote:
| Afaik they are emulating, which you can do on macOS too.
| Still great that it works with Linux
| theLiminator wrote:
| Better on Linux on mac (as compared to macos) maybe?
| hu3 wrote:
| I've been gaming on Linux since Warcraft 3 days.
|
| Wine is wonderful and with Valve's help it only got better.
|
| But why would gaming on a mac be better? Maybe one day, but for
| now:
|
| FTA: "While many games are playable, newer AAA titles don't hit
| 60fps yet."
| Wowfunhappy wrote:
| I read the GP differently. I think they meant: if you are on
| a Mac computer, is gaming better under Linux vs macOS?
|
| I think the answer might be yes, because it's possible to
| play so many more titles!
| GeekyBear wrote:
| Game emulation isn't a Linux only thing.
| talldayo wrote:
| But if anyone can name a non-Windows platform that does
| it better, I'll wait!
| Wowfunhappy wrote:
| Is there a way to run Control or Cyberpunk on macOS?
| fl0id wrote:
| Yes. Haven't tried those games, but on apple silicon
| whisky app emulates with gameporting toolkit +
| wine/proton. For intel silicon I think it was also
| possible but not sure.
| Wowfunhappy wrote:
| Oh, wow, I did not realize how many games worked with
| this:
|
| https://docs.getwhisky.app/game-support/index.html
|
| I had assumed the lack of Vulkan on macOS was a major
| issue. Apparently not!
| fl0id wrote:
| Yeah,can't tell you how it works exactly but it's quite
| good
| wsc981 wrote:
| Cause MoltenVK [1] is used, I think.
|
| ---
|
| [1]: https://github.com/KhronosGroup/MoltenVK
| GeekyBear wrote:
| Not really.
|
| PC games use DirectX as their graphics API, so you need
| something that can translate from DirectX to the native
| graphics API your OS is running.
|
| On MacOS you'd be translating from DirectX to Metal and
| Apple provides the emulation software (D3DMetal) as part
| of the Game Porting Toolkit.
|
| On a Steam Deck, Proton uses Vulkan on Linux as the
| native graphics API, so in that case you are translating
| from DirectX to Vulkan.
|
| > DXVK (which translates Direct3D 8, 9, 10 and 11 calls
| to Vulkan on the fly), vkd3d-proton (which translates
| Direct3D 12 to Vulkan)
|
| https://emulation.gametechwiki.com/index.php/Proton
| outworlder wrote:
| > PC games use DirectX as their graphics API
|
| You are forgetting the increasing number of titles
| targeting Vulkan directly.
| GeekyBear wrote:
| That is an extremely niche use case on Windows.
| MobiusHorizons wrote:
| That's true, but many titles are 32bit and Apple removed
| 32 bit support, causing these titles not to run. It's a
| real bummer, because there is no technical limitation.
| GeekyBear wrote:
| Crossover and Whisky run 32 bit PC games just fine.
| sleepycatgirl wrote:
| That's why the new WoW64 mode in wine is exciting. Even
| if the system doesn't support 32 bit binaries, you can
| still run 32bit windows software
| valianteffort wrote:
| I played through the entirety of Elden Ring and its DLC on
| my macbook pro through GPTK which is a pretty modern and
| demanding game. Don't think that would be possible on
| asahi.
| endorphine wrote:
| Do you use Wine or Proton?
| cdogl wrote:
| > FTA: "While many games are playable, newer AAA titles don't
| hit 60fps yet."
|
| You're lucky to get 60fps playing a fairly undemanding game
| on MacOS, even on hardware that is otherwise a dream.
|
| For example, Baldur's Gate 3 is barely playable on my M3
| MacBook Pro at well below native resolution with all settings
| turned down. It's a brilliant game but hardly cutting edge
| graphically.
| GeekyBear wrote:
| Emulation has unavoidable overhead.
|
| For instance, Alyssa mentions in this post that most emulated
| games will need at least 16 Gigs of RAM at minimum.
|
| In addition, native ARM games on MacOS don't have the
| additional overhead of emulating a different CPU architecture
| and Graphics API.
|
| However, that doesn't take away from this emulated support
| being an amazing achievement.
| jillesvangurp wrote:
| > most emulated games will need at least 16 Gigs of RAM at
| minimum
|
| That's because the RAM is shared with the GPU and most of
| these games would require a GPU with at least 2-4GB on top of
| the normal system requirement to have at least 8GB. So, 8GB
| of RAM would be cutting it close on a mac since part of that
| would have to be sacrificed for the GPU.
| GeekyBear wrote:
| Alyssa lays out the reasoning in the linked blog post.
|
| They are running emulated games in their own separate
| virtual machine, because Intel games expect a 4k page size
| and the OS is running with a 16k page size.
|
| Virtual Machines require their own chunk if memory
| overhead, so the resource usage can't help being higher
| than a native MacOS game's would be.
| nottorp wrote:
| > at least 16 Gigs of RAM at minimum.
|
| And the minimum is pretty minimum. A 16 Gb arm mac will go
| into yellow memory pressure while running emulated games,
| I've noticed.
| m463 wrote:
| If you mean "I have a mac, is it better to run linux to game?"
|
| Then there's a case for it, since you can run AAA games that
| apple + macos doesn't support / allow.
| GeekyBear wrote:
| Nothing prevents you from running games under emulation on
| MacOS.
|
| Apple and Wine provide the tools, and apps like Whisky make
| them easy to use.
|
| > Essentially, this app combines multiple translation layers
| into a single translation tool. It uses Wine, a translation
| layer that allows Windows apps and games to run on POSIX-
| based operating systems, like macOS and Linux. It also uses
| Rosetta and the Game Porting Toolkit, which are two official
| Apple tools that allow x86 programs to run on Apple Silicon
| and serve as a framework for porting Windows games to macOS,
| respectively.
|
| Normally, this sort of process would require users to
| manually port games to Mac. But by combining Wine, Rosetta,
| and the Game Porting Toolkit, this can all happen
| automatically.
|
| https://www.xda-developers.com/hands-on-whisky-macos-gaming/
|
| However, as aleays, running games under emulation has a
| performance cost.
| kergonath wrote:
| You'd need to compare with what can be done on macOS
| including with things like crossover and the GPT. AFAICT, the
| Linux side is making progress, but still more games can be
| run from macOS.
| talldayo wrote:
| > AFAICT, the Linux side is making progress, but still more
| games can be run from macOS.
|
| I don't believe that's true. According to ProtonDB, 80% of
| the top-1000 most-played games on Steam are confirmed
| working on Linux: https://www.protondb.com/dashboard
|
| I haven't seen any source documenting nearly similar
| success rates with Mac but I also haven't seriously tried
| gaming on Apple Silicon.
| whimsicalism wrote:
| steam deck is x86
| talldayo wrote:
| What a coincidence! So are a variety of Macs that shipped
| with hardware supporting Linux and Vulkan on day 1.
| russelg wrote:
| Yes, but this thread is about Asahi Linux, which is for M
| series Macbooks. Not x86.
| achandlerwhite wrote:
| The Mac efforts rely on MoltenVK for and Vulkan needs which
| itself relies on the underlying Metal API. As I understand
| it Asahi/Honeykrisp driver for Vulkan does not rely on the
| Metal API so it actually can do more conformant Vulkan than
| Crossover/Whisky can. For example tranform feedback and
| other geometry shader stuff will work on Asahi. MoltenVK is
| working on it, but not there yet.
| dagmx wrote:
| You're ignoring D3DMetal which is what is most commonly
| going to be used and equivalent to what Proton is doing
| to convert D3D to VK.
|
| Most games are D3D. A very small minority are Vulkan from
| the get go.
| achandlerwhite wrote:
| On many games I have tried DX => DXVK => MoltenVk =>
| Metal is significantly faster than DX => D3DMetal. For
| example XCOM2 is about twice the frames per second (yeah
| it has an official Mac version but it is even slower).
| whimsicalism wrote:
| I will have to check this newest development out, but as
| someone who dual boots Asahi and MacOS - up until now MacOS
| with Crossover has definitely been the best experience, if you
| are willing to pay
| dagmx wrote:
| No, you'll still get better performance, more features
| supported and lower overhead running with Game Porting Toolkit
| currently.
|
| That includes raytracing support and heterogeneous paging
| support which are two things Alyssa calls out explicitly
| herself. Not to mention the VM overhead.
|
| That's not to say Alyssa's work is not very impressive. It is.
| But GPTk is still ahead.
|
| That's not even including the other aspects of Mac support that
| Asahi still needs to get to. Again, very impressive work, but
| the answer to your question is No.
| risho wrote:
| i haven't tested it extensively but i tried dark souls 2 on
| parallels and there were vertex explosions making it
| unplayable, using crossover and whisky it was a jittery laggy
| mess. after seeing alyssa's talk i decided to load up asahi
| and it ran perfectly max resolution 60 fps locked. gaming on
| macos in my experience has been unplayable to the point where
| i gave up even trying. after my experience with ds2 i think
| that it's going to be significantly better.
| dagmx wrote:
| What backend did you use? You get very different results if
| it defaults to MoltenVK versus d3dmetal
|
| DS2 comes in both DX9 and DX11 flavours. The latter should
| work better with d3dmetal and is more comparable to what
| proton is doing.
| risho wrote:
| i never tried to change between dx9 and 11 in parallels
| or crossover/whisky since i didn't know that was
| possible, so i was using whatever is default. that said i
| tried messing with all of the wine settings and it didn't
| seem to make a difference. i even messed with stuff like
| esync and msync (or whatever they were).
| nottorp wrote:
| How well do soulsbornes run on windows anyway?
|
| My strong conviction is that From is pretty much
| technically inept when it comes to Windows ports so I just
| play their titles on console...
|
| An emulated title that is in itself a not so great port
| will have trouble ofc...
| risho wrote:
| it works on asahi without issue. that is with x86 to arm
| translation, directx to vulkan translation, windows to
| linux translation and 4k page to 16k page translation
| running in a virtual machine.
|
| as for how well fromsoft games run on windows you might
| have been right 12 years ago when dark souls 1 came out
| initially. it was a mess at the time, but souls games
| have been running just fine on windows(and linux for that
| matter) for years. it's only on macos that it is a mess.
| this has nothing to do with fromsoft and everything to do
| with macos.
| mikhael28 wrote:
| Fantastic! A great proof of concept on Linux - lots of AAA gaming
| is already possible on Mac with Crossover and/or Parallels or
| VMWare Personal, which is free! While I have a Steam Deck, gaming
| on Mac works for me - I refuse to play Baldurs Gate 3 on a
| controller.
| cherryteastain wrote:
| You can hook up a monitor, mouse and keyboard to your Steam
| Deck to be fair.
| zaptrem wrote:
| Don't forget Apple's GamePortingToolkit based on Crossover/Wine
| and the open source client for it Whisky. I think it supports
| most games Linux Proton does now.
| dcchambers wrote:
| I know it's an extremely _un-Apple-like_ thing to do, but I
| really wish Apple would team up with Valve to work on Proton,
| and bring full Proton support to MacOS.
| duskwuff wrote:
| I wouldn't hold my breath. Valve is still bitter about Apple
| deprecating i386 support back in 2019.
| jsheard wrote:
| Bringing Proton to Mac would involve either Apple making
| amends with Khronos and supporting Vulkan, or Valve making
| the substantial effort to port Proton to Metal natively, or
| doing DirectX-to-Vulkan-to-Metal translation with MoltenVK.
| None of those sound very likely or optimal to me.
|
| Besides, the main reason Valve is investing so heavily in
| Linux and Proton is so their destiny isn't tied to someone
| else's platform. MacOS is just another someone else's
| platform like Windows is, with the same threat of getting
| rug-pulled by a first-party app store that spooked Gabe
| Newell[1] into investing in Linux in the first place.
|
| [1] https://www.bbc.co.uk/news/technology-18996377
| wtallis wrote:
| Apple already provides their Game Porting Toolkit which
| includes a D3D12 to Metal translation later for Wine, and
| it has been integrated into user-friendly Wine
| distributions like Crossover since last year. There's not
| much Proton has to offer over what's already available.
| dcchambers wrote:
| My understanding about the game porting toolkit is that
| it requires developers to specifically modify their game
| in order to make their game compatible.
|
| The magic of Proton from a consumer point of view is that
| it _just works_ for basically every game, sans those with
| Kernel-level anticheat stuff. This means thousands of old
| games that haven 't been updated in years will work.any
| games that don't have active developers.
|
| So Apples solution works for new games but isn't a
| practical option for compatibility for existing games.
| whimsicalism wrote:
| crossover experience does not require manual modification
| by developer
| dcchambers wrote:
| TIL about Crossover. Thanks!
| jasomill wrote:
| Also note that Codeweavers, Crossover's developer, is a
| major contributor to both Wine and Proton, so there's a
| great deal of, um, crossover between these projects.
| fl0id wrote:
| There is things like whisky app which makes it a more
| general thing like proton
| wtallis wrote:
| The stated _intended purpose_ of the game porting toolkit
| is to enable developers to modify their games. But the
| software actually being shipped includes what is
| literally a Wine GPU backend, which is usable by (and
| already used and bundled by) consumer-facing Wine
| applications like Crossover. If you go to Codeweavers,
| download any Crossover for Mac from the past year (Sep.
| 27, 2023 according to their release notes), you 're
| getting a tool that includes the D3D to Metal layer from
| Apple's Game Porting Toolkit.
| dcchambers wrote:
| Huh, TIL, thanks!
| jack_pp wrote:
| truth is macs have such a small market share for gaming that it
| ain't worth the effort
| opan wrote:
| >While I have a Steam Deck, gaming on Mac works for me - I
| refuse to play Baldurs Gate 3 on a controller.
|
| Personally 99% of my Steam Deck usage is with it docked. I do
| mostly use a controller, but also have it hooked to the same
| USB switch as my PC so I can hit a button to move my keyboard
| and mouse over.
|
| Baldur's Gate 3 is the first game I ever ran on my Deck that
| did not run very well, though. Most stuff I've played runs at
| 60fps at my external monitor's 1920x1200 resolution. That in
| addition to not liking the gameplay on BG3 much made me not
| continue with the game, though I may revisit it someday.
| WithinReason wrote:
| BG3 is the only RPG I would play on a controller, it's very
| well done. You can also connect a keyboard and monitor to the
| Steam Deck, BG3 runs at 1080p high locked to 30FPS
| nottorp wrote:
| > I refuse to play Baldurs Gate 3 on a controller
|
| I think you picked as an example one of the games that actually
| has a native Mac version?
|
| Or is it a well hidden wine package? I've played it start to
| finish on Macs only and it looked too smooth to be emulation to
| me.
| andrewmcwatters wrote:
| I think at the moment, this is probably the only way to feasibly
| game on a Mac. Crossover and other Wine-based apps as well as
| Parallels are... not really truly possible. If you bought the
| top-of-the-line MacBook Pro 16-inch, 2021 with M1 Max and tried
| to play anything reasonably modern on it, you'd find the
| performance is basically not playable .
| JeffeFawkes wrote:
| I've been having good luck on my M1 Max MBP with Whisky, which
| uses Apple's game porting toolkit: https://getwhisky.app/
| whimsicalism wrote:
| I've been able to play a few games with crossover (like
| overwatch 2) fine. Whisky also works for some stuff.
|
| I also run Asahi so will have to check this out to compare
| tbillington wrote:
| I beat elden ring on m1 pro using Whisky :)
| dcchambers wrote:
| From a performance and technical perspective this is incredible.
| Well done!
|
| It will never happen, but my dream is for the Asahi devs, Valve,
| and Apple to all get together to build out a cross-platform
| Proton to emulate and play games built for Windows on both x86
| and ARM hardware running Linux.
|
| A Steam Deck with the performance and power efficiency of an
| M-series ARM chip and the entire library of games that run on
| Proton is just...dreamy.
| tapoxi wrote:
| https://www.pcworld.com/article/2465907/arm-version-of-steam...
| dcchambers wrote:
| That's awesome news!
| sweeter wrote:
| A lot of stuff like this shows up, they also have a fork of
| waydroid and box64. I think a lot of them are projects and a
| lot of them are just devs with a lot of agency who share the
| dream
| scheeseman486 wrote:
| Steam Deck was made possible by their ongoing efforts to
| enable the play of most of their games catalog on any
| hardware platform that is computationally capable of
| running them, regardless of OS or architecture.
|
| The end game for Valve isn't Steam Deck 2 or 3 (which is
| statistically impossible for Valve to produce), but for
| Steam to be on everything.
| pjmlp wrote:
| Steam Deck was made possible by the plethora of the
| Windows games developer market and Proton.
|
| Most of the studios that own those games, and target
| POSIX like OSes on mobile phones and game consoles, are
| yet to bother with GNU/Linux versions for SteamOS.
| scheeseman486 wrote:
| Wine and DXVK are already running on Android and they
| play Windows games with the rendering and computational
| complexity of Fallout 4 at playable framerates on many of
| the latest smartphone SoCs. It's still WIP, but it's
| already gone beyond proof of concept, people are using
| them. Valve don't need the developers to be on-board in
| order to run their games on anything else, that's why
| Proton exists.
|
| What Valve want is the dissolution between
| platform/architecture and store. By my eye, it's the
| driving force of their efforts, more so than them selling
| hardware or being the open source good guys. Not to
| undervalue their work in helping make Linux a first class
| citizen for gaming, but the core of their business model
| is getting people to engage with their store, full stop,
| and being able to sell their games on Android (and
| elsewhere) would massively extend their reach.
|
| This may go both ways too, there's also been indications
| that Valve have been tinkering with Waydroid, meaning
| Steam could also become a store for Android-native games.
| pjmlp wrote:
| It looks more like how to avoid paying Windows licenses
| for the SteamDeck to me.
| wtetzner wrote:
| I'd guess SteamOS is more about control than licensing
| costs.
|
| I don't think Valve wants to be at the mercy of Microsoft
| and their policy & technical decisions.
| kbolino wrote:
| That's a small part of it, I think. They've almost
| certainly spent a lot more on pouring time and effort
| into Linux than they ever would have saved on license
| fees. It seems like Valve doesn't want to be beholden to
| Microsoft in any way. They support Windows because that's
| where the users and the games are, but they don't want
| Microsoft to be able to rug-pull them either.
| pjmlp wrote:
| Except that they are, to the extent they depend on
| Microsoft technologies for the games that run on Proton.
| kbolino wrote:
| As far as I am aware, neither Valve nor the independent
| Wine/Proton developers are bound by any licensing
| agreements with Microsoft. They are clean-room
| implementing the same technologies, but they are not
| beholden to Microsoft in any legal way. Of course,
| drastic changes in laws or policy regimes could alter
| this dynamic, but those are out-of-context risks.
|
| In order for Microsoft to rug-pull the technology (which
| is quite different from rug-pulling the business model),
| they'd have to break compatibility on Windows itself.
| Video games remain a major reason for home users to run
| Windows. Making ABI-breaking changes to Win32 or DirectX
| is just not very likely to happen. And if it did happen,
| it would be a boon to Valve and not a harm.
|
| The biggest risk (and this would be a classic Microsoft
| move, to be fair) I can foresee is aggressive API changes
| that make it hard for Valve/Wine/Proton to keep up but
| also make it hard for game developers not to. I'm not
| exactly sure what this would look like, and a lot of the
| core technologies are pretty stable by now, but it's a
| possibility. It's not, however, going to harm anything
| that already exists.
| homebrewer wrote:
| They can restrict .NET and the C++ stdlibs so that you
| can only run them under Windows (through a license change
| or by introducing a code check), but if they hadn't done
| that in Ballmer days, I don't think they will now.
| talldayo wrote:
| [flagged]
| pjmlp wrote:
| Because people love to celebrate Proton as if it was
| doing anything for GNU/Linux games, when in reality is
| another OS/2 take on Windows.
| talldayo wrote:
| It doesn't have to do anything for GNU/Linux games,
| that's been an option for years and it's a ghost town
| a-la Metal-native games. Valve (and the community) are
| doing the right thing by ignoring the Apple strategy of
| enforcing distribution terms they will abandon within the
| decade. Developers that _want_ to program for Linux still
| can. It 's just as stupid as it was when the first _Steam
| Machine_ rolled out.
|
| By supporting Proton, they are guaranteeing that modern
| _and_ retro Windows games will be playable on Linux far
| into the future. Trying to get the next _Call of Duty_ to
| support Linux natively is, quite literally, a waste of
| everyone 's time that could possibly be involved in the
| process. I cannot see a single salient reason why Linux
| users would want developers to release a proprietary,
| undersupported and easily broken native build when
| translation can be updated and modified to support
| practically any runtime.
| sweeter wrote:
| Yea. You either have to pump a ton of money into it like
| Apple tries to do to get devs to target your OS, or you
| can take matters into your own hands and do the
| unthinkable with Wine and Proton. Its unironically a
| silver bullet solution. Otherwise we'd all be waiting for
| years to make 1/1000th the progress
| michaelmrose wrote:
| The practical implication is that one can click one
| button and buy install and play thousands of games on
| Linux. Only MS stockholders are liable to care about the
| implications for Windows.
| johnfernow wrote:
| We don't have to imagine what Linux gaming would be like
| without Proton.
|
| - CD Projekt Red: released Witcher 2 on Linux, didn't for
| Witcher 3.
|
| - iD Software: released Doom 3 on Linux, didn't for Doom
| (2016) or Doom Eternal.
|
| - Epic Games: released Unreal Tournament 2004 on Linux,
| but didn't for Unreal Tournament 3 or Fortnite. (A Linux
| port was being worked on for UT3, but it ended up getting
| cancelled.)
|
| - Larian Studios: released Linux version of Divinity:
| Original Sin, didn't for Divinity: Original Sin 2 or
| Baldur's Gate 3
|
| Many studios over the years have made native Linux
| versions, and many studios stopped because the cost of
| porting exceeded the revenue it generated. Proton didn't
| exist when Unreal Tournament 3, Witcher 3, Doom (2016),
| or Divinity: Original Sin 2 released, so Proton wasn't
| the reason those studios stopped developing Linux titles
| -- they stopped because it made no financial sense to
| continue to make them.
|
| Now, with Proton, 79% of the top 1000 games on Steam are
| gold or platinum rated on ProtonDB. If you're fine with
| minor issues, 88% are silver rated or better. For the
| Steam Deck in particular, there are 5,500 verified games,
| and 16,526 verified or playable games. So I'd argue
| Proton is doing quite a lot for people gaming on
| GNU/Linux machines, since they now have access to a solid
| majority of the top 1000 games on Steam, both on a Linux
| desktop and on a handheld.
| sandworm101 wrote:
| I am a strong linux supporter and I too do not like what
| proton is doing to games. A few years ago there were many
| significant games coming out with native linux capacity
| (MineCraft, KSP, Factorio). Then proton dropped. Now,
| rather than support linux natively, even the most pro-
| linux developers are just expecting that their windows
| version will run under proton. And those who are running
| games under proton are essentially cut-off from customer
| support. I've had a few games where a patch suddenly
| stopped them working under proton. I have no recourse in
| such situations. That is not a good trend.
| talldayo wrote:
| Linux is not a stable runtime in the first place. Unless
| you are isolating, redistributing and sandboxing most of
| the libraries used to run your game, it's almost
| guaranteed to break when the dependencies are updated.
| Windows apps don't have that problem, natively or when
| run through emulation.
| ikety wrote:
| Genuinely what is the practical difference in this for
| 99% of users? They just want to play x game. Proton
| performance is pretty great, what else would be a problem
| for those people?
|
| Also when it comes to breaking proton support (Which does
| happen) Valve + GloriousEggroll give you access to plenty
| of older and special versions. Surely that's better than
| rolling back entire software?
|
| My game doesn't work -> I go to protonDB -> Users saying
| use X Proton Version or Y ProtonGE version -> I switch
| the layer used in steam
|
| Hard to imagine a simpler process than that
| homebrewer wrote:
| Just ignore the guy, it's essentially the reverse of "I
| run Arch BTW". Not just about Valve or Proton, but about
| pretty much every FOSS technology that's celebrated here.
| sandworm101 wrote:
| Close, but the root is more nuanced. Once upon a time,
| Microsoft was talking about regulating "apps" on windows
| like Apple does for the iPhone. Valve saw the writing on
| the wall: a potential ban on violent or otherwise adult-
| themed games. So Valve started the steambox project. Get
| the games running on linux/WINE and they could tell
| Microsoft to push off. Years later, we have the steamdeck
| as a revolutionary product and linux is the go-to OS for
| portable gaming.
| pjmlp wrote:
| Running Windows games on top, which will work until it
| doesn't.
| michaelmrose wrote:
| What trouble do you foresee?
| rowanG077 wrote:
| I mean practice has shown it's not a problem. What else
| is there?
| johnfernow wrote:
| What do you foresee not working in the future?
|
| If future versions of Proton break compatibility with
| older Windows apps, you can use different old versions of
| Proton for individual games. Steam makes this very easy
| on Linux, but rarely is it necessary.
|
| I don't foresee many Linux distros breaking compatibility
| with Wine, which is good, as some devs argue Win32 is the
| only stable ABI on Linux. [1]
|
| I don't foresee legal issues either, as Wine has been
| around for 31 years, and its corporate sponsors have
| included Google in the past. I've seen no indication that
| the project is on shaky legal grounds.
|
| Microsoft could always create a new API that Wine doesn't
| yet support, but good luck getting developers to use it
| -- they've tried many times, but not much has stuck, and
| most devs just stick with Win32. [2]
|
| 1. https://blog.hiler.eu/win32-the-only-stable-abi/
|
| 2. https://news.ycombinator.com/item?id=36060678
| p_l wrote:
| I don't remember how officially it was stated, but
| original push by Valve for steam on Linux with Proton was
| to remove their dependency on Microsoft - a hedge against
| possible future ecosystem-impacting decisions in Redmond.
|
| Making SteamDeck use windows wouldn't impact prices much,
| Microsoft is really friendly for putting windows by OEMs.
| Could even run modified to act like current steam deck.
|
| Instead, SteamDeck is there to drive up testing on Proton
| or straight forward porting to Linux, which just
| availability on Linux and the previous steam machine
| didn't drive up
| ikety wrote:
| Linux/Unix has been used as a base overwhelmingly in
| pretty much every new consumer OS for decades. Not to
| mention Microsoft certainly cuts deals with manufacturers
| when it comes to windows on portable devices (I think at
| one point they offered free licenses on devices with
| screen sizes under 8 inches).
|
| The steam deck is 100% usable without leaving 'game mode'
| even a single time. Something that is genuinely
| impossible using Windows as a base. That's the important
| part
| freedomben wrote:
| You are right that many developers don't care and haven't
| bothered with Linux, but one reason for optimism is that
| this seems to be changing. Just looking through the list
| of native Linux games today compared to what it was like
| a year or 2 years ago, there are a lot more options. I
| was looking through the list of Linux games on Gog, and
| it is likewise in a much better position than it was
| prior. I think there is much reason for optimism!!
| grahamj wrote:
| "There is now sufficient reason for greater optimism"
|
| - Automated Personnel Unit 3947
| reassembled wrote:
| Everything except Windows 7 and XP that is.
| jchw wrote:
| I believe Valve dropped official Windows 7 support in
| Steam because Chromium did and they weren't going to fork
| it.
|
| I empathize if you don't like any version of Windows
| newer than 7 or XP, but it's time to let the dream of
| running them forever go. It's not weird when software
| doesn't support the 2009 version of an operating system
| anymore in 2024. If they never dropped support, it would
| be difficult to take advantage of improvements that
| occurred in the last 10 years, because we'd forever be
| stuck in baggage.
|
| Of course when it's feasible everybody loves software
| that really never does drop support, like 7-zip, which I
| think happily still works on Win9x without KernelEx...
| but I'd rather 7-zip stopped having serious security
| issues than _continued_ to work on old Windows versions.
| kbolino wrote:
| Windows 7 was great and I'd love to go back. If I really
| had my druthers, Windows 2000 was peak and XP was just a
| vulgarized version of 2000.
|
| However, it is Microsoft more than anyone else that has
| decided to stop supporting those operating systems.
| Windows XP does not have support for any modern version
| of TLS (only TLS 1.0). There's no good way to support a
| browser-based app like Steam on a platform that cannot
| natively provide a secure connection to a modern web
| server.
|
| There is not such a hard reason to drop Windows 7 support
| (again, except that Microsoft no longer supports it) but
| there are security-relevant APIs that are only available
| starting in Windows 10 which means special patches would
| have to be maintained just for Steam on Windows 7 to
| continue working securely.
| lucasban wrote:
| What do you mean Steam Deck 2 or 3 would be impossible?
| vundercind wrote:
| Steamdeck 3 being statistically impossible is a joke
| about Valve having an aversion to releasing a #3 of
| anything.
|
| Half life 1, 2... hm.
|
| Ok we'll make three HL2 episodes to follow that up.
|
| Ep I. Ep II. Uhhhh... and let's stop there, just like
| forever I guess.
|
| Portal 1. Portal 2.
|
| Left4dead. L4D2.
|
| Team Fortress. TF2.
|
| Counterstrike. CS2. Oh shit we're releasing a third one,
| we might have to use the number three finally, oh no...
| I've got it: CS:Go!
| jakogut wrote:
| Also, the successor to CS:Go is...Counter-Strike 2.
| vundercind wrote:
| Oh damn I got the order on those mixed up. Was probably
| thinking of CS Source.
|
| Regardless, point stands: they hate the number 3.
| echoangle wrote:
| They're probably doing it on purpose as a joke at this
| point.
| jakogut wrote:
| It would have to be, CS2 is the fourth major installment
| in the Counter-Strike franchise.
|
| Then again, all kinds of companies take liberties with
| naming including numbers. Look at Windows 7 (12th major
| release), Windows 10 (successor to Windows 8), the game
| Battlefield 2 (third in the series), Battlefield 3 (three
| games after BF2), Battlefield 1 (after the release of
| BF4), etc.
| ohmahjong wrote:
| It is a joke about Valve only rarely making the third
| installment in any of their series (e.g. Half Life 3 not
| existing) Edit: specifically including "3" in the title -
| the actual number of games tends to be higher but with
| different names.
| rowanG077 wrote:
| I'm not sure if you know. But Alyssa, the person who basically
| wrote almost the entire userspace opengl and vulkan driver,
| works at valve.
| dcchambers wrote:
| Wow! I wasn't aware, but that actually gives me a ton of
| confidence that Valve isn't ignoring ARM with all of their
| Linux + Proton work.
|
| Her output is incredible.
| inputError wrote:
| Alyssa rules. We all love Alyssa.
| 1-more wrote:
| I see cats writing software _with hardly any
| documentation_ like this and my brain melts. Power level
| strictly monotonic, possibly exponential, and very very
| large. Bravissima!
| adastra22 wrote:
| I hope they don't ignore macOS. They could port proton to
| run on Metal + Rosetta and then Steam would support all
| running windows titles on macOS and Linux.
|
| I recognize it's a hell of an ask, but I think Alyssa could
| pull it off.
| pmarreck wrote:
| I'm a huge macOS fan but even I have to admit that gaming
| deserves to have a home on an open-source OS controlled
| by no one (which would be Linux in this case) and that
| Steam devoting effort to bring first-class gaming from
| Windows to macOS is like working to escape from the
| frying pan into the fire.
| psd1 wrote:
| I hope that she was working on Asahi full time at valve,
| because if she did all that while also holding down a day job
| then I might as well be soylent green.
| jamiek88 wrote:
| The 10x developer is real!
|
| Sometimes you've just gotta tip your hat.
| bmicraft wrote:
| An ARM CPU only emulating x86 isn't going to be more efficient
| than straight x86. ARM is barely more efficient as it is at
| those performance levels.
|
| The real reason Apple is ahead is because they're paying for
| more expensive more advanced nodes for their CPUs. I you
| compare CPUs on similar node sizes, you'll see that AMD and
| Intel are basically caught up architecturally in perf/W
| metrics.
| aurareturn wrote:
| This is definitely not true. M3 is 2x - 3x more efficient
| than Lunar Lake on the same N3B node.
| adgjlsfhk1 wrote:
| I don't think that's true. M3 has much better idle/near-
| idle power draw, but actual performance per watt when doing
| things is pretty close.
| aurareturn wrote:
| No, it's the other way around. Intel has generally caught
| up in idle power draw but is still severely behind in
| performance per watt.
|
| https://www.notebookcheck.net/Intel-Lunar-Lake-CPU-
| analysis-...
|
| https://youtu.be/ymoiWv9BF7Q
| hedora wrote:
| The last I checked, there low wattage AMD and high
| wattage Apple had similar performance and wattage, so AMD
| was the right choice for raw performance, and Apple won
| for portable devices.
|
| Intel was losing badly to one or the other at all TDPs. I
| don't get the impression that's changed much. (Even if it
| has, I can't remember the last time I encountered a non-
| xeon intel machine with working hardware and drivers (for
| any OS, and I tried Windows, Linux and macs).
| aurareturn wrote:
| AMD does not win over Apple for raw portal performance.
| AMD does give you a lot of MT performance for a decent
| price. You have to buy an M3 Pro to match an AMD HX 370.
| However, you're sacrificing battery life, quietness,
| portability, and ST performance with AMD.
| Brybry wrote:
| Remember that the latest Intel chips are a TSMC process
| node now, that's a pretty big change.
| high_na_euv wrote:
| Have you seen Lunars iGPU?
| aurareturn wrote:
| Yes, M3 is still 2-3x more efficient than Lunar Lake's
| GPU as long as it's not games that were more optimized
| for x86 and or DirectX. For example, M3 generally wins in
| compute with a lot less power needed.
| adastra22 wrote:
| There is no theoretical reason that is the case. These
| systems would be transpiling, not interpreting.
| alexr243 wrote:
| You can play windows game with this release in Asahi Linux! So
| it is possible now
| shmerl wrote:
| You don't need Apple for that.
| log_e wrote:
| If you want it to happen, ask them for it every day. You are
| their constituent.
| WD-42 wrote:
| Apple is going to do the same thing they did with BSD, WebKit,
| etc. They will wait until proton is mature enough, fork it,
| then release it as their own. Why put in the effort this early
| on?
| WWLink wrote:
| I think it's still hilarious and crazy that
| safari/chrome/webkit/blink exploded out of the cute little
| KHMTL browser called Konqueror in KDE from back in the day.
|
| And the root of the whole browser wars thing was microsoft
| making an absolute dog of a browser for Mac OS X when it came
| out and then refusing to support it. lmao.
| pjerem wrote:
| Haaa Konqueror. It was THE shit back in the day. I loved
| this software. It really was at the core of the KDE
| experience. Too bad it disappeared, I miss it. (well it's
| not technically dead but it's not moving either)
| pxc wrote:
| I came here to say this! Konqueror may have served a
| small community but it was excellent.
|
| It was the file manager as well as the browser and it was
| incredibly capable. By far the most advanced GUI file
| manager of its time. And a pretty fast and pleasant
| browser, although the compatibility was hit and miss.
| (Those were Flash and IE-dominated days as I recall
| them.)
|
| A lot of what I loved about Konqueror is captured in
| Dolphin. I don't think I need my web browser to be a file
| manager... maybe that concept was just a 90s fever dream.
| But I miss Rekonq. Maybe I should revisit Konqueror.
| kombine wrote:
| Yes and I believe Dolphin is the best conventional file
| manager on the market - superior to the Windows Explorer
| and the file browser in in Mac OS.
| aryonoco wrote:
| IE 5.5 for OS X was by far the most standard compliant
| browser of its time. It supported more CSS than either NN
| 4.x or IE 5 for Windows. Nothing came to surpass it until
| Mozilla 1.0 and even then it wasn't a slam dunk.
| pmarreck wrote:
| Yep. I remember those days.
|
| I also remember Safari on Windows, which was convenient
| for many reasons.
| vitaflo wrote:
| Was gonna say IE5 on OS X was the opposite of "a dog of a
| browser". It was the gold standard against which every
| other browser was compared because it was by far the most
| standards compliant browser of its day.
|
| Also a quick correction, there was no IE5.5 for OSX. That
| was for Windows and used a diff rendering engine.
| simonh wrote:
| They won't do anything to undermine Metal.
| WD-42 wrote:
| No but it looks like they'll add Metal support to Wine, do
| the bare minimum to comply with the license and release it
| as "Apple game toolkit". Textbook.
| pachorizons wrote:
| Usually I would be as optimistic as you are about this,
| because that would be the dream (although it would be nicer
| for them to contribute to the project.) However, given
| Proton's primary use case is gaming, such an effort will
| almost certainly be kneecapped by Apple's historic half-
| hearted commitment to anything other than microtransaction-
| powered mobile games.
| ascagnel_ wrote:
| https://developer.apple.com/games/game-porting-toolkit/
| WD-42 wrote:
| Which is exactly what I described. Looks like they took
| crossover/wine and added some custom patches. What are the
| chances they upstream anything? Probably 0.
| tomnipotent wrote:
| Except it wasn't "taken", but licensed from CodeWeavers
| in a commercial partnership. This implies that they're
| contributing cash, not code.
| WD-42 wrote:
| Not sure what agreement they have there, but at the end
| of the day it's Wine which has decades of open source
| development behind it at this point. Plus a bunch of
| other libraries (gstreamer being a notable inclusion)
| that are all FOSS. This still fits the pattern of Apple
| profiting off of OSS projects while contributing back as
| little as they can get away with.
| pmarreck wrote:
| Apple literally already has released a game porting toolkit
| which is basically Proton (see sibling reply)
| WD-42 wrote:
| Which is crossover/wine with custom patches.
|
| https://raw.githubusercontent.com/apple/homebrew-
| apple/refs/...
|
| 0 chance they upstream anything. So in a way they are
| already benefitting from valves work.
| johnnyanmac wrote:
| that's ideally what Vulkan was for. Build for one common open
| source standard, and then Apple/Microsoft/Google/Linux can all
| build an API to support that.
|
| But I guess there was never a time when an open graphics
| standard stood as the leader. Maybe during a brief stint in the
| Windows Vista era at best.
| jorvi wrote:
| During the Unreal Tournament 99 / Quake 3 era a lot of games
| ran a lot better on Nvidia with OpenGL rather than DirectX.
| tonyhart7 wrote:
| or you know, just release a game on native linux build
| pmarreck wrote:
| The reason why this isn't more prevalent is twofold
|
| 1) everything standardized, like it or not (note: I do not),
| on the Windows API, and it has remained relatively stable,
| which is important because
|
| 2) Linux-native games I've had, have become un-executable
| over time without semi-regular maintenance, and Windows games
| running on whatever version of Proton they best work with do
| not have that drawback
| gchamonlive wrote:
| It's more likely it'll be Qualcomm instead of apple and
| eventually an arm based steam deck. These chips just make a lot
| of sense for handheld devices.
| KeplerBoy wrote:
| Are the chips really fundamentally better than their AMD and
| Intel counterparts made on the same node?
|
| Sure it's a great design, but I believe x86-64 will catch up
| once again now with everyone using TSMC.
| psd1 wrote:
| Arm has had a performance-to-power edge over x86 since
| inception.
|
| AIUI, if you want the most flops per die, you'll buy x86 -
| probably the 128-core Xeon for enterprise money. But that's
| not what's best for hand-held gaming.
|
| AAA titles are typically GPU-bound anyway. More CPU flops
| may not offer much benefit.
| talldayo wrote:
| > AAA titles are typically GPU-bound anyway. More CPU
| flops may not offer much benefit.
|
| Yes, but actually no. The Steam Deck is playing at
| _extremely_ low resolutions. Rendering at 720p and 30fps
| is (on paper) 8x less demanding on the GPU than rendering
| a native 1440p60 experience. You can fully get by without
| having a powerful dGPU, which is why the Steam Deck is
| really able to play so many titles on a weak iGPU.
|
| The problem is translation. Cyberpunk 2077 runs fine on a
| 25 watt mobile chip that uses x86, which is why the Deck
| even costs less than $1000 in the first place. If you try
| to put a mobile ARM CPU in that same position and
| wattage, it's not going to translate game code fast
| enough unless you have custom silicon speeding it up.
| There's really no reason for Valve to charge extra for a
| custom ARM design when COTS x86 chips like AMD's would
| outperform it.
|
| For x86 PC games (which pretty much all games are,
| today), ARM is at a substantial disadvantage, period. The
| IPC and efficiency advantages are entirely lost when you
| have to spend extra CPU cycles emulating AVX with NEON
| constantly. If there were ARM-native games on Windows
| then things might be different, but for today's landscape
| I just don't see how ISA translation is better than
| native.
| hentrep wrote:
| I noticed the URL was updated for this post. Previously it linked
| to asahilinux.org which showed an anti-HN manifesto from the HN
| referral. Curious as I haven't seen this before. Seems it has
| been covered by previous commenters:
| https://news.ycombinator.com/item?id=36227103
| ginko wrote:
| How can the site even detect where a user is coming from?
| Browsers leaking this information seems like a huge privacy
| issue to me.
| robin_reala wrote:
| Referer (misspelled in the spec) has been a part of HTTP from
| day 1.
| ginko wrote:
| Feels crazy this isn't disabled by default
| paraboul wrote:
| This is part of the web DNA. Pages linking pages and
| being aware about it. Origin can still disable it.
| Smar wrote:
| There is little hope to get it disabled when an ad
| company is running running the most popular ad platf...
| Erm, the world wide web browser.
| jsheard wrote:
| The Referrer-Policy header lets a server tell the browser
| how much referrer information to pass on when following
| links, all the way down to nothing at all if desired.
| Chrome does respect that, and they also followed other
| browsers in changing the default to "strict-origin-when-
| cross-origin" a few years ago which truncates the
| referrer path when leaving to a different domain, so they
| only see the domain the visitor came from rather than the
| specific page like they used to. Can't really fault
| Google in this case.
|
| https://developer.mozilla.org/en-
| US/docs/Web/HTTP/Headers/Re...
| mananaysiempre wrote:
| See[1] the Referrer-Policy header, <meta
| name="referrer">, <a referrerpolicy> and <a
| rel="noreferrer">.
|
| But generally, webmasters have found it useful to know
| who caused their server to fall over^W^W^W^W^W^W is
| linking to their pages. This was even used as a
| predecessor to pingbacks once upon a time, but turned out
| to be too spammable (yes, even more so than pingbacks).
|
| After the HN operators started adding rel=noreferrer to
| links to the Asahi Linux website, Marcan responded[2] by
| excluding anyone who has the HN submit form in their
| _browser history_ , which feels like a legitimate attack
| on the browser's security model--I don't know how it'd be
| possible to do that. (Cross-origin isolation is supposed
| to prevent cross-site tracking of this exact kind, and
| concerns about such privacy violations are why SRI has
| not been turned into a caching mechanism along the lines
| of Want-Content-Digest, and so on and so forth.) ETA:
| This is no longer in place, it seems.
|
| [1] https://developer.mozilla.org/en-
| US/docs/Web/HTTP/Headers/Re...
|
| [2] https://social.treehouse.systems/@marcan/110503331622
| 393719
| miki123211 wrote:
| > I don't know how it'd be possible to do that
|
| It isn't, at least not in the way you think.
|
| Visited links have always looked different from unvisited
| ones, and the moment you could customize how links looked
| via CSS, browsers also had to implement styling for
| visited links specifically.
|
| Modern browsers put a lot of care into making the changes
| to those styles observable to the user, but not to
| Javascript.
|
| This is an extremely hard problem, and browsers have had
| a lot of security issues related to this behavior.
| Nowadays, you can only apply a very limited subset of CSS
| properties to those styles, to avoid side-channel timing
| attacks and such.
|
| This means you can display a banner to anybody who has a
| certain URL in their browser history, but you can't
| observe whether that banner actually shows up with JS or
| transmit that information to your server.
| mananaysiempre wrote:
| Ah. Ahhh[1]. I see. <!doctype html>
| <style>a { color: white; background-color: white; }
| a:visited { color: black; }</style> <body><a
| href="https://example.com/abracadabra" onclick="return
| false">you are a bad person</a>
|
| [1] https://developer.mozilla.org/en-
| US/docs/Web/CSS/:visited#pr...
| Wowfunhappy wrote:
| > This means you can display a banner to anybody who has
| a certain URL in their browser history, but you can't
| observe whether that banner actually shows up with JS or
| transmit that information to your server.
|
| How do they stop you from using Canvas to see the output
| and send it back?
| zamadatix wrote:
| Canvas can't "see the output", it only sees what is drawn
| in it (which is not a set of HTML tags, it's JS
| commands).
|
| The screen recording/screen sharing API can be used for
| this but security is the reason you have to give explicit
| permission to the site before it can do this.
| miki123211 wrote:
| IIRC, Firefox had a bug where this exact scenario was
| possible, I think you needed to embed the link in html
| embedded inside an SVG, which was displayed in the
| canvas, and then access the bitmap. You could e.g. make
| the link black if visited and white otherwise, and then
| the number of white versus black pixels in the bitmap
| would tell you whether the link was visited or not.
|
| There was also that asteroids game / captcha where links
| were white/black squares and your goal was to click all
| the black ones. Of course, clicking a square revealed
| that you knew the square was black, which meant the URL
| under it was in your history.
| bigstrat2003 wrote:
| Referer does have legitimate uses. For example, back in
| the day people would use it to detect if someone embedded
| an image from their site on another site. SomethingAwful
| famously used to respond to any such requests with
| goatse, and forums I was on had very strict "don't link
| to SA images" rules as a result.
|
| I think that using referer to try to deliver manifestos
| to users of another site is kinda childish, but so it
| goes. Every tool can be put to good or bad uses.
| dylan604 wrote:
| It's only slightly less childish than the current WP
| drama.
| npteljes wrote:
| There's a handy addon for Firefox called Privacy Settings
| that can take care of that. Explicitly adds and option to
| have the referers be not sent, and a quick way of re-
| enabling it, in case it breaks a website. Because of
| course that happens too.
| stepupmakeup wrote:
| The manifesto is longer than the content...
| fullstop wrote:
| It's almost as bad as jzw's website:
| https://cdn.jwz.org/images/2016/hn.png (nsfw)
| hentrep wrote:
| He does the same redirect whenever someone links to his DNA
| Lounge: https://dnalounge.com (NSFW)
| justin66 wrote:
| It's completely different. Jwz's is funny.
| dang wrote:
| The URL wasn't updated. You're thinking of
| https://news.ycombinator.com/item?id=41799011, which was a
| separate post.
| hentrep wrote:
| Ah, thanks for clarifying!
| dancemethis wrote:
| Where's the real inspiration for Asahi, Fandaniel in FFXIV?
| rowanG077 wrote:
| > Asahi means "rising sun" in Japanese, and it is also the name
| of an apple cultivar. Xu ringo (asahi ringo) is what we know as
| the McIntosh Apple, the apple variety that gave the Mac its
| name.
| Wowfunhappy wrote:
| > Tessellation enables games like The Witcher 3 to generate
| geometry. The M1 has hardware tessellation, but it is too limited
| for DirectX, Vulkan, or OpenGL. We must instead tessellate with
| arcane compute shaders
|
| > Geometry shaders are an older, cruder method to generate
| geometry. Like tessellation, the M1 lacks geometry shader
| hardware so we emulate with compute.
|
| Is this potentially a part of why Apple doesn't want to support
| Vulkan themselves? Because they don't want to implement common
| Vulkan features in hardware, which leads to less than ideal
| performance?
|
| (I realize performance is still relatively fast in practice,
| which is awesome!)
| mandarax8 wrote:
| Geometry shaders are not part of base Vulkan. They're an
| extension.
| ornitorrincos wrote:
| they are not an extension, they are part of core 1.0 vulkan.
|
| Although its true that they are an optional feature (as is
| tessellation).
| VHRanger wrote:
| > Is this potentially a part of why Apple doesn't want to
| support Vulkan? Because they don't want to implement common
| Vulkan features in hardware, which leads to less than ideal
| performance?
|
| Yes, it's a big reason.
|
| I tried to port the yuzu switch emulator to macos a few years
| ago, and you end up having to write compute shaders that
| emulate the geometry shaders to make that work.
|
| Even fairly modern games like Mario Odyssey use geometry
| shaders.
|
| Needless to say, I was not enough of a wizard to make this
| happen!
| miohtama wrote:
| Why Apple does not just implement it? They have more
| resources than anyone in the world. Patents?
| kelnos wrote:
| Because they don't care. They've decided that Metal is The
| One True Way to write 3D-accelerated apps on macOS, so they
| only implement the things in hardware that Metal requires.
| Wowfunhappy wrote:
| Maybe, but we got here because I asked "is it possible
| that Apple doesn't want to support Vulkan (in software)
| because they don't want to support the features it needs
| (in hardware)."
|
| If the reason they don't support it in hardware is
| because they don't want to support it in software, then
| the logic gets a bit circular.
|
| I'm interested in which came first, or if it's a little
| of both.
| p_l wrote:
| Vulkan very much is designed to give flexibility to
| hardware vendors. Where abstractions do paper over
| differences it's generally where it makes the abstraction
| cheap _in runtime_ but you might take more code vs. less
| code but requiring a feature that would be otherwise
| optional (for example some of the complex pipeline
| manipulation Vs bindless)
| wtallis wrote:
| There are definitely some features omitted from Apple's
| GPU, but fairly early in the reverse engineering process,
| Alyssa Rosenzweig provided several examples of hardware
| features present in Apple's GPU that are not exposed by
| Metal: https://rosenzweig.io/blog/asahi-gpu-part-4.html
| achandlerwhite wrote:
| Perhaps, but also geometry shaders are generally losing
| popularity and on their way out. Per google ai search
| result (for what it is worth):
|
| Geometry shaders are generally considered less necessary
| in modern graphics pipelines due to the rise of more
| flexible and efficient alternatives like mesh shaders
| which can perform similar geometry manipulation tasks
| with often better performance and more streamlined
| workflows
| Wowfunhappy wrote:
| In hardware? I would assume because it takes up space on
| the die, right? It's not free.
| fl0id wrote:
| Because they like to be different tm
| dagmx wrote:
| Geometry shaders have long been disfavored by all ISVs ,
| not just Apple. It's just most include the software path.
|
| If you're using geometry shaders, you're almost always
| going to get better performance with compute shaders and
| indirect draws or mesh shaders.
|
| A lot of hardware vendors will handle them in software
| which tanks performance. Metal decided to do away with them
| rather than carry the baggage of something that all vendors
| agree is bad.
|
| It takes up valuable die space for very little benefit.
| johnnyanmac wrote:
| Geometry shaders have almost always sucked in all fairness.
| I'm surprised a game newer than 2015 bothered with them.
| It's been pretty common knowledge that geometry shaders
| really only work better on Intel hardware (and I'm not sure
| how long _that_ lasted).
|
| Tessellation falling short is just classic Apple, though.
| Shows how much they prioritize games in their decision
| making, despite every other year deciding they need a AAA
| game to showcase their hardware.
|
| (apologies for the crude answer. I would genuinely be
| interested in a technical perspective defending the
| decision. My only conclusion is that the kind of software
| their customers need, like art or editing, does not need
| that much tessellation).
| ribit wrote:
| Are you talking about Vulkan or about geometry shaders? The
| later is simple: because geometry shaders are a badly
| designed feature that sucks on modern GPUs. Apple has
| designed Metal to only support things that are actually
| fast. Their solution for geometry generation is mesh
| shaders, which is a modern and scalable feature that
| actually works.
|
| If you are talking about Vulkan, that is much more
| complicated. My guess is that they want to maintain their
| independence as hardware and software innovator. Hard to do
| that if you are locked into a design by committee API.
| Apple has had some bad experience with these things in the
| past (e.g. they donated OpenCL to Kronos only to see it
| sabotaged by Nvidia). Also, Apple wanted a lean and easy to
| learn GPU API for their platform, and Vulkan is neither.
|
| While their stance can be annoying to both developers and
| users, I think it can be understood at some level. My
| feelings about Vulkan are mixed at best. I don't think it
| is a very good API, and I think it makes too many
| unnessesary compromises. Compare for example the
| VK_EXT_descriptor_buffer and Apple's argument buffers.
| Vulkan's approach is extremely convoluted -- you are
| required to query descriptor sizes at runtime and perform
| manual offset computation. Apple's implementation is just
| 64-bit handles/pointers and memcpy, extremely lean and
| immediately understandable to anyone with basic C
| experience. I understand that Vulkan needs to support
| different types of hardware where these details can differ.
| However, I do not understand why they have to penalize
| developer experience in order to support some crazy
| hardware with 256-byte data descriptors.
| MBCook wrote:
| I'm not a game programmer, so I just sort of watch all
| this with a slightly interested eye.
|
| I honestly wonder how much the rallying around Vulkan is
| just that it is a) newer than OpenGL and b) not DirectX.
|
| I understand it's good to have a graphics API that isn't
| owned by one company and is cross platform. But I get the
| impression that that's kind of Vulkan's main strong suit.
| That technically there's a lot of stuff people aren't
| thrilled with, but it has points A and B above so that
| makes it their preference.
|
| (This is only in regard to how it's talked about, I'm not
| suggesting people stop using it or switch off it to
| _thing_ )
| shmerl wrote:
| Nothing stops them from providing their own API and
| Vulkan both. So your arguments only make sense for why
| they might want other API but they don't make sense on
| the part reasons for completely denying Vulkan support
| alongside it. There is no good reason for that and the
| apparent reason is lock-in.
| ronsor wrote:
| Why couldn't you just use MoltenVK?
| slimsag wrote:
| MoltenVK doesn't support geometry shaders for ~3 years
| now[0]
|
| [0] https://github.com/KhronosGroup/MoltenVK/issues/1524
| mrpippy wrote:
| Metal 3 (in 2022) added mesh shaders, which can be used to
| emulate geometry shaders.
|
| We (CodeWeavers) are doing this in (a fork of) MoltenVK, and
| Apple's D3DMetal is as well.
| achandlerwhite wrote:
| Hi, is there a plan to submit these changes back up to
| MoltenVK?
| mrpippy wrote:
| We would still like the changes to be upstream but they may
| need more polish, and it spawned a conversation about the
| division of responsibilities between SPIRV-Cross and
| MoltenVK:
|
| https://github.com/KhronosGroup/SPIRV-Cross/pull/2200
| https://github.com/KhronosGroup/SPIRV-Cross/pull/2204
| ribit wrote:
| Apple not supporting Vulkan is a business decision. They wanted
| a lean and easy to learn API that they can quickly iterate
| upon, and they want you to optimize for their hardware. Vulkan
| does not cater to either of these goals.
|
| Interestingly, Apple was on the list of the initial Vulkan
| backers -- but they pulled out at some point before the first
| version was released. I suppose they saw the API moving in the
| direction they were not interested in. So far, their strategy
| has been a mixed bag. They failed to attract substantial
| developer interest, at the same time they delivered what I
| consider to be the best general-purpose GPU API around.
|
| Regarding programmable tessellation, Apple's approach is mesh
| shaders. As far as I am aware, they are the only platform that
| offers standard mesh shader functionality across all devices.
| shmerl wrote:
| That might be an excuse, but that's hardly a reason. They are
| simply extreme lock-in proponents and don't want to support
| cross platform graphics API. That's the real reason.
| wtetzner wrote:
| > They are simply extreme lock-in proponents and don't want
| to support cross platform graphics API.
|
| Which seems like an ineffective move when you have no market
| share.
| shmerl wrote:
| They don't seem to care. I'm sure that will bite them in
| the long term, but for now they are very intent on complete
| NIH and lock-in anywhere they can push it.
| xbar wrote:
| Thank you Alyssa Rosenzweig Asahi Lina
| chaos_princess Davide Cavalca Dougall Johnson
| Ella Stanforth Faith Ekstrand Janne Grunau
| Karol Herbst marcan Mary Guillemard Neal
| Gompa Sergio Lopez TellowKrinkle Teoh Han
| Hui Rob Clark Ryan Houdek
| dyingkneepad wrote:
| Thank not only these people but also their employers for
| funding the work.
| gertop wrote:
| Marcan and asahi Lina are the same person.
| preisschild wrote:
| Is there actually any proof of that?
| anonfordays wrote:
| Yes, a lot, it's basically confirmed. Last time someone
| linked proof, it got flagged immediately. Kiwifarms is a
| dumpster fire, so I'm not going to search or link anything.
| epcoa wrote:
| Must it really be confirmed or proven? This isn't a court
| of law.
|
| But when someone willingly posts (and keeps) this publicly
| https://www.youtube.com/watch?v=effHrj0qmwk
|
| and then acts offended or claims doxxing (and starts using
| it to stir shit up for leverage) when people draw the
| obvious conclusion, that's behavior in bad faith and should
| be called out as such and dismissed.
| neoromantique wrote:
| And we would care because...?
| ashirviskas wrote:
| Because they were mentioned twice..?
| neoromantique wrote:
| If they insist on using a pseudonym it is their right,
| going out of your way to unmask pseudonyms is scummy(akin
| to doxxing).
| lynguist wrote:
| May I use this space to ask the question: is the M3 substantially
| different from the M1 and M2 that it is not supported?
| gilgoomesh wrote:
| I don't know how different but it apparently has dramatically
| improved hardware shaders compared to earlier M chips so I'm
| guessing that a lot of this might be different, there.
| wmf wrote:
| The M3 GPU added a bunch of features including ray tracing. The
| "dynamic caching" sounds like a big change to local memory
| which could require serious driver changes.
|
| https://www.theverge.com/2023/10/30/23938676/apple-m3-chip-g...
| fl0id wrote:
| Yes. And also some other peripherals are different.
| pbasista wrote:
| From what I understand, one of the factors to not focus on
| Asahi Linux on M3 for now is the lack of an M3 Mac Mini which
| supposedly makes the development easier.
| geokon wrote:
| last I check you can't even buy M1 macs on apple's website
| anymore (maybe it's region dependent)
| aykevl wrote:
| M3 and M4 haven't been supported yet because they weren't a
| priority (looks like they've been focusing on gaming support
| for the last year or so).
|
| Alyssa said in her talk that they'll probably get it working in
| 6 months or so:
| https://www.youtube.com/watch?v=pDsksRBLXPk&t=2932s
| ribit wrote:
| M3 GPU uses a new instruction encoding, among other things.
| Also, it has a new memory partitioning scheme (aka. Dynamic
| Caching), which probably requires a bunch of changes to both
| the driver interface and the shader compiler. I hope the Asahi
| team will get to publishing the details of M3 soon, I have been
| curious about this for a while.
| Thaxll wrote:
| I see that they're using FEX, what about box86? Is it comparable
| in term of performance?
| 58028641 wrote:
| box86 does ARM32 which isn't supported by Apple Silicon
| Thaxll wrote:
| box64 if you prefer.
|
| https://box86.org/2022/03/box86-box64-vs-qemu-vs-fex-vs-
| rose...
| ThatPlayer wrote:
| Box64 _only_ does 64-bit binary translations. So for
| example Steam cannot run on box64 alone because it 's a
| hybrid with both 32-bit and 64-bit binaries:
| https://github.com/ptitSeb/box64/?tab=readme-ov-
| file#notes-a...
|
| Wine has beta support for 32-bit Windows applications on
| 64-bit-only wine, but it's not default.
|
| They also address it: https://docs.fedoraproject.org/en-
| US/fedora-asahi-remix/x86-...
| paulryanrogers wrote:
| It is shocking the effort required to have a good gaming
| experience on Apple computers (excluding iOS). They always struck
| me as agnostic to games, yet in recent years it appears to border
| on open hostility.
| fl0id wrote:
| They made gameportingkit, which got made into whisky app. So
| not totally hostile
| kalleboo wrote:
| Apple has always been anti-gaming. It's been in the companies
| DNA since the first Mac was derided as a "toy" for having a
| graphical user interface, and they overcompensated trying to
| make it a business machine with no games.
|
| About once a decade someone inside of Apple who is really
| passionate about games pushes some project through - you had
| GameSprockets in the 90's, you had someone convincing Valve to
| port Half-Life, you have GamePortingKit now, but it's just not
| in the companies culture to give game developers the long-term
| support they need.
| snarfy wrote:
| It was Jobs specifically that was anti-gaming. I'm not sure
| where Cook stands.
| whimsicalism wrote:
| Wish NixOS (or at least Arch) were supported on the level that
| Fedora is
| opengears wrote:
| NixOS is fully supported https://github.com/tpwrules/nixos-
| apple-silicon/blob/main/do...
| WorldPeas wrote:
| I used to daily drive this. Works quite well.
| whimsicalism wrote:
| yeah but it's a bigger pain
| whimsicalism wrote:
| and yet how do i install this gaming support on nixos?
| pxc wrote:
| You'd have to package FEX :D
|
| For the kind of person who wants to run NixOS on Apple
| Silicon or do Linux gaming on Apple Silicon in the first
| place, that's probably interesting and not too hard
|
| but if you're allergic to that, you might be able to figure
| something else out with Box64, which is already packaged in
| Nixpkgs
|
| x86_64 gaming on NixOS is of course well supported and has
| been for a long time. There's a 'native' package that I've
| always used and the Steam Flatpak is also available and
| works as well as it does anywhere
| whimsicalism wrote:
| we are talking about asahi linux. i think it is pretty
| clear that nixos isn't supported like a first class
| citizen because you have to do a fair bit of work to make
| all of the more recent userspace fixes work on NixOS. i
| run NixOS Asahi so I know.
|
| it was easier when Arch was a first class citizen but the
| advice nowadays you get upon encountering a problem on
| Arch is to switch to Fedora
| IntelMiner wrote:
| Perhaps if the NixOS folks want better support they
| should invest more time in keeping up with Asahi Fedora?
|
| The developers can use what they want. Marcan famously
| used Gentoo for many years
| fl0id wrote:
| Yeah yeah great, now please m3 support, or maybe before that
| support for internal mic and external displays/dp-alt. Pretty
| please? (Not complaining happy about any progress)
| Philpax wrote:
| kinda sounds like you're complaining, though
| fl0id wrote:
| Fair point :)
| wly_cdgr wrote:
| Ok, but why would a hardcore Linux person want to play games that
| embody everything they hate about Windows in their mode of
| production, data gathering practices, politics, etc?
| Philpax wrote:
| linux users like to have fun too
|
| Also, there are plenty of Windows-only games that aren't
| subject to those practices. Free games, itch.io games, GOG
| games, etc. There's a big world out there!
| lmm wrote:
| > there are plenty of Windows-only games that aren't subject
| to those practices. Free games, itch.io games, GOG games,
| etc. There's a big world out there!
|
| Those games are generally not AAA by definition, and often
| either already have a Linux build released, run acceptably
| under traditional emulation, or both.
| viraptor wrote:
| It's just a platform which is an available option. Nobody
| forces you to play games that you don't agree with for any
| reason.
| _fizz_buzz_ wrote:
| People use Linux for a wide variety of reasons and those
| reasons are very often not ideological. If the only reason to
| use Linux was ideological, Linux wouldn't be as popular as it
| is.
| umanwizard wrote:
| There are lots of reasons to run Linux. Not everyone who runs
| it is a free software ideologue.
| nottorp wrote:
| Stay away from the companies requiring their own game store /
| "club" (i'm looking at you Rockstar) account and you're likely
| to be fine.
| WorldPeas wrote:
| all I need is DP alt mode and I'm switching!
| jayd16 wrote:
| This makes me think of the classic clip of George Carlin telling
| a joke about the difference between heaven and hell [1].
|
| Is there a modern equivalent with FAANG, Microsoft, Sony, Valve,
| etc.?
|
| [1]https://www.youtube.com/watch?v=oR8xPC4NEro
| 0xDEAFBEAD wrote:
| In heaven, Microsoft is in charge of gaming, Amazon does the
| customer service, Apple is responsible for privacy, Facebook
| does the UI, and everyone works at Google.
|
| In hell, Apple is in charge of gaming, Google does the customer
| service, Facebook is responsible for privacy, Microsoft does
| the UI, and everyone works at Amazon.
| Arcanum-XIII wrote:
| "Amazon does the customer service"
|
| Sure this isn't Hell ? Because customer service at Amazon is
| a best non existant, at worse actively against you...
| raffraffraff wrote:
| Can't you famously just return stuff to Amazon within a
| month for basically any reason? I purchased a monitor from
| Dell and after a few weeks it became clear that there was a
| loose connection internally. It was extremely simple to
| prove. But getting it replaced was hell. I went through the
| whole process of creating a ticket, talking to 3 different
| people, taking photos of the thing from every angle and
| then after _they_ failed to get back to _me_ for a week, I
| emailed for an update and was told "Sorry sir, there was
| no activity on the ticket for over a week so the ticket was
| closed". It didn't matter that the delay was on their side.
| And no they wouldn't reopen the ticket, and no I couldn't
| refer to the old ticket, and no the old photos wouldn't
| work. Start over. Talk to several different support people
| _again_ , take all those photos _again_.
|
| My SIL bought a scanner from Amazon a few months back and
| never unboxed it because she was moving house. When she
| did, it was faulty. They took it back without much of a
| fight even though the month was up. She just said "I
| unboxed it yesterday, it's broken".
| chefandy wrote:
| It's changing. I imagine that was always intended to be
| an introductory thing to cement their position in the
| marketplace.
| xnzakg wrote:
| Good old enshittification. Make it good to attract users,
| then optimize for profit once the users can't leave.
| thaumasiotes wrote:
| What's stopping the users from leaving?
| fsflover wrote:
| https://pluralistic.net/2024/08/17/hack-the-planet/
| thaumasiotes wrote:
| That is not a compelling case for Amazon locking
| customers in. You can't make a purchase anywhere else
| because you paid for Amazon Prime?
| InDubioProRubio wrote:
| From citizen to shitizen.. we need a virtual sovyeet
| union in antartica.. systemic competition
| oarsinsync wrote:
| It's been like that for over a decade now. I hope you're
| wrong, but I fear you're not.
| jjk7 wrote:
| Not a chance -- if I can't easily return things I might
| as well go back to in-store or use aliexpress or similar.
| echelon wrote:
| Amazon's customer service (for the web store at least) is
| fantastic.
|
| Even if the core shopping/delivery service fails you, if
| you complain, they'll take the "customer is always right"
| position and make you whole. They'll refund or re-ship with
| no questions asked, without requiring you sending back
| anything or even so much as providing proof.
|
| I'm sure some people must take advantage of that level of
| customer service, but it's a really pleasant experience.
| leghifla wrote:
| Be cautious about calling their customer support if you
| have "bought" DRM stuff: you can be banned for any reason
| at any time.
|
| I complained about a failed delivery (broken box, one
| item missing). They refunded me but then immediately put
| me on a watch-list, threatening to ban me if I ever
| complain again. I will never buy anymore on amazon.
|
| See https://news.ycombinator.com/item?id=41555898
| apetrovic wrote:
| I bought Kindle Paperwhite with ads. Get tired of ads.
| Tried to pay Amazon to remove ads, for some reason it
| didn't work (I'm not from USA).
|
| Contacted customer support, explained what's the problem,
| the person on the other side said "wait a minute, sir" and
| removed ads from my Kindle without asking me to pay for it.
|
| That was a good experience with Amazon.
| aktuel wrote:
| Based on my own experience it is still fantastic. Not long
| ago I had an issue with an order and a real human called me
| back right away outside normal office hours. No waiting in
| a phone queue. And he was actually able to help me. If that
| is not excellent I don't know what is. I don't know of any
| other large company with a remotely similar customer
| experience.
| 35mm wrote:
| Facebook's UI is slow as hell.
|
| But otherwise this is accurate.
| 0xDEAFBEAD wrote:
| Perhaps I should have said "UI design" instead of "UI".
|
| I feel a little guilty, because it's all based on
| stereotypes, and I don't have enough firsthand experience
| to say which stereotypes are true.
| nkrisc wrote:
| It's fine since the original joke is based on stereotypes
| too. The stereotypes are the joke.
| meindnoch wrote:
| Facebook's UI is slow and buggy.
|
| Are you putting them in charge of UI because they've made
| React? (which is already a cardinal sin in my book)
| jayd16 wrote:
| This is good but the punchline needs to be punchier.
|
| I do like the implication that were working in the warehouse
| and not AWS but maybe it's too subtle.
|
| You might also be able to do something with the surprise
| switch from Linux to Linus. In heaven code is reviewed on
| GitHub [...], in hell [...] a nd your code is reviewed by
| Linus.
| tmtvl wrote:
| Shamus Young had a gaming equivalent (unfortunately I can't
| find the actual comic, the Internet Archive may have it,
| though): https://www.shamusyoung.com/twentysidedtale/?p=9866
| dang wrote:
| We detached this subthread from
| https://news.ycombinator.com/item?id=41802586. Not a criticism
| --it just went pretty far off topic.
| nxobject wrote:
| If only I had "canapplesiliconemulatewindowsgames.com"!
| amoss wrote:
| I'm slightly confused after reading about page alignment. Why
| would a 16k page be less aligned than a 4k page causing
| assumptions about pointers within those pages to break? The 4k
| pages on x86 are aligned on 4k boundaries, are the 16k pages on
| M1 aligned on <4k boundaries?
| y1n0 wrote:
| There are more 4k boundaries than 16k boundaries. The issue is
| code compiled for 4k boundaries running on a 16k system.
| amoss wrote:
| I'm missing something here. Assuming there are pages at 0k,
| 16k, 32k etc - all of those pages are aligned on 4k
| boundaries as 4k > 16k. So code written with the assumption
| that its pages are 4k aligned should have that assumption met
| when running with 16k pages. It is still early here and I
| have only had one cup of coffee. Am I misunderstanding
| something really obvious?
| dezgeg wrote:
| x86 app might mmap 8kb, then munmap the second 4kb and
| expect that to work. But not possible on 16k pages.
| amoss wrote:
| ah ok, so it would not be pointer alignment inside the
| pages but instead the assumption that page +4k is a page.
| MBCook wrote:
| I was a little confused by that in the article as well.
| It being a granularity issue makes more sense to me.
| gigatexal wrote:
| I'm just blown away at all the work they're able to do with a
| platform that they basically reverse engineered. I'm glad to be
| contributing to their efforts. I'm also waiting for when M3
| support comes! Such a cool group of engineers and hackers. I love
| it.
| sylware wrote:
| I still wonder why valve is that much reluctant at porting its
| proton stuff into the simple and plain C99 of wine/vkd3d.
| aleden wrote:
| Then what is proton written in? C++?
| sylware wrote:
| wine and vkd3d are plain and simple C99.
| seabrookmx wrote:
| Likely because their engineers are more productive in C++?
|
| Modern C++ with move semantics is a lot more easy to reason
| about and memory safe than C99, IMO.
|
| Since it's a greenfield project, they didn't have to worry
| about the nasty baggage of legacy C++ spaghetti that kills most
| projects.
|
| Just because you prefer "simple" C99 doesn't mean they do :)
| sylware wrote:
| I think there is something wrong with them because they are
| failing to see that the c++ syntax has an abysmal complexity
| which propagates the toolchain implementation.
|
| This is the only reason you need to make this language a
| definitive nono.
|
| They should be ashamed of themselves, and if they are not,
| well, they are toxic, and they are doing it at worldwide
| scale.
| seabrookmx wrote:
| Ironically, I think this comment is much more toxic than a
| developer writing free software in a language of their
| choosing.
| rowanG077 wrote:
| You are right of course that c++ is abysmal. What your are
| overlooking is that C is an even bigger trash fire nuclear
| foot gun.
| macrolime wrote:
| Does this mean we're closer to getting GPU support on Docker on
| Apple devices?
| ribit wrote:
| No.
| ZiiS wrote:
| For people like me who have been using Ashai for a while but are
| not Fedora natives; TIL `sudo dnf system-upgrade download
| --releasever=40; sudo dnf system-upgrade reboot` is necessary
| first as the normal upgrades left me on 39.
| joelthelion wrote:
| Realisticly speaking, is Asahi Linux usable right now for a
| random schmuck who just wants to use his computer?
| umanwizard wrote:
| Depends what kind of computer you have and what you want to do
| with it. M3 does not work at all. M1 is the best supported but
| even there some important things like microphones and
| thunderbolt still don't work.
| 2OEH8eoCRo0 wrote:
| So no
| umanwizard wrote:
| If you expect to be able to install it on any random Mac
| computer without thinking and have everything work, then
| no, it's not there yet. But I think just saying the answer
| to the OP's question is "no" would have been an
| oversimplification.
| MBCook wrote:
| I think my favorite little bit from the article is that they're
| using a VM to "fix" the page size differences between macOS and
| Windows.
|
| What an ingenious idea.
| qkhhly wrote:
| can i play black myth wukong with it?
| xuQH9W3HP8 wrote:
| I believe it would be pertinent to mention the following:
|
| What you're referring to as Linux, is in fact, GNU/Linux, or as
| I've recently taken to calling it, GNU plus Linux. Linux is not
| an operating system unto itself, but rather another free
| component of a fully functioning GNU system made useful by the
| GNU corelibs, shell utilities and vital system components
| comprising a full OS as defined by POSIX. Many computer users run
| a modified version of the GNU system every day, without realizing
| it. Through a peculiar turn of events, the version of GNU which
| is widely used today is often called Linux, and many of its users
| are not aware that it is basically the GNU system, developed by
| the GNU Project. There really is a Linux, and these people are
| using it, but it is just a part of the system they use. Linux is
| the kernel: the program in the system that allocates the
| machine's resources to the other programs that you run. The
| kernel is an essential part of an operating system, but useless
| by itself; it can only function in the context of a complete
| operating system. Linux is normally used in combination with the
| GNU operating system: the whole system is basically GNU with
| Linux added, or GNU/Linux. All the so-called Linux distributions
| are really distributions of GNU/Linux.
___________________________________________________________________
(page generated 2024-10-11 23:02 UTC)