[HN Gopher] Paving the Road to Vulkan on Asahi Linux
___________________________________________________________________
Paving the Road to Vulkan on Asahi Linux
Author : jiripospisil
Score : 485 points
Date : 2023-03-20 15:56 UTC (7 hours ago)
(HTM) web link (asahilinux.org)
(TXT) w3m dump (asahilinux.org)
| zamadatix wrote:
| Ahhh this is so awesome! I'm now kicking myself for upgrading to
| an M2 Max thinking all M2 models were supported already, now I
| have to wait to see this massive performance improvement.
| Fantastic work by the Asahi team, it's great to see this come
| together and the blog posts are excellent summaries of
| information I otherwise wouldn't be able to grok.
| tomcam wrote:
| Sincere, not kiss-ass question here: are they low-key becoming
| the best communicators in the Linux world? Or are there equally
| well-documented projects that just aren't getting the same heat
| for whatever reason?
| smoldesu wrote:
| My personal favorite is the This Week In[0] series of posts, if
| you want a simple way to keep track of notable changes.
| Technical blogposts are a pretty common practice among reverse-
| engineers, too; the Dolphin emulator has some great
| breakdowns[1], along with the people who reverse-engineered the
| Nintendo Switch's boot process[2] (and the rest of
| LiveOverflow's stuff).
|
| The Asahi writeups are great, but certainly not all there is.
| _Tons_ of reverse-engineering stuff and Linux documentation
| gets submit to this website, it just doesn 't generally do as
| well in the ranking system.
|
| [0] https://thisweek.gnome.org/
|
| [0] https://pointieststick.com/category/this-week-in-kde/
|
| [1] https://dolphin-emu.org/blog/
|
| [2] https://youtu.be/Ec4NgWRE8ik
| tomcam wrote:
| Sweet! Thanks for opening my mind!
| kitsunesoba wrote:
| I don't follow the space super closely so I may be mistaken,
| but the impression I get is that Asahi posts are more likely to
| be posted/shared in less niche tech-related spaces, whereas
| most other Linux news tends to stay firmly within the Linux/GNU
| sphere. So if nothing else, Asahi's communications are more
| generally visible.
| babypuncher wrote:
| I think the Asahi Linux project rekindles some of that
| excitement from the earlier days of Linux on PC-compatibles in
| the late '90s and early '00s.
|
| Some people might not remember this, but hardware support for
| Linux was a real crapshoot back then, and it's only "mostly
| smooth" on PC today because we have a quarter century of work
| building out drivers and modules for the platform.
|
| It's fun watching the breakneck pace at which they are going
| through the same processes with a brand new and proprietary
| consumer-oriented computing platform.
| Phelinofist wrote:
| LWN is super great
| tomcam wrote:
| So true. Thank you.
| shmerl wrote:
| _> We could add explicit sync to them, but that would break
| backwards compatibility..._
|
| At some point it would be good to break it and get rid of
| implicit sync in the Wayland use case. Keeping it forever is not
| worth it.
| renox wrote:
| Well the question is then do you have to update the Wayland
| clients?
| shmerl wrote:
| Probably. May be it's like Wayland-new and similar transition
| as from X? So they do need to coexist at the same time
| somehow, but also it can be a separate path.
| qalmakka wrote:
| Noob question: given that Zink exists and works quite well,
| wouldn't it been simpler to implement a Vulkan driver first and
| then just use Zink for OpenGL?
| risho wrote:
| I THINK that I remember marcan addressing this in one of his
| youtube interviews:
|
| This is actually what their plan is long term. That said in the
| short term it's way easier to implement opengl, it gives them a
| simple way to explore the hardware, and it also makes it so
| that real people will be able to run desktop linux on apple
| silicon macs way sooner.
| wtallis wrote:
| I think Zink requires a fairly feature-complete Vulkan
| implementation. Starting with a basic OpenGL implementation is
| definitely the quicker route to having a way to run and test
| some real applications.
| kitsunesoba wrote:
| To add to this, the faster route to something that runs was
| important because it was a goal of the devs to start
| dogfooding the distribution as soon as possible.
| ThatPlayer wrote:
| Zink docs list a bunch of Vulkan extensions you need to
| support to be able to run Zink. The Raspberry Pi's v3dv
| Vulkan driver doesn't even support all the requirements,
| though it is only missing 1 extension.
|
| Alyssa also works on the panvk Vulkan drivers for ARM Mali
| GPUs, which currently don't even support Vulkan 1.0.
|
| https://docs.mesa3d.org/drivers/zink.html#opengl-2-1
| OptionX wrote:
| This gonna sound like but I promise I'm not being facetious or
| trying to make a point. I'm genuinely curious. Whats the point of
| Asahi Linux? Why buy a Mac to run linux?
|
| If you're spending money on Mac I assume you want to buy in the
| whole MacOS environment, that's Apple value proposition in my
| eyes.
|
| Is it the M1, it that fast and better than similar priced laptops
| running an x86-64? Or is it the novelty of using ARM-based stuff?
| Is the market for ARM-based laptops still Apple only?
|
| Also is there relevant limitation on stuff you can't do on MacOS
| through homebrew or something and can on a Linux distro (not a
| mac user so I don't know).
| themadturk wrote:
| Speaking as a Mac M1 users, but not a Linux user (I have played
| with Asahi, think it's great, but don't need it right now), I
| think almost no one (or a very small minority of people) buys
| Mac hardware to run Linux. I think it's the inverse, people buy
| Apple hardware and then realize Linux is available and want to
| run it.
|
| Yes, I think the general opinion is that Apple's M1 and M2
| platforms are superior to Intel, even at the Mac's (supposedly)
| higher price point.
|
| Though MacOS is a complete Unix system, it is still
| proprietary, and there's nothing wrong with wanting to do your
| work (or play) on a free OS running on an excellent hardware
| platform. Asahi is giving people the opportunity to do that.
|
| Finally, though I can't speak for the Asahi team, I think also
| there's an element of "because it's there". Here is a great new
| hardware platform offering a incredibly difficult challenge to
| a group of people who live for this kind of thing. Why would
| they _not_ want to do it?
| nicoburns wrote:
| > Is it the M1, it that fast and better than similar priced
| laptops running an x86-64
|
| That's definitely part of it. You probably need to include
| battery life for it to really make sense. There's nothing else
| that will give you that performance _and_ close to 20 hours of
| battery life in a slim laptop form factor.
|
| There's also people who are mostly happy using macOS but may
| want to boot into Linux for specific tasks.
| flohofwoe wrote:
| The ARM Macs are seriously impressive hardware, even for just
| the build and tactile quality. But macOS is regressing quickly
| for professionals, there's too many design compromises to make
| the OS attractive and safe for 'casual users' but those same
| features are starting to become a hassle for professional
| users. Linux is the complete opposite of course, it's a hassle
| for casual users, but in exchange gives complete freedom to do
| what you want. Personally I'm still ok with macOS, but with
| each new macOS release the grass is looking greener on the
| Linux side ;)
| brightball wrote:
| If they make it possible for me to revive old Apple hardware I'm
| going to be very excited about this project.
| sedatk wrote:
| > Now we can run Xonotic at over 800 FPS, which is faster than
| macOS on the same hardware (M2 MacBook Air) at around 600*! This
| proves that open source reverse engineered GPU drivers really
| have the power to beat Apple's drivers in real-world scenarios!
|
| > Not only that, our driver passes 100% of the dEQP-GLES2 and
| dEQP-EGL conformance tests, which is better OpenGL conformance
| than macOS for that version. But we're not stopping there of
| course, with full GLES 3.0 and 3.1 support well underway thanks
| to Alyssa's tireless efforts!
|
| That's very impressive work. Congrats to Asahi and Alyssa.
| mouse_ wrote:
| Now that we can see Vulkan is around 4/3 more power efficient
| than Metal on the same hardware, I wonder if Apple will budge
| on their not-invented-here syndrome and allow for a real
| vulkan.kext on upcoming macOS versions. That would solidify it
| as not only the best graphical workstation OS, but also the
| best gaming OS, in my opinion. Part of me thinks they're
| avoiding this in worry of stepping on Microsoft's toes.
| brookst wrote:
| Vulkan is about 4/3 as power efficient _when rendering at a
| lower resolution_ than Metal
|
| Is that surprising? Fewer pixels usually means faster
| rendering.
| kuschku wrote:
| Metal was rendering at lower resolution than Vulkan here.
| rowanG077 wrote:
| It's not using Vulkan. It's using opengl.
| sebzim4500 wrote:
| >Part of me thinks they're avoiding this in worry of stepping
| on Microsoft's toes.
|
| What
| jmull wrote:
| From the article:
|
| * Please don't take the exact number too seriously, as there
| are other differences too (Xonotic runs under Rosetta on
| macOS, but it was also rendering at a lower resolution there
| due to being a non-Retina app).
| frogblast wrote:
| Not the least of which is likely power and clock state
| management (both on the CPU and GPU)
| babypuncher wrote:
| Native Vulkan support could also pave the way for a proper
| Mac version of DXVK. That could make Macs a lot more viable
| as gaming machines than they are now, even with the Rosetta 2
| overhead.
| m463 wrote:
| They just won't do it.
|
| Not that they can't, it would be nice. When they capitulated
| and came out with the intel macs around 2007ish, it became
| sort of a golden era. You could run macos and windows on
| their machines, and the smart computer folks started getting
| and usefully using macs.
|
| But now apple is years into a disappointing inward looking
| phase.
|
| What a decent future would be like... -
| vulcan/x - take back xquartz into the fold -
| actively pursue other linux graphics apis - apple does
| virtualization - maybe like rosetta but for all their
| software - run macos9 in a window - apple does
| containers - what if there was something like docker
| for macos natively? FROM macos:10.3 - apple
| actively supports open source projects - open up ios
| - let me see the filesystem - let me run a firewall
| (true privacy?)
|
| etc...
| pxc wrote:
| If Apple did all that, I would buy new hardware from them,
| and even leave their OS in place on it, for the first time
| in almost two decades.
| londons_explore wrote:
| If you go work for apple and use development hardware, you
| can have many of these things...
|
| But you lose the ability to talk about it.
| jen20 wrote:
| The move to MacOS by development and sysadmin types started
| long before Intel Macs with the release of OSX, when it was
| finally possible to get a laptop with a 5+ hour battery
| life that ran a Unix-like OS.
|
| Edit: The latest macOS has a great virtualization system
| built in, that many of the container platforms have already
| switched to.
| einherjae wrote:
| The PowerPC machines never did reach actual 5 hour
| battery time, 3 at most, on a good day, with the display
| off.
| jjtheblunt wrote:
| I think my "Lombard" or maybe "Pismo" powerpc powerbook
| did longer than 3 by far. And my iBook would go 8 hours
| no sweat.
|
| edit: fixed the nickname
| jen20 wrote:
| Mine managed 6-8 without too much problem throughout the
| time I was in university. And they had removable
| batteries so you could just switch them out if you ever
| needed to (I had two for my Powerbook, and that would do
| a full day on campus without ever having to go near a
| power outlet).
| ofchnofc wrote:
| Not that I disagree with the spirit, X is dead, and someone
| demo'd Wayland apps on macOS at NixCon Paris.
| spullara wrote:
| I wonder if the driver could be ported to Mac OS?
| gigatexal wrote:
| MacOS has been put on the back burner for Apple. It's all
| iPhone and iOS. It's clear that these scrappy hackers are
| going to fully utilize the hardware, clearly Apple doesn't
| care.
|
| Off-topic: FreeBSD had an early version of Grand Central
| Dispatch ported to it, I wonder if Linux could benefit from
| that maybe with some io-uring goodness.
| mort96 wrote:
| That ... really doesn't seem like the case. The macOS world
| has seen soo many big changes recently, with the complete
| visual overhaul of everything with Big Sur and then Ventura
| (whether you like that or not), the rewriting of a whole
| lot of applications and system stuff from AppKit to SwiftUI
| (again, whether you like that or not), porting the entire
| operating system to ARM, inventing an excellent x86_64
| virtualization layer, overhauling everything related to
| booting and system upgrades (even if it's just taking
| what's already built for iOS and heavily modifying it to
| work for Macs), new window management features, etc etc.
| That's a lot of engineering resources invested.
|
| The sorry state of Apple's OpenGL drivers is a part of
| their strategy. They're choosing to not invest in OpenGL,
| and have even officially deprecated it. They want you to
| use Metal instead.
| encryptluks2 wrote:
| [dead]
| phh wrote:
| As far as I know the backend to have the driver running on
| macos is already merged in mesa, so it should already work
| as-is?
| pedrocr wrote:
| So ARM Macs in OSX can now or soon have true Vulkan support
| with just a custom userspace app code targetting the kernel
| interface directly?
| nicoburns wrote:
| I don't think the vulkan driver exists in a usable state
| yet. So far there's only an OpenGL driver.
| Ruq wrote:
| Sometimes I really get to thinking (more than I usually do) about
| how much it sucks that so much hardware is completely
| undocumented and must be extensively reverse-engineered to even
| function outside of the realm of manufacturer ordained software.
| saagarjha wrote:
| I'm curious what rendering path Xonotic uses on macOS. Is it
| OpenGL? Apple supports that, but they run it on top of Metal,
| which leaves it buggy and with performance that's nothing to
| write home about.
| ElijahLynn wrote:
| Wow:
|
| > So what does this all mean for users of the Asahi Linux
| reference distro today? It means... things are way faster!
|
| > Since the Mesa driver no longer serializes GPU and CPU work,
| performance has improved a ton. Now we can run Xonotic at over
| 800 FPS, which is faster than macOS on the same hardware (M2
| MacBook Air) at around 600*! This proves that open source reverse
| engineered GPU drivers really have the power to beat Apple's
| drivers in real-world scenarios!
| raphlinus wrote:
| The big question I have is whether this can possibly support
| mandatory Vulkan features that are not available in Metal. The
| one I care about most is device scoped barriers, which in turn
| are needed for single-pass prefix sum techniques.
| rowanG077 wrote:
| From what I read on IRC full Vulkan is definitely the goal. And
| with some hacks should be supported by the hardware.
| raphlinus wrote:
| The specific thing I asked for is very technically
| challenging. One of the things I can offer is some tests that
| fail in, among other things, MoltenVk, as the mapping to
| Metal barriers is imprecise. I'm not sure whether the Vulkan
| CTS test will catch it, I've seen it miss memory model
| failures on other hardware. I'm always happy to chat about
| this if someone from the team wants to reach out.
| rowanG077 wrote:
| Alyssa and Lina are very responsive on IRC. #asahi-gpu on
| OFTC IRC network. You best ask them. Whether metal or
| moltenVk supports it doesn't matter. The hardware is
| capable of more.
| jamies wrote:
| Asahi Lina is truly an inspiration for open source reverse
| engineering. For those not aware, they also live stream their
| coding sessions quite often: https://www.youtube.com/@AsahiLina
|
| I'm excited for the day that I can easily install SteamOS (the
| modern one that runs on the Steamdeck) on an M2 Mac mini for an
| insanely powered "Steam console" for my living room TV.
| heywhatupboys wrote:
| I did _not_ expect the coding live streams of GPU engineering
| to be presented by a virtual anime persona with a squeaky
| voice.
| BenSahar wrote:
| Me either.
|
| I don't really get the V-Tuber thing (other than wanting to
| stay anonymous) but having code explained to me by an anime
| character is hilarious.
| prmoustache wrote:
| I don't mind that much thr anime character. But the voice
| is simply unbearable.
| pja wrote:
| Better believe in cyberpunk futures; you're in one.
| realjhol wrote:
| It's just Marcan being weird and creepy.
| TimTheTinker wrote:
| Marcan is very busy with a lot of other things, like
| upstreaming patches to the Linux mainline and improving
| platform support.
|
| He's been clear that he's not Asahi Lina... and he's also
| not a GPU hacker as far as I know.
| monocasa wrote:
| > and he's also not a GPU hacker as far as I know.
|
| I'm not really willing to indulge the greater discussion,
| but marcan has done some serious GPU hacking before,
| reverse engineering the microcode (not shaders) of the
| PS4's GPU to fix bugs that the PS4 hacked around in the
| drivers.
| realjhol wrote:
| Asahi Lina has the same spanish-sounding accent as Hector
| but pitched up and falsetto. "raider" - the hostname of
| the developer machine is that same as the hostname of
| Hector's machine.
|
| He even did a super-cringe "take over" video, where Asahi
| Lina "broke into" one of streams:
| https://www.youtube.com/watch?v=effHrj0qmwk
| sebzim4500 wrote:
| Personally, I was more suprised by the wii sports music and
| all the pink.
| ozarker wrote:
| I wonder how long it's going to take for games to start
| generally supporting ARM. Getting Linux running well on
| M1/M2/etc.. seems like only half the battle for making a good
| gaming machine out of these.
| est31 wrote:
| Desktop games*. ARM is a major target for gaming already.
| Games are 61 percent of app store revenue and 71 percent of
| play store revenue. And mobile games are the majority of the
| gaming market (51%).
|
| https://www.businessofapps.com/data/mobile-games-revenue/
| ajvs wrote:
| Getting Waydroid to run well on Linux has big issues still
| unfortunately if you wanted to use it to play Android
| games. Managed to get it working for a few months on a
| previous Ubuntu version, now can't get it to work at all.
| klooney wrote:
| 16k pages is going to make everything hard, I'm not holding
| my breath.
| nicoburns wrote:
| I think the Asahi project will release a 4k kernel version
| for those really need/want it at some point. As I
| understand there are no technical barriers, they're just
| delaying it to push more projects into supporting the 16k
| mode (which has better perf).
| sophacles wrote:
| What role does page size play here, and why is 16K a
| problem?
| jraph wrote:
| Sibling comments said it all, though "The Quest for
| Netflix on Asahi Linux", posted on HN [1] as a very good,
| detailed explanation of this and is a nice read.
|
| [1] https://news.ycombinator.com/item?id=35081510
| gavinsyancey wrote:
| The page size dictates the minimum size and alignment
| requirements for `mmap`, and also for regions of memory
| with different levels of protection (e.g. read-only vs
| read+write vs read+execute, etc). If a program expects to
| be able to `mmap` in 4kb chunks and can't, it will
| probably not work properly.
|
| On macOS, IIRC the userspace and kernel-space page size
| can be different and different userspace programs can run
| with diferent page sizes, however on Linux the page size
| is currently fixed across the system and set at compile
| time. The M1's IOMMU only supports 16k-aligned pages, so
| memory regions that need to be shared with other hardware
| (e.g. the GPU) need to be 16k-aligned. As such (and
| because Linux doesn't currently have great support for
| mixed page sizes), the Asahi Linux project has decided to
| run with 16k pages globally. However, that breaks a
| number of applications that are expecting 4k pages.
|
| More info:
| https://github.com/AsahiLinux/docs/wiki/Broken-Software
| londons_explore wrote:
| Pages have been 4k on a lot of systems for 30+ years.
|
| That means a lot of software has come to assume that.
|
| Certain memory buffers need to be page size aligned, or a
| multiple of pages long. Code can only be loaded to a page
| aligned memory address. Memory mapping and
| read/write/execute permissions can only be set on a per-
| page basis.
|
| If all that stuff is hardcoded now, there will be lots of
| fixes necessary to make things work properly with a
| different page size.
|
| And those fixes probably will need the software to be
| recompiled. And some software is only distributed in
| binary form, and getting someone to recompile it may be
| nearly impossible.
| fulafel wrote:
| Linux gaming has been developing in the opposite direction
| for a while, moving away from even x86 Linux native ports and
| toward running x86 Windows games under emulation.
| kccqzy wrote:
| They are running x86 Windows games under Wine. Remember
| that Wine stands for Wine is not an emulator.
| fulafel wrote:
| The recursive acronym tradition of course (GNU's Not
| Unix, Eine Is Not Emacs etc) traditionally implied the
| implementation being superset or better than the thing
| it's replacing and referencing in the acronym.
|
| Wine FAQ concludes
|
| > "Wine is not just an emulator" is more accurate.
| Thinking of Wine as just an emulator is really forgetting
| about the other things it is. Wine's "emulator" is really
| just a binary loader that allows Windows applications to
| interface with the Wine API replacement.
| foresto wrote:
| Try to remember that hardware emulation is not the only
| kind of emulation.
|
| Wine (written as WinE when I first encountered it, IIRC)
| emulates the Windows runtime environment.
| nicoburns wrote:
| I'd guess that will probably only happen when either windows
| gets widespread ARM adoption, or there's a new Xbox or
| PlayStation console that uses an ARM processor. Which...
| might be a while.
| mepian wrote:
| There's the Nintendo Switch which does get ports.
| cubefox wrote:
| The Nintendo Switch console already uses an ARM SoC by
| Nvidia. But I'm not sure whether this has meaningfully
| increased the probability of porting games to MacOS. The
| Switch uses Vulkan, but Apple uses Metal, a proprietary
| graphics API. Whether ports make sense probably depends on
| how strongly the Mac market share increases compared to
| Windows.
| jsheard wrote:
| The Switch _can_ use Vulkan but it 's unusual in offering
| a wide range of APIs, from OpenGL and Vulkan (the
| implementations likely derived from Nvidia's existing PC
| driver) or a custom low-level API tailored to the
| hardware called NVN. From what I gather from the
| emulation scene, the majority of Switch titles with non-
| trivial performance requirements use NVN. Even idTech,
| which famously uses Vulkan on PC, uses NVN instead for
| its Switch ports.
| smoldesu wrote:
| I wouldn't count on many developers going back to update old
| games with ARM support. It's more likely that the community
| will work to build some sort of Box86 + Proton stack to get
| games working, which should get a lot of the classics
| working[0]. From there, I think the struggle will be getting
| Box86 to run fast enough for modern games. Apple's ARM CPUs
| have great IPC, but that can still get annihilated when it's
| forced to simulate SIMD/AVX instructions. I assume Apple has
| some sort of vector acceleration framework in Apple Silicon,
| but it will take time and effort to reverse-engineer and
| implement.
|
| Things are certainly looking better than they did a couple
| years ago, but getting ARM to run x86 code faster-than-native
| is an uphill battle. Maybe even an impossible one, but I've
| been surprised before (like with DXVK).
|
| [0] Crysis on a Rockchip ARM SOC, for example:
| https://youtu.be/k6C5mZvanFU?t=1069
| nicoburns wrote:
| > I assume Apple has some sort of vector acceleration
| framework in Apple Silicon, but it will take time and
| effort to reverse-engineer and implement.
|
| I'm pretty sure it's just vanilla ARM NEON so I don't think
| it will take any reverse engineering. The Apple Silicon GPU
| is custom, but the CPU is just minor extensions to (and
| compatible with) AArch64. Rumour has it that this is
| because AArch64 was designed by Apple and donated to ARM
| (who Apple has close relationship with being that they were
| a founding member).
| saagarjha wrote:
| Apple support NEON (and uses it for most SIMD code) but
| it also has other proprietary ISA extensions for e.g.
| matrix multiply.
| smoldesu wrote:
| Interesting, that's what I was curious about. NEON is a
| bit slow last I checked, but at least Apple is sticking
| to spec here. It does make me wonder how much performance
| is left on the table for ARM architectures that want to
| emulate x86, though.
|
| ...it _also_ raises the question of how emulated titles
| fare against translated ones. It would be fascinating to
| see how something like Dark Souls Remastered performs
| through Yuzu vs DXVK on Apple Silicon.
| kitsunesoba wrote:
| It's a little frustrating how it's the norm in the game
| industry for companies to toss a binary over the wall and
| maybe patch it for a short period after release (not a
| given, ports in particular are vulnerable to being forever
| stuck at 1.0), with significant technical updates being out
| of the question until it's been long enough for them to try
| to sell you a remaster.
|
| Not having any experience in that industry, I wonder what
| the driving forces of this are. I suspect it's some
| combination of incredibly brittle codebases that cease to
| build if glanced at the wrong way and aversion to spending
| anything on games post-release.
| [deleted]
| stonemetal12 wrote:
| >aversion to spending anything on games post-release.
|
| I am pretty sure that is the answer. Unless the game is
| Cyberpunk levels of unplayable, there is no money in post
| release support unless it is bundled with DLC or GOTY
| releases.
|
| Back in the day it was pretty commonly sited figure that
| like 90% of a game's revenue came in the first 3-4 weeks
| of release. DLC and "seasons" are an attempt to stretch
| it out and make more off a single release, but I haven't
| heard how well that works.
| masklinn wrote:
| > DLC and "seasons" are an attempt to stretch it out and
| make more off a single release, but I haven't heard how
| well that works.
|
| That also dates back to back in the days, we just called
| it expansion packs.
| jacquesm wrote:
| I much prefer that model over services that suddenly
| disappear.
| izacus wrote:
| Not to mention the predatory subscription models that are
| rampant in mobile for software that is equally as broken,
| just costing more.
| kitsunesoba wrote:
| The "binary abandonment" model can have effectively the
| same result, though.
|
| An example that come to mind immediately is how much of a
| mess it is to get games that were built with Games for
| Windows Live like the PC port of Fable 3 running on
| modern Windows. It's possible, but there's a ridiculous
| number of hoops to jump through, none of which would be
| necessary if Microsoft shipped a quick and dirty update
| that pulled out the Games for Windows Live dependency.
| ynx wrote:
| Not supporting new platforms is because
|
| - Total dependency on an engine's build system
|
| - Lack of official support for uncommon platforms
|
| - Extremely low expected ROI even if it were possible to
| deliver on other platforms
|
| Gamedevs aren't in the business of building platforms,
| they're in the business (mostly) of consuming them and
| going where the players are.
|
| Gamedevs not updating is because
|
| - The engines themselves are indeed outrageously brittle
| at times, with LTS releases sometimes containing
| significant bugs that persist against newer releases of
| minor and major versions
|
| - New releases can actually cause dramatic regressions,
| not just in terms of bugs, but in terms of features,
| stability, binary size, and more
|
| - AAAs are wasting time chasing the next big thing, non-
| AAAs are struggling with few people and need to
| constantly be building the next thing because they're
| building products, not services
|
| - Gamedevs are largely media/entertainment companies,
| very few act like technology companies
| masklinn wrote:
| > I suspect it's some combination of incredibly brittle
| codebases that cease to build if glanced at the wrong way
| and aversion to spending anything on games post-release.
|
| The primary reason is that there's no money in it. Like
| movies, your "one shot" game (without some sort of
| continuous billing e.g. mmo, subscription, continuous
| stream of DLCs) makes most of its revenue in the first
| few weeks, and once the kinks are ironed out what it
| makes afterwards doesn't really depend on maintenance.
|
| Additional maintenance doesn't pay for itself, the
| producer doesn't pay the devs for that, and thus the devs
| take on the next contract to pay the bills. Not to
| mention additional maintenance is a risk.
| 58028641 wrote:
| The problem with Box86 is that it requires 32 bit ARM,
| which Apple Silicon does not support.
| [deleted]
| rubenfiszel wrote:
| I have been a thinkpad + arch devoted user for the last 10 years.
| I just want a nice ARM machine now and it seems the best option
| at the moment is Macbook Air M2 + Asahi. I do not know how to
| feel about it, maybe a bit of sadness, but I wish great luck to
| Asahi.
|
| Also every blog they post are great read!
| danieldk wrote:
| Why do you feel sad? Apple Silicon Macs are fairly open
| hardware, I see it as a win that there are ARM64 machines now
| that can run Linux and are competitive with x86_64.
| [deleted]
| rsaxvc wrote:
| Not the commenter, but I'm a little sad ThinkPads didn't keep
| up.
|
| They have an ARM64 offering, but it's PlaySkool premium.
| pengaru wrote:
| > Apple Silicon Macs are fairly open hardware
|
| If that were remotely true TFA wouldn't be about _reverse_
| _engineered_ GPU support on Apple Silicon. Nor would there
| really be a need for Asahi Linux to be developed in its own
| silo while it gets Apple Silicon support hammered out.
| Mike_12345 wrote:
| ThinkPad also has proprietary undocumented subsystems that
| are reverse engineered to work on Linux. Such double
| standards versus Apple.
| error503 wrote:
| Sure it has some undocumented subsystems, but compared to
| the Macs, it has a much stronger claim to openness. Apple
| has released virtually no information on the internals of
| these machines, and they aren't standard PCs like the
| Lenovos. Calling them 'open' is absurd, it would be hard
| to imagine a publicly released general-purpose computer
| that is _less_ open.
| Mike_12345 wrote:
| > but compared to the Macs, it has a much stronger claim
| to openness.
|
| False. Lenovo hardware contains a lot of proprietary
| undocumented parts that required reverse engineering to
| get working on Linux/BSD. The parts that didn't require
| reverse engineering (Intel GPU) were not made by Lenovo.
|
| Apple hardware is "open" as far as they don't try to
| prevent other operating systems to be installed.
| Apparently they made it reasonably straightforward for
| the Asahi team.
| error503 wrote:
| > False. Lenovo hardware contains a lot of proprietary
| undocumented parts that required reverse engineering to
| get working on Linux/BSD. The parts that didn't require
| reverse engineering (Intel GPU) were not made by Lenovo.
|
| How is it false? Whether the parts were made by Lenovo or
| not is irrelevant. It may not be 100% open (and this is
| probably not due to parts that Lenovo themselves
| created), but it is _substantially_ open, which is far
| more than can be said about the Macs, which are virtually
| undocumented system-architecture wise, and who knows what
| Apple will do in the future to hamstring efforts to use
| them outside the walled garden.
|
| > Apple hardware is "open" as far as they don't try to
| prevent other operating systems to be installed.
| Apparently they made it reasonably straightforward for
| the Asahi team.
|
| That is not "open", it's just "not openly hostile to
| reverse engineering...yet".
| Mike_12345 wrote:
| > but it is substantially open
|
| No it is not. I'm amazed that people just don't get this
| simple fact. The drivers were reverse engineered.
| ThinkPad is not an open platform. It contains some Intel
| and AMD stuff that is open, but you can't give credit to
| Lenovo for that.
| smoldesu wrote:
| > Apple hardware is "open" as far as they don't try to
| prevent other operating systems to be installed.
|
| 1. This is not true for "Apple hardware" as a rule.
|
| 2. Removing support for third-party OSes would be a
| shocking product regression for the Macbook.
|
| 3. If Apple's definition of "Open" excludes any
| transparent documentation or explanation, then they have
| provided precisely nothing.
|
| You contradict yourself by praising Apple for keeping
| standard features while deriding Lenovo for doing the
| same thing. All of this ignores the Linux certification
| Lenovo offers on their products, their Linux support
| contracts and even the freely-provided firmware updates
| through fwupd (something Apple will never provide).
| Regardless of whether you characterize "open"-ness as
| non-hostility or constructive support, Lenovo is still
| the more open company by a country mile. And Lenovo
| doesn't even do that much to-boot.
| Mike_12345 wrote:
| >You contradict yourself by praising Apple for keeping
| standard features while deriding Lenovo for doing the
| same thing.
|
| Putting words in my mouth. I never praised Apple and I
| never derided Lenovo. I am simply stating the facts. I am
| trying to explain that both companies have the same
| approach. Neither of them are open source idealists.
| Lenovo is not more open than Apple. Apple is not more
| open than Lenovo. I am pointing out the double standards
| and hypocrisy in this thread. I have owned many Lenovo
| and Apple products and I'm not a fanboy of any company.
|
| > 1. This is not true for "Apple hardware" as a rule.
|
| It is true for their laptops and desktops. iPhone/iPad
| are not relevant to this discussion.
| pengaru wrote:
| > ThinkPad also has proprietary undocumented subsystems
| that are reverse engineered to work on Linux. Such double
| standards versus Apple.
|
| The differentiator for decades now is intel-based
| laptops, including thinkpads, have been well-supported by
| mainline kernels including GPU support. Support that
| Intel has directly funded development and maintenance of.
|
| Where are the @apple.com commits supporting Apple Silicon
| in mainline Linux?
|
| Even AMD is better as of amdgpu.
| Mike_12345 wrote:
| Well supported by mainline kernels, thanks to reverse
| engineering undocumented proprietary Lenovo hardware.
| ThinkPads contain other components besides the GPU. Apple
| is not in the business of selling GPUs to other hardware
| vendors and the fraction of customers demanding Linux
| support is miniscule. Intel supports Linux as a business
| decision based on profitability, not open source
| idealism.
| goosedragons wrote:
| What components? Lenovo sells several ThinkPad models
| with Linux out of the box. The fingerprint reader is a
| source of trouble but it's not a Lenovo part.
| Mike_12345 wrote:
| [dead]
| smoldesu wrote:
| > Well supported by mainline kernels, thanks to reverse
| engineering undocumented proprietary Lenovo hardware.
|
| Such as? What "proprietary Lenovo hardware" is
| obfuscating my boot process, I'm really curious now.
|
| > Intel supports Linux as a business decision
|
| Yes. Intel supports Linux because the concept of selling
| Unix doesn't work. Take it from Apple, who gave up on
| selling their OS after realizing that people were
| _really_ only in it for the hardware. If Intel is the
| begrudging neighbor to Open Source software, then Apple
| is holding them in a Mexican standoff with their
| userbase. Somehow, Intel 's "business decision" manages
| to be the more civilized relationship between the two.
| Mike_12345 wrote:
| [dead]
| babypuncher wrote:
| This isn't really unique to Apple Silicon. The difference
| here is that most proprietary systems Linux has to work
| with on PC were reverse engineered many years ago, while AS
| is being reverse engineered today.
|
| The Asahi Linux developers themselves have praised the
| openness of Apple Silicon, not because they have access to
| documentation or source code that we don't, but because it
| seems Apple has gone out of their way to make sure their
| platform can securely accommodate third party operating
| systems even though they have no incentive to. It's
| surprising in contrast to Microsoft, who has been slowly
| trying to make booting Linux on PCs that ship with Windows
| harder and harder.
|
| I definitely think calling Apple Silicon an "open platform"
| is a bit of a stretch, but it's not the iron clad walled
| garden people think it is either.
| smoldesu wrote:
| > The difference here is that most proprietary systems
| Linux has to work with on PC were reverse engineered many
| years ago
|
| Such as what, though?
|
| Intel and AMD both wrote support for their systems
| themselves. Nvidia has long offered a proprietary driver
| for Linux users, and even Intel Macbooks were a shoo-in
| once the firmware is sorted out. It's been a _long_ time
| since someone has approached a full-scale reverse
| engineering project like Asahi, and I think
| characterizing it as "non-unique" undersells the amount
| of bespoke work here.
|
| Apple made the right move by continuing to allow third-
| party OSes, but that's not equivalent to building out
| support. The work required to bring up a black-box SOC is
| hugely distinct from using first-party drivers to boot
| into Linux through UEFI.
| cstrahan wrote:
| > Such as what, though?
|
| Drivers for WiFi, audio, Bluetooth, a heap of I2C devices
| like keyboards on laptops and temp/fan control, graphics
| cards, and much much more.
|
| Not a single company "built out support" for all these
| things. And none of it is covered by some common
| interface -- each must be reverse engineered (or
| implemented following reference manuals, if they are
| available). Intel and AMD did _not_ provide support for
| these, because they _can't_ -- the processor architecture
| is oblivious of these peripherals.
|
| I think you're underestimating how much volunteer work
| has been done to get Linux to be usable on _any_ machine.
| From your wording, I suspect you may think there are some
| grand unifying abstractions that, when implemented once,
| provide compatibility with most machines, and that Intel
| and AMD did just that. But that would be mistaken.
| babypuncher wrote:
| I'm comparing it more to the state of Linux on PC in the
| '90s and early '00s, when most vendors didn't care about
| Linux unless you were buying a server. Getting Linux
| running on a laptop back then was often a mess of hacky
| reverse engineered drivers, sometimes with incomplete or
| missing functionality.
|
| Of course what Asahi Linux has undertaken still feels
| like a bigger and more impressive task, I'm just saying
| that this kind of work is not entirely unprecedented. The
| current Linux ecosystem on Apple Silicon is more
| comparable to that of the PC Linux ecosystem from 25
| years ago than from today.
| rubenfiszel wrote:
| I am neither an Apple lover or an Apple hater. I think Apple
| produces extremely well polished products thanks to their
| vertical integration and have innovated in hardware pushing
| the frontier, especially with the ARM suites. However, they
| also have a fairly closed ecosystem in which they are trying
| to overprice things when they can abusing their dominant
| position. I would feel sad to contribute to its success but I
| also selfishly really need the best tool available.
| sbuk wrote:
| > _However, they also have a fairly closed ecosystem in
| which they are trying to overprice things when they can
| abusing their dominant position._
|
| They have ~16% of the global market. In no way do they have
| a dominant position.
| rubenfiszel wrote:
| Not wanting to start an anti-apple thread but I meant
| dominant position in their closed garden. Is that an
| abuse or not, I'll let the litigators decide.
| smith7018 wrote:
| Apple's computers are actually quite competitive when
| comparing price-to-performance. Beyond that, they have
| great build quality, battery life, components, and support
| which all adds up to being a great package for their cost.
| Seriously, this whole "Apple is too expensive" talking
| point died long ago. When the MacBook Air first came out,
| it was $1,800 ($2,500 adjusted for inflation) with a slow
| Intel C2D proc. Now you can get an M1 MacBook Air for $1k
| or an M2 for $1,200.
| nicoburns wrote:
| The base models are reasonably competitive. But if you
| want to upgrade anything then they become extortionate.
| nightski wrote:
| I'd argue price/performance is where they are the
| weakest. Especially when you want more than the bare
| minimum ram or ssd. An Apple replacement for my current
| notebook would cost over $5k and I spent a fraction of
| that.
|
| Battery life is really the core differentiator at the
| moment.
| wtallis wrote:
| > An Apple replacement for my current notebook would cost
| over $5k and I spent a fraction of that.
|
| What if you price out a replacement with the full RAM and
| SSD capacity you want from the OEM rather than as an
| aftermarket upgrade? I think the problem usually is not
| so much "Apple over-charges for upgrades" as it is "all
| OEMs over-charge for upgrades", with a side of "Apple
| uses non-upgradable storage".
| tadbit wrote:
| > What if you price out a replacement with the full RAM
| and SSD capacity you want from the OEM rather than as an
| aftermarket upgrade?
|
| Moot point. Of course if you tie your hands behind your
| back your options will be limited. The point, for the
| parent, is that they aren't limited by insane markup
| pricing.
| wtallis wrote:
| It's important to correctly identify the underlying
| problem and whatever tradeoffs are involved. It's
| unproductive to bitch specifically about Apple's
| expensive storage and memory upgrades when it's actually
| an industry norm. It might be more fruitful to discuss
| why OEMs in general are able to get away with such steep
| upgrade pricing, and it's definitely more interesting and
| appropriate for HN to debate the pros and cons of Apple's
| soldered memory and storage.
| kaba0 wrote:
| Did you take into account the different RAM architecture?
| Sure you can get bigger RAM, but that's not nearly the
| same as what the M series offers (and it shows on
| benchmarks) - you might be better off with a 16GB
| MacBook, than a 32GB other laptop. Oh, and it's not like
| this form factor/higher quality displays, etc would be
| cheap by other manufacturers.
| leidenfrost wrote:
| A someone with an M1 pro, keep in mind that there's no support
| for external monitors aside fron the main laptop display, yet.
| tpmoney wrote:
| Are you talking about support under Asahi because MacOS
| definitely does have support:
|
| > Display Support
|
| > Simultaneously supports full native resolution on the
| built-in display
|
| > at 1 billion colors and:
|
| >
|
| > Up to two external displays with up to 6K resolution at
| 60Hz at over a
|
| > billion colors (M1 Pro) or
|
| > Up to three external displays with up to 6K resolution and
| one external
|
| > display with up to 4K resolution at 60Hz at over a billion
| colors (M1 Max)
|
| >
|
| > Thunderbolt 4 digital video output
|
| >
|
| > Native DisplayPort output over USB-C
|
| > VGA, HDMI, DVI, and Thunderbolt 2 output supported using
| adapters (sold
|
| > separately)
|
| >
|
| > HDMI digital video output
|
| >
|
| > Support for one display with up to 4K resolution at 60Hz
|
| > DVI output using HDMI to DVI Adapter (sold separately)
|
| https://support.apple.com/kb/SP854?viewlocale=en_US&locale=e.
| ..
| oflebbe wrote:
| using an external monitor on an m1 pro at work.
| fsiefken wrote:
| Does this mean that SteamVR can run on Asahi Linux and macbook
| now?
| freedomben wrote:
| Even if you don't care a lot about Apple, this is still a great
| read.
|
| If you're a layman it can be hard to find information on how
| graphics works that is technical enough (uses terms like "user
| space" and "kernel"), but simple and high-level enough for
| somebody who doesn't know much. There is stuff like that
| throughout the piece.
|
| Here's the first example:
|
| > _In every modern OS, GPU drivers are split into two parts: a
| userspace part, and a kernel part. The kernel part is in charge
| of managing GPU resources and how they are shared between apps,
| and the userspace part is in charge of converting commands from a
| graphics API (such as OpenGL or Vulkan) into the hardware
| commands that the GPU needs to execute._
|
| > _Between those two parts, there is something called the
| Userspace API or "UAPI". This is the interface that they use to
| communicate between them, and it is specific to each class of
| GPUs! Since the exact split between userspace and the kernel can
| vary depending on how each GPU is designed, and since different
| GPU designs require different bits of data and parameters to be
| passed between userspace and the kernel, each new GPU driver
| requires its own UAPI to go along with it._
| derefr wrote:
| On a tangent from that quote, I'm curious how much extra perf
| we could squeeze from GPUs if the applications driving them
| were running in kernel mode (picture an oldschool boot-from-
| floppy game, but in the modern day as a unikernel), and
| therefore the "GPU driver" was just a straight kernel API that
| didn't need any context switching or serialized
| userspace/kernelspace protocol, but could rely on directly
| building kernel-trustable data structures and handing them off
| to be rendered.
|
| Presumably there was an era of console games that did things
| this way, back before game consoles had OSes -- but since that
| would be about 10-15 years ago now (the Gamecube + PS2 era)
| it'd be somewhat hard to judge from that what the perf margin
| for modern devices would be, since the modern rendering
| pipeline is so different than back then.
| speed_spread wrote:
| You could start anew from an OS like TempleOS with a flat
| memory space and direct access to hardware. But it will be
| hard to compare until you have real world scenarios with
| modern apps on both platforms.
| MrRadar wrote:
| That's the premise behind this amusing presentation:
| https://www.destroyallsoftware.com/talks/the-birth-and-
| death...
| cesarb wrote:
| > I'm curious how much extra perf we could squeeze from GPUs
| if the applications driving them were running in kernel mode
| [...] could rely on directly building kernel-trustable data
| structures and handing them off to be rendered.
|
| Probably not much. Applications already directly build data
| structures in userspace and hand them off to be rendered by
| the hardware; the kernel intervention is minimal, and AFAIK
| mostly concerns itself with memory allocation and queue
| management.
| monocasa wrote:
| Exactly. In fact Mantle/Vulkan/Metal/DX12 is based on the
| realization that with full GPU MMUs user space can only
| crash its own context, so it's safe to give access to
| console like APIs on desktop systems, and only have the
| kernel driver mediate user space as much as the kernel
| mediates access to the CPU.
| dijit wrote:
| > On a tangent from that quote, I'm curious how much extra
| perf we could squeeze from GPUs if the applications driving
| them were running in kernel mode (picture an oldschool boot-
| from-floppy game, but in the modern day as a unikernel)
|
| Presumably you're quite seasoned so I would assume you'd
| know: but Windows itself put a lot of its graphics rendering
| in kernel-space, they saw considerable performance gains from
| doing so but suffered 2 decades of severe bugs in rendering.
| endorphine wrote:
| And the end goal is to upstream all the work so that we can run,
| for example, Debian in Macs?
|
| Also, is anyone else afraid of the possibility of Apple deciding
| to screw us up by imposing restrictions to prevent people
| specifically from doing this for...reasons?
| kitsunesoba wrote:
| As I understand it, while the core pieces required for Linux to
| run on Apple Silicon will be upstreamed, there are parts that
| smooth the experience out and make it more practical that are
| unlikely to be integrated into other distributions, which
| necessitates Asahi's continued existence as a distribution.
| Wowfunhappy wrote:
| It should be noted, Marcan has said that the ultimate,
| eventual goal is for Asahi to no longer have to exist as a
| distro. That may be a long way off however!
| htag wrote:
| This is a similar model to the KDE Neon distribution, which
| upstreams basically everything but gives some benefit to
| developers working on the KDE project.
| kaba0 wrote:
| > Also, is anyone else afraid of the possibility of Apple
| deciding to screw us up by imposing restrictions to prevent
| people specifically from doing this for...reasons?
|
| According to Marcan, Apple explicitly went out of their way to
| support secure booting of other OSs as well.
|
| Also, it's hard to predict, but I think it would only increase
| revenue if the small, but rich linux-using software community
| would choose MacBooks as "the next thinkpads", and it's not
| like most people would not just have both OSs available and
| switch between them.
| leonewton253 wrote:
| I think better time would be spent getting Full Vulkan on MacOS
| with proton support. The amount of people wanting to run Linux on
| Macs is waaay lower than with Windows PCs.
| malermeister wrote:
| Hard disagree. Apple Silicon is by far best in class, but the
| OS it ships with feels like a toy to me. Can't wait for the
| hardware to be liberated.
| NexRebular wrote:
| Can't wait indeed, they will be excellent BSD machines when
| all is said and done.
| radicaldreamer wrote:
| Why does MacOS feel like a toy? It's the primary OS for a
| huge number of developers (at least in the Bay Area) who are
| doing plenty of production work on it every day.
|
| Fully support bringing a well supported Linux distro to the
| hardware but MacOS is nothing like ChromeOS or some sort of
| thin client operating system.
| ofchnofc wrote:
| [dead]
| sebzim4500 wrote:
| Not GP but I also believe that MacOS feels like a toy.
|
| All the icons are jumping around everywhere, everything is
| colourful, it's 2023 and you can't maximize a window or
| make it take up half the screen, etc.
|
| I also hate the touch bar but I'd probably get used to
| that. I used a pre-touchbar Air for a few months and going
| back to windows felt amazing.
|
| I am eagerly waiting for Asahi to be usable as a daily
| driver, my next laptop will probably run Apple silicon.
| daaaaaaan wrote:
| Mouse over the green window button, hold down option and
| you can maximize, and tile to the left/right of the
| screen.
| [deleted]
| Bloomy22 wrote:
| It is also possible to configure the double-click
| behaviour on the title bar to zoom the windows without
| fullscreen them...
| malermeister wrote:
| * poor window management
|
| * no built-in package manager
|
| * low hackability/customizability
|
| * constant code signing prompts with 3rd party software, my
| OS is fighting me trying to use software
|
| * constant prompts to please finally sign into icloud
|
| * deprecated OpenGL
|
| * general handholding in the OS getting in the way
| kouteiheika wrote:
| With all due respect, no offense, but I find comments like this
| a little bit disrespectful.
|
| These are a couple of volunteers, working for free, and you're
| saying that it'd be better for them to volunteer their time for
| the benefit of a huge trillion dollar corporation and work on
| something that the aforementioned corporation explicitly does
| _not_ want (but could very easily do itself).
| DeathArrow wrote:
| Mail Apple and ask for Vulkan support.
| p_j_w wrote:
| Then go ahead and do it, but why should the Asahi Linux people
| take this into consideration? The entire point of the project
| is to get Linux running on ARM Macs. That's what they
| personally want and there's no reason for them to make market
| share considerations.
| matthoiland wrote:
| I love reading things like this that reinforce my belief that I
| personally know very little about anything. _back to writing CSS
| for me :)_
| ahelwer wrote:
| The key to understanding this world is that nearly everybody
| does these things full time for their own interest. Trying to
| accumulate this level of expertise on nights & weekends is an
| express train to burnout. On the other hand if your financial
| needs are satisfied (worked at FAMANG for a decade while being
| frugal, doing contracts for 1/3 of the year & being frugal,
| married a doctor, got into cryptocurrency early, donations if
| you're anomalously popular) and you're reveling in the joy of
| self-indulging exploration, learning, and tinkering without
| having to worry about giving an update at daily standup
| tomorrow, it's amazing what you can accomplish. Knowledge is
| cumulative. Within a few years many people could be at this
| level. This is part of why UBI is so popular within software
| engineering circles, because you really don't need _that_ many
| resources to just be in it for the love of the game.
|
| On the other hand having kids is basically anathema to being
| able to live this life. So you are choosing work (in a broader
| sense of term than conventionally used) over family.
| PaulDavisThe1st wrote:
| I'm the father to a 27 year old, step-father to a 31 and 33
| year old. I started my journey into audio software when my
| daughter was about 2 years old and I was a stay-at-home
| parent. I'm often considered one of the most senior people in
| audio software development in the world now (a bit of an
| illusion caused by the invisibility of people inside
| proprietary development processes, but I'll take it).
|
| I can take you on a deep dive into every aspect of audio
| software. My kids and my wife did not obstruct that, and if
| anything, having responsibilities towards them forced me to
| be even better at the process that got me to where I am
| today.
| Version467 wrote:
| Thanks for posting this. I see kids in my not too distant
| future and while I personally don't believe this I see lots
| and lots of comments on the internet saying that having
| kids basically stops everything else dead in its tracks for
| ~2 decades.
|
| There are so few people with experiences like yours that
| it's sometimes hard to not let that get into my head.
|
| So it's refreshing to see a different opinion.
| ahelwer wrote:
| A lot of generalities don't really apply to you if you
| were one of the two other people building Amazon.com in
| Bezos' garage: https://www.wired.com/1999/03/bezos-3/
| Version467 wrote:
| I don't know what I expected, but it certainly wasn't
| that. Thanks for letting me know. Though I really don't
| know what to make of this now (if anything).
| PaulDavisThe1st wrote:
| Maybe see my reply adjacent to yours in this subthread.
| PaulDavisThe1st wrote:
| Amzn allowed me to (a) be a stay-at-home parent (b) work
| on a FLOSS project for several (maybe 10) years without
| needing to generate any revenue.
|
| It did not have any impact on my curiosity or learning
| process during the journey I've been on for the last 25
| years.
|
| The point is the the presence (or absence) of children is
| not determinative of your ability to deep-dive. Or so I
| am claiming.
| ahelwer wrote:
| Right! My original quip about children was more about
| financial constraints than anything. Not trying to shame
| you or anything, I think using the Amazon windfall to
| work on FOSS is absolutely the dream and one of the best
| possible ways you could have contributed to the world.
| PaulDavisThe1st wrote:
| It's a fair point that being able to tinker on FLOSS
| while my kid(s) were at school rather than having a full
| time job and leaving the tinkering for late at night was
| probably quite beneficial.
|
| Nevertheless, I would still like to claim that kids or
| not is not determinative of your ability to do the deep
| dive.
|
| I'd also like to think that some distance in the future,
| it will be raising my daughter will turn out to have been
| the best possible way I contributed to the world. This
| software stuff is, in the end, a distraction for the most
| part (especially when there are/were already so many
| options in the particular niche that Ardour occupies).
| ahelwer wrote:
| Sorry, I should have specified: my post was specifically
| concerning FOSS development. Of course people inside large
| companies developing proprietary software can attain a high
| level of knowledge about whatever field even if they have
| families, because they're working on it full time over many
| years and being paid for it.
|
| Although it's unclear, perhaps you are talking about FOSS
| development (actually looking up Ardour from your profile,
| yes you definitely are). That's very impressive, then! So
| you did manage to juggle having a full-time job, FOSS
| development, and a family?
| PaulDavisThe1st wrote:
| I was initially financially independent (due to amzn),
| playing the role of stay-at-home parent and slowly
| expanding the FLOSS project's role; in about 2008, the
| FLOSS project became my only source of revenue.
| ozarker wrote:
| "Since the Mesa driver no longer serializes GPU and CPU work,
| performance has improved a ton. Now we can run Xonotic at over
| 800 FPS, which is faster than macOS on the same hardware (M2
| MacBook Air) at around 600*! This proves that open source reverse
| engineered GPU drivers really have the power to beat Apple's
| drivers in real-world scenarios!"
|
| Wow that's impressive!
| dev_tty01 wrote:
| It is impressive, but worth noting that the macOS version was
| running x86 code under Rosetta. Hmm, I guess that's also
| impressive...
| carlycue wrote:
| It's kind of hilarious how the entire conversation about CPU's
| have steered towards Apple's chips. No one talks about or
| mentions AMD or Intel chips anymore outside of gaming circles...
| grog454 wrote:
| Are there server circles? I'd guess they talk about intel and
| AMD more than Apple.
| LeonenTheDK wrote:
| Definitely are, lots of talk of general ARM usage in the
| server space in those circles, particularly when it comes to
| AWS' Graviton, or other hardware/cloud offerings.
| diffeomorphism wrote:
| Because it is kinda boring? Just like M2 is much less
| interesting than M1. Current gen Intel or AMD chips are like
| 10% to 20% faster than apple (which apple acknowledges in their
| marketing and hence points at performance per Watt). Intel uses
| about the same energy at idle but about double at load. AMD has
| about the same efficiency (work per Watthour) under load but
| worse idle. And now nothing is happening until the next
| release.
|
| > No one talks about..
|
| Yeah, nobody cares unless something new comes out.
| sampa wrote:
| you live in a bubble
| smcl wrote:
| I follow Lina, Alyssa and Hector from the Asahi team on Mastodon
| and all three were great choices to follow. They all post
| interesting stuff regularly, and Lina in particular is great. She
| regularly livestreams her coding sessions, announcing what she'll
| work on ahead of time so you can set yourself a little reminder.
| I'm really in awe of these people.
| whatever1 wrote:
| Does anyone pay these people for their awesome work ?
|
| Every time I see their progress in a such undocumented space, my
| jaw drops. Huge respect.
| dharmab wrote:
| Most of them accept donations:
|
| > If you want to support my work, you can donate to marcan's
| Asahi Linux support fund on GitHub Sponsors or Patreon, which
| helps me out too! And if you're looking forward to a Vulkan
| driver, check out Ella's GitHub Sponsors page!
|
| Lina also accepts donations on her streams. I think Alyssa is
| funded by her employer, but I'm not sure.
___________________________________________________________________
(page generated 2023-03-20 23:00 UTC)