Earlier quoted context omitted.
100% this. Yes, Hector went nuclear, but he begged Linus to step in and provide leadership (either merge or reject) and instead Linus ignored the whole technical issue with regards to rust being totally blocked. Even now with Hector out of the picture, there’s still no suitable path forward for rust in Linux. No wonder why people are giving up (exactly what the blockers want).
Counterpoint: prior to going nuclear, is there any evidence that Marcan directly tried to get Linus's attention, given the huge quanity of mailing-list mail Linus is sure to get every day? I only see Danilo doing that in that thread. And admittedly Linus didn't respond (and Greg KH only minimally responded). But even CC probably means a lot of mail for top maintainers, and at that point I don't see anything that woul…
Resigning as Asahi Linux project lead
871–880 of 1001 posts
Re: Resigning as Asahi Linux project lead
#872Earlier quoted context omitted.
100% agree. For the last few years, I've been saying the following regularly (to friends, family and coworkers): communication is the hardest thing humans will ever do. Period. Going to the moon, launching rockets, building that amazing app... the hardest thing of all is communicating with other people to get it done. As a founder (for 40+ years and counting) I manage a lot of different type of people and communicati…
> (yes, this is direct from stoicism) stoics don't write multi-paragraph goodbye letters
Marcus Aurelius wrote extensive personal reflections in his "Meditations". Seneca wrote detailed letters to friends and family discussing philosophy, life, and death. Epictetus discussed death extensively in his Discourses, but sure, they were philosophical teachings rather than personal goodbyes.
They focus on acceptance and equanimity rather than formal farewells.
That said, "control what you can and forget the rest" is indeed stoicism, albeit simplified.
Re: Resigning as Asahi Linux project lead
#873Earlier quoted context omitted.
> He needs to stop fighting with the winds he can't control. Users gonna be users, and people gonna be people. Everyone won't be happy, never ever. Right - but it kinda sounds like he's facing headwinds in a lot of different directions. Headwinds from Apple, who are indifferent to the project, stingy with documentation, and not inclined to reduce their own rate of change. Headwinds from users, because of the stripped…
Another uphill battle that I haven't seen anyone mention is just how good mobile AMD chips got a year or so after the M1 release. I wouldn't buy a Mac to run Linux on it when I can buy a Lenovo with equally soldered parts that'll work well with the OS I wanna run already.
Re: Resigning as Asahi Linux project lead
#874This part of the post is being overlooked: Then 2024 happened. Last year was incredibly tumultuous for me due to personal reasons which I won’t go into detail about. Suffice it to say, I ended up traveling for most of the year, all the while having to handle various abusers and stalkers who harassed and attacked me and my family (and continue to do so). This is _not_ ok in any form, what the actual hell?
It seems like mostly personal problems, and if this is not going into detail, whoo I don't know what detail would be: https://vt.social/@lina/112887550181123672 https://docs.google.com/document/d/1W2Vvwg0rwSVb5r4TQ_NmAF8S... They pretty much straight up confirm the identity of Asahi Lina, so enough with the gaslighting that merely mentioning this (and having a totally reasonable discussion on contributor persona poli…
Shouldn't we be above those kind of childish telenovela shit?
Re: Resigning as Asahi Linux project lead
#875Earlier quoted context omitted.
Implementing (or removing) Drop on a type is a breaking change for that type's users , not the language as a whole. And only if you actually write a trait that depends on types directly implementing Drop[0]. Linux breaks internal compatibility far more often than people add or remove Drop implementations from types. There is no stability guarantee for anything other than user-mode ABI. [0] AFAIK there is code that ac…
> is a breaking change _for that type's users_, not the language as a whole. And yet the operating mantra...the single policy that trumps all others in Linux kernel development... is don't break user space.
GCC also occassionally breaks compability with the kernel, btw.
Re: Resigning as Asahi Linux project lead
#876Earlier quoted context omitted.
Another uphill battle that I haven't seen anyone mention is just how good mobile AMD chips got a year or so after the M1 release. I wouldn't buy a Mac to run Linux on it when I can buy a Lenovo with equally soldered parts that'll work well with the OS I wanna run already.
A lot of it is simply AMD getting on newer TSMC nodes. Most of the Apple's efficiency head start is better process (they got exclusive access to 5nm at first).
Many ARM SOC are designed to run on battery only so the wireless packages and low power states are better, my AMD couldn't go below 400mhz.
But yeah the "Apple M hardware is miles and leagues away" hypetrain was just a hypetrain. Impressive and genuinely great but not revolutionary, at best incremental.
I hope to be able to run ARM on an unlocked laptop soon. I run a Chromebook as extra laptop with a MediaTek 520 chip and it's got 2 days battery life, AMD isn't quite there yet.
Re: Resigning as Asahi Linux project lead
#877Earlier quoted context omitted.
Not even close to 100%, the reason that it feels like every major C codebase in industry is pinned to some ancient compiler version is because upgrading to a new toolchain is fraught. The fact that most Rust users are successfully tracking relatively recent versions of the toolchain is a testament to how stable Rust actually is in practice (an upgrade might take you a few minutes per million lines of code).
IDK about "industry" but I can't think of any prominent C or C++ open-source codebase that requires a specific version of gcc or clang to compile.
Here's one example of workarounds in ~100 packages that broke when upgrading to GCC 10: https://github.com/search?q=repo%3ANixOS%2Fnixpkgs%20fcommon...
Re: Resigning as Asahi Linux project lead
#878Earlier quoted context omitted.
This is every successful product, small, medium, large. I've never ever worked on a big corporate or small personal project and not experienced this. The secret is to have a healthy system for taking in those requests, queueing them by priority, and saying, "you are 117 in the queue, you can make it faster by contributing or by explaining why its higher priority". You can't let feature requests get to you, the moment…
Yep. I've been working on Ardour for 25 years now, and it took me 7-10 years to develop the right kind of skin for dealing with "user feedback". For me, the right kind of skin was basically to shed such stuff like water off a duck's back. Whether someone is saying "I've been using Logic for 10 years and this is so much easier and intuitive" or "You should be ashamed for asking anyone to pay for this steaming pile of…
Re: Resigning as Asahi Linux project lead
#879Earlier quoted context omitted.
> It's comments like these that causes people to wear out. No it isn't. You - fundamentally - don't get to control what people say to you. You need to filter how to take that. And that's incredibly hard. Especially in open source. You need to both be able to ignore (some version of "idiots, who can't be bothered to read") and be openminded enough to take weird requests, because they could be the starting point of a n…
> And that's incredibly hard >You need to both be able to ignore > and be openminded enough to ... I'm know it's pretty pointless to argue because we see the world in a different way. But realize the (quoted) requirements are you putting on the open source developer. A developer without these skills will burn out.
> A developer without these skills will burn out.
And I think that's something that should be said more directly. If you want to do open source (as in become the provider of load bearing infrastructure): Then you really need to realise what you are getting yourself into. Would I like that to be different? Sure. Would I bet on that changing? Absolutely not.
And yes, that absolutely means you can either do open source as a hobby, then nobody should ever be willing to rely on the thing you are building (because you can just say "i've got better things to do than fixing the security bug you got") or you can attempt to get other people to use and rely on it, but then you have to find a way not to burn out.
Re: Resigning as Asahi Linux project lead
#880Earlier quoted context omitted.
> Writing the code is at most 5% of software development IME. This really depends on what you work on. And how good the managers are on your team. I talked to a manager at Google once about how he saw his job. He said he saw his entire job as getting all of that stuff out of the way of his team. His job was to handle the BS so his team could spend their time getting work done. This has been my experience in small pro…
Even in the Google example, it's still in the low percentages when you view it as a system . All the manager did was efficiently allocate resources. It didn't reduce the non-programming work - it simply moved it elsewhere.
Someone who is in a management position, has good political skills and good connections will be way more efficient at doing some of this non-programming work.
This is something that even C-levels forget. Something that takes a CTO 2 minutes to do can take several months for a regular developer to achieve, and I have plenty of experience on and plenty of examples of that.