Audience. This will only reach people who agree. It's a lesson Dems just haven't learned yet about where America is in discourse:
Hillary: "This great economy, based on the new globalization means that we will with the help of economists transform Pennsylvania's economic infrastructure away from dirty fuels."
Donald: "I'm going to save coal."
Kamala: "My macroeconomists say this is the best economy the US has ever seen, and they say my plan to help will put money back in American pockets"
This is something that most people engaged in internet discourse could learn as well. It's often not productive to write a long response to a pithy sound-byte argument.
Not only is that losing the engagement economy, but onlookers to the thread are far more likely to read and latch onto the smaller soundbites. Longer replies also give critics more gristle to latch onto - you may think a long post covers all its bases, but you're really just giving people more avenues of rebuttable.
Better to be succinct, and if important context is left out, respond to it as concerns are raised.
Honestly, yes. To sway public opinion, you have to meet your audience where they get their information. I know that my mother gets most of her news from TikTok unfortunately. Reaching out to the public through as many avenues as possible is absolutely necessary at this point.
> But then also came the entitled users. This time, it wasn’t about stealing games, it was about features. “When is Thunderbolt coming?” “Asahi is useless to me until I can use monitors over USB-C” “The battery life sucks compared to macOS” (nobody ever complained when compared to x86 laptops…) “I can’t even check my CPU temperature” (yes, I seriously got that one).
This sounds so rough. I can't imagine pouring your heart out into this labor of love and continue to have to face something like this. Back in the early days of Quora, when it used to be good, there used to be a be nice be respectful policy (they might still have it), I wonder if something like that would be helpful for open source community engagement.
Regardless, major props to Marcan for doing the great work that he did, our community is lucky to have people like him!
First of all, I wholeheartedly applaud Marcan for carrying the project this far. They, both as individuals and as a team proper, did great things. What I can say is a rest is well deserved at this point, because he really poured his soul into this and worn himself down.
On the other hand, I'll need to say something, however not in bad faith. 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. Even you integrate from applications to silicon level, not everyone is happy what Apple has accomplished technically. Even though Linux is making the world go on, we have seen friction now and then (tipping my hat to another thing he just went through), so he need to improve his soft skills.
Make no mistake, I'm not making this comment from high above. I was extremely bad at it, and I was bullied online and offline for a decade, and it didn't help to be on the right side of the argument, either. So, I understand how it feels and how he's heartbroken and fuming right now, and rightly so. However, humans are not an exact science, and learning to work together with people with strong technical chops is a literal superpower.
I wish Hector a speedy recovery, a good rest and a bright future. I want to finish with the opening page of Joel Spolsky's "Joel on Software":
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 communication failures are the largest common thread.
Humans have a very, very tough time assuming the point of view of another. That is the root of terrible communication, but assumptions are right up there as a big second.
On the Marcan thing... I just want to say, control what you can and forget the rest (yes, this is direct from stoicism). Users boldly asking for features and not being grateful? Just ignore them. Getting your ego wrapped up in these requests (because that's what it is, even if he doesn't want to admit it), is folly.
I contributed to Marcan for more than a year. I was sad to see the way it ended. I wish him well.
> Humans have a very, very tough time assuming the point of view of another. That is the root of terrible communication, but assumptions are right up there as a big second.
That's very true. I recommend some people to read "The Four Agreements", because that thin book has real potential to improve people's lives through active and passive communication.
Also worth being aware of Robert Kagen's adult development model [0] or something similar; that gives people a framework to go from "humans seem" to some actual percentages and capabilities.
Spoiler, but approximately 66% of the adult population make do without being able to maintain their own perspective independently of what their social circle tells them it is. I imagine that would make it extremely challenging to determine what someone else's perspective is. Especially if that perspective is being formed based on empiricism rather than social signalling.
And if we're making book recommendations, Non-Violent Communication is a gem of an idea.
That's pretty fascinating, thanks for sharing it! It's a pretty compelling explanation as to why some people seem to be completely unable to logically explain their reasoning for certain beliefs and just fall back to "well it should be so because everybody says so."
Ta. I learned about it from my favourite HN comment (https://news.ycombinator.com/item?id=40856578) and have spent the last 6 months wondering why people don't bring it up more. It may just be a model but it has much explanatory power for why there seem to be so many "stupid" people around. I don't really have the word to describe them; people who are technically reasonable but not convinced by arguments or evidence.
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.
If they've written "many many words over thousands of years" for the merits of their philosophy, they are also perfectly capable to write multi-paragraph goodbye letters. That's the bearing it has on the parents claim. And many did.
Why you felt the need to add your comment, is a more apt question.
> If they've written "many many words over thousands of years" for the merits of their philosophy, they are also perfectly capable to write multi-paragraph goodbye letters. That's the bearing it has on the parents claim. And many did.
Eh, not really - "multi-paragraph goodbye letters" here refers to the overly dramatic fad that internet denizens sometimes engage in when they leave communities, and they tend to have a lot of whining.
Those types of goodbye letters are not the types of goodbye letters stoics would write.
> Why you felt the need to add your comment, is a more apt question.
If you were able to pick up so swiftly what the person I replied to was implying, you too should be able to have picked up that I replied because I disagreed with that implication.
I doubt this, but would be curious to see a source.
> You could then just say that you disagree and state your case, without rudely asking why they posted it.
I didn't find it rude at all, and your reply was far less productive than my IMO neutral question. You took offense on behalf of someone else and inserted yourself when it was unnecessary and entirely reliant on your interpretation and perception. Now we're discussing your perceived slight instead of anything of substance.
> 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 down experience.
Headwinds from the kernel team, who are in the unenviable situation of having to accept and maintain code they can't test for hardware they don't own; and who apparently have some sort of schism over rust support?
Be a heck of a lot easier if at least one of them was on your side.
> Headwinds from Apple, who are indifferent to the project, stingy with documentation, and not inclined to reduce their own rate of change.
That is part of the challenge he chose to take on.
> Headwinds from users, because of the stripped down experience.
Users can be ignored. How much you get users to you is your own choice.
> Headwinds from the kernel team, who are in the unenviable situation of having to accept and maintain code they can't test for hardware they don't own
You don't have to upstream. Again, it's not the kernel team that chose to add support for "hostile" hardware so don't try to make this their problem.
> and who apparently have some sort of schism over rust support?
Resistance when trying to push an entirely different language into an established project is entirely expected. The maintainers in question did not ask for people to add Rust to the kernel. They have no obligation to be welcoming to it.
> Be a heck of a lot easier if at least one of them was on your side.
Except for the users all the conflicts are the direct result from the choice of work. And the users are something you have to choose to listen to as well.
"Their boss" - I'm not sure that boss is best word here.
"did ask for it" - did he? Because from my perspective it looks more like he gave the bone for corporations so they will shut up for rust in kernel. After some time it will end up "Sorry but rust did not have enough support - maintainers left and there were issues with language - well back to C"
I don’t think that’s an accurate way to describe what happened, no. He seems to be enthusiastic about it and to genuinely want it to succeed.
> "A lot of people actually think we're somewhat too risk averse," said Torvalds. "So when it comes to Rust, it's been discussed for multiple years by now. It's getting to the point where real soon now, we will actually have it merged in the kernel. Maybe next release."…
> "Before the Rust people get all excited," the Linux kernel creator and chief said. "Right? You know who you are. To me, it's a trial run, right? We want to have [Rust's] memory safety. So there are real technical reasons why Rust is a good idea in the kernel…”
> “And hopefully, it works out, and people have been working on it a lot, so I really hope it works out…”
Last September he was still insisting he thinks the project will not fail, and he was not exactly subtle in his criticism of maintainers who refuse to engage with it in good faith.
> "Clearly, there are people who just don't like the notion of Rust, and having Rust encroach on their area.
> "People have even been talking about the Rust integration being a failure … We've been doing this for a couple of years now so it's way too early to even say that, but I also think that even if it were to become a failure – and I don't think it will – that's how you learn," he said.
> "So I see the whole Rust thing as positive, even if the arguments are not necessarily always [so]."…
> With impressive diplomacy, considering his outbursts of years past, Torvalds went on, "There's a lot of people who are used to the C model, and they don't necessarily like the differences... and that's ok.
But yeah, I still don't think it's all that inaccurate: He may not have wanted it to fail, and still not think it's a technical failure... But socially? Still seems possible he'd be starting to think that while the Rust language per se is a technical success, all the drama surrounding the integration of it into Linux means that that is turning out to be a social failure.
(Or maybe I'm just projecting because that is what it looks like to me.)
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).
That's my understanding as well, as soon as the node exclusivity dropped they were ballpark equal.
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.
> 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.
It's more nuanced than that. Apple effectively pulled a "Sony A7-III" move. Released something one generation ahead before everybody else, and disrupted everyone.
Sony called "A7-III" entry level mirrorless, but it had much more features even when compared to the higher-end SLRs of the era, and effectively pulled every other camera on the market one level down.
I don't think even they thought they'd keep that gap forever. I personally didn't think it either, but when it was released, it was leaps and bounds ahead, and forced other manufacturers to do the same to stay relevant.
They pulled everyone upwards, and now they continue their move. If not this, they also showed that computers can be miniaturized much more. Intel N100 and RaspberryPi/OrangePi 5 provides so much performance for daily tasks, so unimaginable things at that size are considered normal now.
I like the Sony story, but I don't think Apple did "pull everyone along" like that, they had an exclusivity deal with TSMC to be first on a good manufacturing node improvement. They took their high-quality, high-performance iPhone SoC, gave it more juice and a bit better thermals.
It's just another "Apple integrating well" story.
Their SoC is huge compared to competitors because Apple doesn't have to make a profit selling a SoC, they profit selling a device + services so they can splurge on the SoC, splurging on the SoC plus being one node ahead is just "being good", the team implementing Rosetta are the real wizards doing "revolutionary cool shit" if anything
> they had an exclusivity deal with TSMC to be first on a good manufacturing node improvement.
...plus, they have a whole CPU/GPU design company as a department inside Apple.
Not dissimilar to Sony:
Sony Imaging (camera division) designed a new sensor with the new capabilities of Sony Semiconductor (fab), and used their exclusivity to launch a new camera built on top of that new sensor. Plus, we shall not forget that Sony is an audiovisual integration powerhouse. They one of the very few companies which can design their DSPs, accompanying algorithms, software on top of it, and integrate to a single product they manufacture themselves. They're on par with Apple's integration chops, if not better (Sony can also horizontally integrate from Venice II to Bravia or Mics to Hi-Fi systems, incl. everything in between).
The gap also didn't survive in Sony's case (and that's good). Nikon and Fuji uses Sony's sensor fabs to use their capabilities and co-design sensors with the fab side.
Canon had to launch R series, upscale their sensor manufacturing chops. Just because Sony "integrated well" when looked from your perspective.
Sony is also not selling you the sensor. It's selling you the integrated package. From sensor to color accuracy to connectivity to reliability and service. A7-III has an integrated WiFi and FTP client to transfer photos. A9 adds an Ethernet jack for faster transfers. Again, integration within and between ecosystems.
>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.
Compared to the incremental changes we've seen the previous 10 years before it arrived on AMD/Intel space, it was revolutionary.
Was Intel switching from the Pentium 4 to the Core architecture considered revolutionary at the time? Was AMD's bulldozer architecture? I don't recall.
We must have different definitions of the word "revolutionary". They put a high-end mobile chip in a laptop and it came out good, what's revolutionary? The UMA architecture has advantages but hardly revolutionary.
The jump in performance, efficiency, battery time was not incremental or "evolutionary". Such jumps we call evolutionary.
What they did doesn't matter. Even if they merely took an intel laptop chip and stuck a chewing gum on it, the result was evolutionary.
So much so, that it put a fire under Intel's ass, and mobilized the whole industry to compete. For years after it came out the goal was to copy it and beat it.
What did you expect to call "revolutionary"? Some novel architecture that uses ternary logic? Quantum chips?
And some of these Lenovos are relatively upgradable too. I'm using a ThinkPad I bought refurbished (with a 2 year warranty) and upgraded myself to 40 GB of RAM and 1TB of SSD (there's another slot too if I need it). It cost me $350 including the part upgrades.
Prices seem to have risen a bit since I bought mine. Here's a similar model with a Ryzen 5 7530U for $355: https://www.ebay.com/itm/156626070024 It is certified refurbished and has a two year warranty. It has a SODIMM slot and supports dual SSDs, although not the full size M.2.
It's not just that "people are hard" - it was clear that this will end up this way the moment marcan started ranting on social media about having to send kernel patches via e-mails. Collaborating on software development is a social activity and stuff like convincing maintainers to trust you and your approach is just as important part of it (if not more important) as writing code. Not realizing that is a sure road to burnout (and yes, I'm just as guilty of that myself).
> Not realizing that is a sure road to burnout (and yes, I'm just as guilty of that myself).
Humans are shaped by experience. This is both a boon and a curse. I have been also been on the hot end of the stick and burned myself down, sometimes rightly, sometimes wrongly. Understanding that I don't want to go through this anymore was the point I started to change.
> Collaborating on software development is a social activity and stuff like convincing maintainers to trust you and your approach is just as important part of it (if not more important) as writing code.
Writing the code is at most 5% of software development IME. This is what I always say to people I work with. I absolutely love writing code, but there are so many and more important activities around that, I can't just ignore them and churn out code.
> 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 projects and in very well run projects. And in immature projects - where bugs are cheap and there’s no code review. In places like that, I’m programming more like 60% of the time. I love that.
But Linux will never be like that ever again. Each line of committed code matters too much, to too many people. Is has to be hard to commit bad code to Linux. And that means you’ve gotta do a lot of talking to justify your code.
I did some work at the IETF a few years ago. It’s just the same there - specs that seem right on day 1 take years to become standards. Look at http2. But then, when that work is done, we have a standard.
As the old saying goes, if you want to go fast, go alone. If you want to go far, go together. Personally I like going fast. But I respect the hell out of people who work on projects like Linux and chrome. They let us go far.
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.
Yeah. I think the whole drama around rust on Linux is a great example of this. If Linus came forward and clearly supported (or clearly rejected) rust on Linux, it would have saved a lot of people months of stress and heartache.
It really depends what kind of code and for which usage.
People might also live their hobby dev experience better if they were really coding for themselves without any expectation except pushing the code to a repo. As a hobby dev, you don't have to make package, you don't have to have an issue tracker, you don't have to accept external contributions, you don't have to support your users if you aren't willing to have this on your shoulder. You don't even need a public git repo, you could just put a release tarball when release is ready on your personal website.
This works perfectly fine as long as you're happy with being approximately the only user of your code. With some of my projects I do just that, but it gets very different once you add users to the mix.
5%? Sure there is a lot of activity around software. But out of week of 40 hours I most certainly code more than at most 2 hours. If this is your workplace I think it's dysfunctional.
You are implying that if you can communicate but have nothing backing it up that's worth 95%? If anything code can still be taken as is and understood by someone else. So to me it's always most important to be able to produce anything before being able to communicate.
In a sense, yes. I'm contributing to a small but crucial part of a big project, as a coordinator of a four person team. The dynamics of the project form the team as "band of equals", in other words, everybody has approximately the same capabilities, and roles are divided organically, and I ended up as the "project manager" for that group somehow.
Even before we started coding, there was an RFC written by us. We have talked about it, discussed it, ironed it out with the chief architects of the project. When everything made sense we started implementing it. Total coding hours is irrelevant, but it's small when compared all the planning and it's almost finished now.
The code needs to tap and fit into a specific place in the pipeline. Finding and communicating this place was crucial. The code is not. Because you can write the most sophisticated code in the most elegant way, but if you don't design and implement it to fit to the correct place, that code is toast, and the effort is a waste.
So yes, code might be the most enjoyable (and sometimes voluminous) part, but it's 5% of the job, by weight, at most.
Once your proof of concept gains traction more time is spent in meetings with other teams responsible for the systems you'll be interacting with - making sure you do it "right" rather than scrappy. Once your initial release starts getting popular you spend more time looking at metrics and talking to operations folks to make scaling easier and not waste resources. Once your product starts having customers who depend on it, you spend a lot of time working with product to figure out features that make sense, advise on time estimates, mentor new team members, and advise teams who use your product/services as a dependency.
These are all engineering tasks, and the longer you spend on a team/in a company, the more likely it is you provide more value by doing this than by slinging code. You become a repository of institutional knowledge to dispense.
Think about it the other way around: How much code is written and never used? How much code is written and would be better if it were never used? How much code is used only to then notice, that it doesn't solve the business problem that it was intended to solve? How much code is run and it's never noticed that it doesn't solve any business problem?
All the while: You are correct, being able to produce anything that solves a problem is much more valuable than being able to talk about it. But in order to unlock the value (beyond solving your own problem) absolutely requires communication
It's more like writing the code is just the first step on a long road. You won't go anywhere at all if you don't take it, but if that's the only thing you do, all you did is the first step.
I have written plenty of code that's stuck on this first step in my life, including some that went to the very same LKML we're talking about here right now. Some of those things have already been independently written again by other people who actually managed to go further than that.
Perhaps "useless" was the wrong word the GP used. "valued" may be better.
It's fairly common for very useful/valuable code to be discarded because the engineer (or his management) failed to articulate that value to senior leaders as well as someone else who had inferior code.
> it was clear that this will end up this way the moment marcan started ranting on social media about having to send kernel patches via e-mails. Collaborating on software development is a social activity and stuff like convincing maintainers to trust you and your approach is just as important part of it (if not more important) as writing code.
Yeah but FFS using email for patches when there are so much better ways of doing development with git? The Linux Foundation could selfhost a fucking GitLab instance and even in the event of GitLab going down the route of enshittification or closed-source they could reasonably take over the maintenance of a fork.
I get that the Linux folks want to stay on email to gatekeep themselves from, let's be clear, utter morons who spam on any Github PR/issue they can find. But at the same time it makes finding new people to replace those who will literally die out in the next decade or two so much harder.
It's an interesting phenomenon where people keep coming out of the woodwork and criticize the most successful software development project inhistory for doing it wrong.
They're not micro kernel! They're not TDD! They're not C++! They're not CVS! Not SVN! Not SCRUM! Not Gitlab!
Yet the project marches on, with a nebulous vision of doing a really useful kernel for everyone. Had they latched on any of the armchain expert criticism of how they're doing it wrong all these years we wouldn't be here.
> Yet the project marches on, with a nebulous vision of doing a really useful kernel for everyone.
The question is - how long will it march on? The lack of new developers for Linux has been a consistent topic for years now. Linus himself isn't getting younger, and the same goes for Greg KH, Ted Ts'o and other influential leads.
When the status quo scares off too many potential newcomers, eventually the project will either wither or too inexperienced people drive the project against a wall.
The people in charge decided on their preferred ways of communication. You may believe that there are better ways out there, and I may even agree with you, but ultimately it's completely irrelevant. People responsible decided that this is what works for them and, to be honest, they don't even owe you an explanation. You're being asked to collaborate in this specific way and if you're unable to do it, it's on you. If you want to change it, work your way to become a person who decides on this stuff in the project, or convince the people already responsible. Notice how neither of those are technical tasks and that they don't depend on technical superiority of your proposed methods either.
> Yeah but FFS using email for patches when there are so much better ways of doing development with git?
You are missing one point, namely that email is probably the only communication medium that's truly decentralized. I mean, on most email providers you can export your mailboxes and go to someone else. You can have a variety of email clients and ways to back up your mailboxes. No git clone, no specific mailbox or server is in any way special, I think Linus emphasized recently that they made efforts to ensure kernel.org itself is not special in any way.
Yes, I find Github's or Gitlab's UI, even with all enshittification by Microsoft and whatnot, better for doing code reviews than sight-reading patches in emails. And yet I cannot unsee a potential danger that choosing a service — any service! — to host kernel development would make it The Service, and make any migration way harder to do than what you have with email. Knowing life, I'd say pretty confidently that an outcome would be that there would be both mailing lists and The Service, both mandatory, with both sides grumbling about undue burdens.
Have you ever been in a project which had to migrate from, say, Atlassian's stack to Github, or from Github to Gitlab, or vice versa? Heck, from SourceForge + CVS/SVN to Github or similar? Those were usually grand endeavors for projects of medium size and up. Migrate all users, all issues, all PRs, all labels, test it all, and you still have to write code while it all is happening. Lots of back-and-forth about preserving some information which resists migration and deciding whether to just let it burn or spend time massaging it into a way the new system will accept it. Burnout pretty much guaranteed, even if everyone is cooperating and there is necessity.
But you could probably build tools on top of email to make your work more pleasant. The whippersnappers who like newer ways might like to run them.
I personally don't think GitHub's PR model is superior to e-mail based patch management for two reasons. First, e-mail needs no additional middleware at git level to process (I can get my mails and directly start working on my machine), plus e-mail is at least one of Git's native patch management mechanisms.
This is not about spam, server management or GitLab/Gitea/whatever issue. This is catering to most diverse work methods, and removing bottlenecks and failure points from the pipeline. GitLab is down, everybody is blocked. Your mail provider is failing? It'll be up in 5 minutes tops, or your disk is full probably, go handle it yourself.
So Occam's razor outlaws all the complex explanations for mail based patch management. The answer is concise in my head:
> Mailing list is a great archive, it's infinitely simpler and way more robust than a single server, and keeps things neatly decentralized, and as designed.
This is a wind we can't control, I for one, am not looking and kernel devs and say "What a bunch of laggard luddites. They still use e-mail for patch management". On the contrary, I applaud them for making this run for this many years, this smoothly. Also, is it something different what I'm used to? Great! I'll learn something new. It's always good to learn something new.
Because, at the end of the day, all complex systems evolve from much simpler ones, over time. The opposite is impossible.
> Your mail provider is failing? It'll be up in 5 minutes tops, or your disk is full probably, go handle it yourself.
Well until you deal with email deliverability issues, which are staggeringly widespread and random. Email were great to send quick patches between friends like you'd exchange a USB key for a group project. For a project the size of Linux? It doesn't scale at all. There is a reason why Google, Meta, Red Hat, and [insert any tech company here] doesn't collaborate by sending patches via email.
the problem with mail-based patch management is that it doesn't scale well, management wise... when you have hundreds of patches and multiple reviewers who can review them, Github/Gitlab environments make it easier to prioritize the patches, assign who will do the review, filter the patches based on tags, and keep track of what wasn't reviewed yet...,
mail-based patch management is fine for smaller projects, but Linux kernel is too big by now.. it sure is amazing how they seem to make it work despite their scale, but it's kinda obvious by now, that some patches can go unnoticed, unprioritized, unassigned, ...
and open source is all about getting as many developers as possible to contribute to the development. if I contribute something and wait months to get it reviewed, it will deter me from contributing anything more, and I don't care what's the reason behind it. the same goes for if I contribute something and receive an argument between two or more reviewers whether it's the right direction or not and there's no argumentative answer from a supervisor of the project and this situation goes on for months...
Email is just the protocol. What you're really saying is that http-based protocols make more powerful tools possible.
It's not really enough to state your case. You have to do the work.
On the surface, the kernel developers are productive enough. Feel free to do shadow work for a maintainer and keep your patch stack in Gitlab. It it can be shown the be more effective, lots of maintainers are going to be interested. It's not like they all work the same way!
They just have a least common denominator which is store-and-forward patch transport in standard git email format.
Everyone still has at least the base branch they're working on and their working branch on their machine, that's the beauty of working with Git. Even if someone decides to pull a ragequit and perma-wipe the server, when all the developers push their branches, the work is restored. And issues can be backed up.
> Also, is it something different what I'm used to? Great! I'll learn something new.
The thing is, it's harder and more difficult in a time that better solutions exist. Routinely, kernel developers complain about being overworked and onboarding of new developers to be lacking... one part of the cause certainly is that the Linux kernel is a massive piece of technology, and another one that the social conventions of the Linux kernel are very difficult, but the tooling is also very important - Ballmer had a point with "developers developers developers".
People work with highly modern tools in their day jobs, and then they see the state of Linux kernel tooling, and they say "WTF I'm not putting up with that if I'm not getting paid for it".
Or to use a better comparison... everyone is driving on the highway in the same speed, but one car decides to slow down, so everyone else overtakes it. The perpetual difficulties of many open source projects to accomodate changing times and trends - partially because a lot of small FOSS is written by people for their individual usage! - are IMHO one of the reasons why there is so much chaos in the FOSS world and many private users rather go for the commercial option.
You are missing the entire point. When you interact with a group of people who already have a culture and a set of practices/traditions, you have to play by their rules, build up credibility with that community... and then maybe, down the road, you can nudge them a little to make changes. But you have to have credibility first, have established that you understand what they do and understand why their preferences are the way they are.
If you approach it from the viewpoint that you have the solution and they are Luddites, you will influence no one and have no effect.
Marcan's career as a developer includes lots of development on hostile systems where he's jailbreaking various consoles to allow homebrew.
Asahi Linux is similar, given how hostile and undocumented Apple Silicon is, but it has a great amount of expectations of feature completeness and additional bureaucracy for code changes that really destroys the free-wheeling hacker spirit.
I understand. While I'm not as prolific as him, I've grown with systems which retrocomputing fans meticulously restore and use, so I had to do tons of free-wheeling peeking and poking.
What I found is being able have this "afterburner mode" alongside "advanced communications" capabilities gives the real edge in real life. So, this is why I wish he can build his soft skills.
These skills occupy different slots. You don't have to sacrifice one for the other.
Probably a few reasons. For Darwin, there are a few small projects but I think they are all functionally dead. The benefit with Linux, or even the BSDs here is, sure you gotta port to the hardware, but you should get a good set of user land stuff running for 'free' after that. Lots of programs just need to be compiled to target arm64 and they will at the very minimum function a little bit. Then you can have package maintainers help improve that. I don't think any of the open source Darwin based projects got far enough to build anything in user land. So you'd probably just get the Darwin code from Apple, figure out how to build it and then build everything else on top of it.
The BSDs. You can fork a BSD. Maybe he could try to mainline into the BSD, but would probably face a similar battle with the BSDs. Right, one again, the benefit mainlining into linux, and there is some (maybe limited) support to include Rust, is you can narrow your scope. You don't need to worry as much about some things because they will just sorta work, I am thinking like upper layers of the kernel. You have a CPU scheduler and some subsystems that, may not be as optimized for the hardware, but at least it is something and you can focus on other things before coming around to the CPU scheduler. You can fork a BSD, but most would probably consider it a hard fork. I also don't think any of the BSDs have developers who are that interested in brining in Rust. Some people have mentioned it, but as far as I know, nothing is in the works to mainline any kind of Rust support in the BSD kernels. So he would probably meet similar resistance if he tried to work with FreeBSD. OpenBSD isn't really open to Rust at all.
Why insist on developing in Rust? I mean, I see how it's much cooler and actually better than something like C, but people are hugely underestimating how difficult it is to change the established language of a 3 decade old project.
If Rust is the point you get up from the bed in the morning, why don't you focus on Redox and make it the new Linux? Redox today is much more than Linux was in 1991 so it's not like you would be starting from scratch.
You're probably not as good as Linus in, well, anything related to this field really. The only way to find out whether you actually are is to do the work. Note that also he spent a lot of time whining to people who were perceived as the powerful in the field. But in addition to whining he went and did the work and proved those people wrong.
Mind you, I'm a PHP developer by day, so this Rust-vs-C debate and memory management stuff is not something I've had experience with personally, but the "Rust is magical" section towards the bottom seems like a good summary of why the developer chose to use Rust.
Oh no, I totally agree. I am just saying from the perspective of the Asahi Linux project and wanting to use as much Rust as they can, that is what they are facing and the associated trade offs.
I personally fall a little more on the side of the Linux kernel C devs. Inter-oping languages and such does bring in a lot of complications. And the burden is on the Rust devs to prove it out over the long haul. And yes, that is an uphill battle, and it isn't the first time. Tons of organizations go through these pains. Being someone who works in a .NET shop, transitioning from .NET Framework to .NET core slowly is an uphill battle. And that's technically not even a language change!
But I do agree, Redox would probably less friction and a better route if you want to get into OS dev on an already existing project and be able to go "balls to the walls" with Rust. But you also run into, Redox just has a lot less of everything. That is just because it's a small project.
> Asahi Linux is similar, given how hostile and undocumented Apple Silicon is, […]
«Undocumented» – yes, but «hostile» is an emotionally charged term that elicits a strong negative reaction; more significantly, though, it constitutes a flagrant misrepresentation of the veritable truth as stipulated within the resignation letter itself:
When Apple released the M1, I realized that making it run Linux was my dream project. The technical challenges were the same as my console homebrew projects of the past (in fact, much bigger), but this time, the platform was already open - there was no need for a jailbreak, and no drama and entitled users who want to pirate software to worry about.
Which is consistent with marcan's multiple previous blog posts and comments on here. Porting Linux (as well as NetBSD, OpenBSD) onto Apple Silicon has been no different from porting Linux/*BSD onto SPARC, MIPS, HP-PA and other platforms.
Also, if you had a chance to reverse-engineer a closed source system, you would have known that «hostile» has a very specific meaning in such a context as it refers to a system that has been designed to resist the reverse-engineering attempts. No such resistance has been observed on the Apple Silion computing contraptions.
> No such resistance has been observed on the Apple Silion computing contraptions.
I think they even left a "direct boot from image" (or something similar) mode as a small door to allow Asahi Linux development, if not to accelerate a little bit without affecting their own roadmap. Even Hector tweeted about it himself!
I also think calling it hostile is a little far. I recall Hector making comments of, "yea, even though is not greatly documented, it does things quiet a few things the way I would expect" and I believe even applauded Apple on a few thing. I wanna recall it was specifically around the booting.
Yeah, I want to give them accolades for the great work they did.
I just wanted to also add that users will be users. Once its out, there will be endless posts about "why X" and "why not Y". No matter what you do, lots of people are going to be displeased. Its just the way things go. I hope he will want to pick it up again after some time.
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 you do your users become your opponent. None of those requests are entitled, the author has clearly already reached a point where they are antagonistic towards requests.
I always tell this story about working with sales at a job where I worked in tech support. Sales would call me up and ask why I hadn't talked to their client about their very important ticket.
I would tell them:
"I have 5 P1 tickets, 8 P2 tickets, and dozens of P3 tickets. Your ticket is a P3 ticket."
They would ask that I change it to a P1. I would. Then they would call me an hour later asking me about the ticket and I would tell them:
That's when they understand that they have to start fighting their peers and talking with the big boss to get their P1 ticket moved in front of the other P1 tickets.
Yup, but it gets them out of my hair, and they understand the support guy isn't in a position to wave a magic wand for them. If sales guy wins his fight with the folks in charge and I get time / resources to work on his thing, fine with me.
At Symbian defects were classified from P1-P4, with the inevitable shit-fights about adding magic runes to the title so everyone knows that your P1 is more important than theirs.
The day came when, after prolonged hand wringing and with stern observations about great power and great responsibility, the priority could be set to P0. But like any bunch of junkies we came off this new high all too quickly and the P-1 classification arrived, the showstopper of showstoppers.
In hindsight what I most regret is that we stuck with an integer field; we were denied the expressive power of fractionally critical issues.
So? If they succeed (big if), then that ticket is your new priority. Maybe even for good reason, maybe not. But usually you don’t care that much which one you work on first, do you?
Good for them for at least understanding at that point. The typical response is to say "I get that, I really do—can you move this one to the front of the line for me?" and then maybe a vague threat like "I can talk to your manager if it would help".
In my experience, when it's other people deciding the priority of your tasks (usually your boss), the distribution is 150 P1 tickets, 3 P2 tickets and 1 P3.
This is when the underrated skill of saying NO pays off massive dividends. One long-term client once told me the thing he appreciated the most, compared to most other consultants, was that I wasn't afraid of pushing back on his requests and saying no (within reason). Probably the most valuable feedback I have ever received.
When I worked support, they didn't even have a priority system (it was C2B, so there weren't necessarily enterprise customers. That did come later, with LiveChat and all it's joys). Instead, we had a 24hr expected turnaround and harder tickets would naturally filter to the top. Tickets that had reached near that point had a higher weight, which went towards your metrics/"leaderboard status". To dissuade gaming of the system, ongoing replies were assigned to an agent (you wouldn't give a half-assed reply and then hope for someone else to clean it up) and were exempted from the bonuses (so were one standard ["fresh"] ticket each).
Obviously, there was some oversight from managers, but overall it worked pretty well.
Yes, this is pretty normal; in paid products I even find it's less aggressive than in free things. But I have a hard and frozen shell around my vital organs to just politely and friendly point to the place in queue and where to donate to speed it up. For $10k I will build your cpu temp proc, if that's not an option then it's in pos #17463 of my task list.
Yes. I was developing some open source stuff before venturing to for-profit closed Source Software, and I was surprised that the paying customers were on average much nicer than those who got their stuff for free!
When you pay for something, you’ve already demonstrated that you value whatever it is (a product, a service, etc). Free stuff tends to attract people who don’t value the thing.
Or the more darwinistic view: anything you pay access for, you can get gated off from.
Its quite difficult to ban someone from a public park, especially when they can just put on a new hat.
Its really easy to ban someone from a private park. Even if they do put on a new hat, when they get belligerent again you just revoke the renewal of their access pass.
There's also a level of professionalism depending on the product. When I'm responsible for an MSP team I'm very polite to them and always try to get them good, detailed, high-quality information when I'm telling them about problems with their work product, because I want them to do good work quickly and that's the best way to do that.
Yea, I'm not sure it's open-source vs other software. It's public vs. professional insiders.
My company's bug tracker is mostly internally-filed bugs, but accepts bugs from the public. The difference in tone and attitude is night and day. The public-filed bugs can be wild, varying across: Rude, entitled, arrogant, demanding, incoherent, insulting, irrelevant, impatient... They are also the worst when it comes to actually including enough information to investigate. Frequently filed without logs, without reproduction steps, sometimes without even saying what the filer thinks is wrong. We get bugs with titles "It doesn't work" and with a text description that reads like a fever dream from someone very unwell.
We do have strong personalities among employees, but bug reports tend to be professionally and competently written, contain enough information to debug, and always, always leave out insults and personal attacks. The general public (at least many of the ones technical enough to file bug reports) does not seem to have the emotional regulation required to communicate professionally and respectfully.
> Frequently filed without logs, without reproduction steps, sometimes without even saying what the filer thinks is wrong.
In projects where this is a problem, I've made an issue template that clearly requests all the stuff I think I'll need. There's a big note at the top of the template that says it's not optional and that if it isn't filled out fully, I'll close the issue without comment.
And then I do that, every time. Sometimes they fill it out and reopen, sometimes they don't. Either way, I don't end up wasting time trying to help people who don't respect my time.
I tell my friends all the time: You want your product to be accessible? Sell cheap, but not too cheap.
Fair deals attract people with some money, but the almost-free only attract people who are forever broke, who live their life feeling entitled to everything being handed over to them.
> were on average much nicer than those who got their stuff for free!
this is always true with, at least a great many, people. it's related to choosey-beggar syndrome. it's a bug/glitch/feature in human psychology.
if you ever have the chance to be a property manager, never ever let someone move in a week early or pay a week later for free. never let your rent get drastically below market. when people aren't paying for something, it's incredibly common behavior to stop respecting it. it's like a switch flips and suddenly they are doing you the favor.
that's why in times past, offering or taking "charity" was considered impolite. but making a small excuse might be ok. say someone needs to stay an extra week after their lease was over, but was strapped for cash. instead of saying "sure you can stay one more week", say "well, you'd really be doing me a small favor staying in the place to watch for the extra week since it's empty anyway. how about i discount the rent by 50% for that week and amend the lease to take care of it."
I agree that this is needed. It doesn't stop the person requesting the feature from asking for a meeting to explain why and just whining that they need it the whole time and saying they shouldn't have pay anything to get it addressed right now.
Having in the person taking these meetings for a software vendor, it can get really toxic quickly and I never had more than 1 meeting a quarter with really toxic people and they were at least paying for the product and maintenance so hearing them out was part of the job. It unfortunate to get to the point where you view customer requests as antagonistic, but I can see how it happens. Some people really feel entitled, and some have a job to do and limited resources or control to do it in.
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 shit" (both real quotes), I had to be able to shrug and carry on with whatever my development priorities were anyway.
That said, I sympathize very much with Marcan on this project: getting the basic infrastructure for Linux operational on new hardware inflames passions much more than a niche project like a DAW.
Thank you for Ardour btw, great piece of software although I still use Ableton from time to time, Ardour is taking over more and more parts for me :)
I've read your comments here (and elsewhere) for a long time, and I'm sure you'd have some great ideas or at least opinions about this, which is pretty relevant to what you just wrote: https://news.ycombinator.com/item?id=43037537
I think my experience actually making a living from a FLOSS project changes things enough that it is not that relevant to people doing it "for the love it" or as a side-project.
It's much easier to shrug off strong comments when the people who do support you are making it possible for you (and one other) to lead a pretty comfortable middle class life.
God how I hate these arguments. You have this especially with Gimp. "But my beloved multibillion company worth product can do X sooo much better and easier. Also it has 16bit bla bla bla." You don't say?!?!?!?
Any tips how to get a thicker skin, or it grows on you over the years ?
Also, thanks for Ardour. I am a hobby cellist and record sometimes myself using Ardour and to cut down samples for an app I am working on. I tried doing that with my iPhone which worked like crap. Yup!
Open source is about liberating computing not about liberating users.
If you're supporting end users you need to be collecting money from them.
The mechanics of this system are entirely upside down. The corporations have bought into open source to regain control of computing and passionate developers are mired in the swamp of dumb user requests.
I think entitlement like that is stupid and bad for open source (and everything). However, in the next paragraph the author gets into criticising the opposite position, that asahi linux was not ready for everyday use. The entitled requests came from users that thought of asahi linux as exactly covering an everyday use case, a linux distro they should be able to use to carry on their tasks. This I find contradictory. While some entitled users always exist, you can either admit that asahi is not a daily driver for people who want to use most of basic features of a laptop, or admit that the requests make sense. You cannot both claim that asahi is fine to be used, and complain that users ask for being able to connect an external monitor on a M1 macbook air. I am not sure what is wrong with the claim that asahi linux is an experimental (and no less amazing) project that people lacks certain (widely considered basic when things come to this) functionality, or that the functionality of it is restricted to these use cases that may include using it as a headless server but exclude some common other ones. I am not sure how this would matter, but setting user expectations to a level that matched the state of development may have helped to limit such requests.
I say that also because I have been gotten quite a few responses from people that I should use asahi, while looking at what it supports it definitely would not make sense for me, and you cannot just present it to a macos alternative right now.
Thing is it will never get to be a daily driver if people don't use it and shake out the bugs.
25 years ago (huh, long time), when Windows ME pissed me off for good, linux wasn't exactly known for being a daily driver but I gave it a try and, unsurprisingly, it did become reliable over the years. Other than Gnome's propensity to make stupid changes to default settings I can't remember the last time I had to even think about messing with the underlying system and other than a simple google search on the linux compatibility of hardware before I buy I just don't think about it. Actually, I take that back, when I first got my current laptop I was messing around to get the AMD mesa drivers (or whatever) working because I wanted to mess around with this fancy GPGPU thing.
Personally, if I were to buy a macbook it would be for the OS and not dodgy linux support because I've walked that road before. If the Christmas sales were just a tiny bit better though...
I am talking about lack of pretty standard features, not bugs. Having more users would not help there. And in general, you dont need a huge influx of users, and you definitely you dont get as much help from users who are not going to put at least some effort in the feedback they give. You want users that are conscious enough about what they are using to give useful feedback and/or support with donations. I am pretty sure that some people still are attracted to running an experimental version of linux.
Imo modern linux experience is much better than the situation you describe, at least as long as you use certain type of hardware. In the past it was definitely harder. But wrt asahi, I want the "luxury" of using an external monitor with my 13" macbook air, and sadly, while in the past x86 machines I put linux I would put some effort and get AMD mesa drivers to work, I cannot do that here. I respect the effort put in the asahi project, but calling it suitable for a daily driver is misleading, unless you specify exactly what sort of daily driver you mean. Stuff like using an external monitor is pretty basic in my book of daily usage.
I work for a company that is open source and has a large community. I blows my mind (and often aggravates me) how rude some people can be.
For some reason people feel that it is appropriate to throw barbs in their issue reports. Please to everyone out there, if you find an issue and want to report it (hurray open source!) please be kind with your words. There are real people on the other side of the issue.
Always remember, you catch more flies with honey than vinegar.
> I blows my mind (and often aggravates me) how rude some people can be.
That seems to be a general characteristic. I strive to be cheerful and helpful whenever I'm asking for something. I feel like (sadly) it sets me apart from the crowd and helps me to get what I'm asking for. And IAC, with so little effort on my part I may brighten someone else' day and that makes me happy.
Just last week I asked housekeeping at a hotel for an old style coffee pot since I had brought my own coffee and filters. I started with "Can I pester you a moment?" and the conversation went up from there. Housekeeping was extremely friendly and helpful. Later I guessed this might have been her way to disarm some of the typical hostile interchanges she's been the brunt of.
I always feel like I'm imposing, and I have to remind myself that there are people who are eager to hear what I have to say. I try to set up my issue reports with appropriate background, and I always volunteer to, for example, submit a PR for a documentation change if the resolution requires it. And I have had some of the most wonderful interactions with complete strangers who had an idea, built a tool for themselves, and found other people had the same need.
There's a broader topic of ... just be nice to people. It doesn't cost anything. It does reassure me that this universe has been struggling with this for decades upon decades--witness the Malvin and Jim scene in WarGames. "Remember when you told me to tell you when you were acting rudely and insensitively?"
I think I kind of get it. By the time someone actually gets to the point of filing an issue report, they are at the end of their rope. They have tried everything they can think of. They have googled and found no one else having the same problem, or fixes that don't work, or people saying "why would anyone need that feature". They feel like they're being gaslit, their time is being wasted, and that the developers are intentionally antagonizing them. And then the form to submit the issue has way too many fields and comes across as very adversarial.
That's certainly how I felt when trying to get my drawing tablet to work properly under Linux Mint, although in my case I skipped filing an issue and just gave up and went back to Windows.
It sounds like he really got invested too much into what people wrote.
> “Asahi is useless to me until I can use monitors over USB-C” “The battery life sucks compared to macOS”
These are not even requests. These are objective statements he can either take note of for prioritisation or ignore. I can also say Asahi is useless to me until usb-c monitors support, but that's just my situation - there's no bad faith or request here. Previously that was the same for WiFi support.
I wish there was some good model for maintainers of bigger projects to deal with this on a personal level. The bigger the project, the more people there will be with unmet requirements and that's just life. It literally can't be solved.
I had a similar thought. The tone of the messages was a little rough and they definitely could have used some better tact knowing that the project developers would see it, but ultimately those are just factual statements delivered with brutal bluntness.
Right exactly. They're not tactful, but they also weren't in bad faith. Marcan should have taken 5 minutes to realize that he's the boss, he's the one doing the work, nobody is entitled to anything in free software and that if people want a feature sooner they can either fund the project or kick rocks. Anyone who's been in open source for over 2, definitely 3 understands this.
> I miss having free time where I can relax and not worry about the features we haven’t shipped yet. I miss making music. I miss attending jam sessions. I miss going out for dinner with my friends and family and not having to worry about how much we haven’t upstreamed. I miss being able to sit down and play a game or watch a movie without feeling guilty.
This is the big problem really. He should have just turned down his work hours to a regular 40 a week, asked for more donations to pay more people and asked for more volunteer help. And honestly, probably therapy.
This is the same person that resigned as a kernel maintainer (focus on Apple/Arm unsurprisingly) about a week ago.
I don't know this person so this is completely baseless speculation but I assume they are "going through it" in some way and experiencing significant burnout, which based on my own experience in the past has a way of (negatively) amplifying all sorts of interactions that are related to the source of your burnout.
Basically, making linux work on Apple hardware is a pretty hard task, including a shitload of reverse engineering.
When a user decides to try it, and finds a lot of features missing, they are completely unaware of the work required to get it into that state, and just think they should have the readily available features.
> This sounds so rough. I can't imagine pouring your heart out into this labor of love and continue to have to face something like this.
Or: he shouldn't steal people's time with false advertising :shrug:
Also if he wants to create an operating system, then these aren't even requests, but
bug reports. So the users ate his false advertising, spent time to try out his system, then spent some more time to file bug reports, and then he calls them "entitled users".
I can't imagine then what's his problem. I don't get offended by people that can't even read. I don't normally call them people let alone entitled :\ Set up a bot that links them the device support page, and problem solved? I don't get it
> 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 new major contributor. The second is optional, as long as you are happy just doing your thing, but then the former probably won't become a problem for you.
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.
I'd argue I'm not putting any requirement on the developer, I'd argue I'm making a statement of fact. Namely
> 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.
Open source attracts some of the very worst users. Often people pretending to be trying to help by "suggesting improvements", but just as often entitled people who want to work for free. I don't think policies will change that. It's just something you have to accept when you provide something useful to lots of people for free. Even if you use moderated environments for user feedback (adding the burden of constantly banning people), people will find your email address and complain to you directly. See also: jwz/xscreensaver/Debian drama. Seeing how people treat open source developers makes me hesitant to upload any code I write to a public repository.
I'd expect the worst part for an Asahi project contributor to be the active sabotage some angry Linux kernel devs are trying to pull because they don't like Rust. Users being unreasonable is one thing, but your fellow maintainers are supposed to be allies at least.
I hope Marcan can find a new project to take on that doesn't involve all of this mess.
> Open source attracts some of the very worst users
I don't think it's even just that, it seems to be something about the price.
I work on a piece of closed-source free software, and we consistently get support requests from unbelievably entitled assholes. The worst of them are the ones that have some technical knowledge; they will not only demand things be fixed or implemented, they make completely erroneous statements about how easy it would be to fix/implement with the conviction that they are 100% correct, with a level of arrogance that is impossible to fathom how they could have written their email with a straight face.
The support requests we receive for a paid offering from the same company are 99% of time much more pleasant people (of course there are the, "I PAID FOR THIS YOU MUST FIX IT!!!1!" on occasions, but they're a definite minority).
I think I've said this before, but 'free' seems to attract the worst of humanity.
When I want to give something away, I list it for some nominal fee like $10, then just tell them to keep it. Because when I used to list things for free, I got the dredges of society bothering me. Asking for delivery, asking me to hold it for 3 months til they can find a truck, cussing at me for saying no to both of these, cussing me because I sold it to someone else already, telling me long sob stories to guilt me. I've never had any of that happen when asking for money(except one guy wanted me to deliver it for $20, which was a fair-ish offer).
I wonder if that same 'pay but you'll get it back under the table' model could work for software? At least until the word got out, I guess.
> I hope Marcan can find a new project to take on that doesn't involve all of this mess.
The only way to do that is to never collaborate with anyone else. I hope he'll be someday able to process what happened, why and reach appropriate conclusions. Software development is a social activity, especially with relatively high-visibility projects like Asahi, and it comes with just as usual burden of social troubles as any other kind of social activity.
> Software development is a social activity, especially with relatively high-visibility projects like Asahi, and it comes with just as usual burden of social troubles as any other kind of social activity.
Yes.
> The only way to do that is to never collaborate with anyone else.
Not necessarily. You can also treat project politics and social skills like any other technical skills that you need on your team like network engineering or database optimization.
If you can find trusted collaborators with those social and political skills, you can make a lot of things happen without necessarily being very good at it yourself.
Team building has a lot of parallels with building a full stack technology. Or building a sports team.
It's true, but what I was responding to was "a project to take on that doesn't involve all of this mess".
The real answer is to either learn these skills or, as you suggest, delegate them. Hoping to find something that doesn't involve "all this mess" at all will be fruitless.
That's what I get with my software projects. People tell me that it sucks and I suck at code and other projects have it better, and don't forget to waste months of your time rewriting to Rust, and don't you dare to use unsafe all over your code (see: actix drama)... sigh. But when asked to show their alternative they get silent. So as long as you keep being assertive this is fine. For everyone who comes and behaves like a drama queen you have to prove again and again that talk is cheap and code is how you get the job done. Or you simply ignore them.
In the early aughts, I spent a lot of time writing and maintaining Open Source software. I burned out on that because of rude users. I had one guy track me down offline and phone me at all hours to demand that I drop everything and fix a bug for him. When I pointed out that my day job came first because I have to pay bills, he went on an online screed accusing me of holding him hostage unless he paid for fixes and listing my cell number so people could "encourage me to be a better developer."
In those days, I was part of a core development team for a project with a fairly large community. A few bad users and a few bad development team members is all it takes to poison something like that.
Now I barely even contribute to Open Source projects even when I fix them for my own uses.
Depends on the project. I have found Pinephone users quite nice overall as a kernel developer.
Anyway, if your project involves convincing hundreds of maintainers to increase their cognitive/work load in order to include your fancy new foreign workflow breaking language into their project, you have to expect pushback.
> Open source attracts some of the very worst users.
This has not been my experience. Perhaps consider that the problem is not the users.
> the active sabotage some angry Linux kernel devs are trying to pull because they don't like Rust
On the other hand, users that demand you rewrite the project in their favorite language or otherwise accomodate their preferences over your own are pretty annoying.
> On the other hand, users that demand you rewrite the project in their favorite language or otherwise accomodate their preferences over your own are pretty annoying.
This whole post feels like typical burnout. Imagine porting something as complex as Linux to a platform who's creators actively do not want Linux ported to it. Of course you will burn our eventually. Not to dismiss his experiences, but I wonder if there is some deflection going on here - burnout was happening anyway but blaming others is a good smoke-screen.
>"I can’t even check my CPU temperature” (yes, I seriously got that one"
Actually if this distro is my primary / only one I would like to be able to check CPU, GPU, etc. temperature. It is important to know if cooling is adequate or requires cleaning / repair.
In any case Marcan would be way better off having thick skin. Users will always be assholes (well same is generally true about vendors).
why not tag it as pre-alpha, not suitable for daily use? Saying smoothest linux experience on one side and expecting people to not expect basic features of the hardware working...how does that work?
"Heavily under development and not ready for prime time use" should have been first line in readme and only reply to such feature request.
So it sounds like they bit more than they could chew.
I have been maintaining open source projects, and really: users of open source projects suck. They get your work for free, but it's not enough; they have to be assholes on top of that.
I would say it's more the case that the users who suck are both the loudest and also seem the loudest. If you get 10 people saying thank you and one person cussing you out, it might still ruin your day. And of course a lot of people just quietly use the thing and are happy with it, and you never hear from them at all.
People complain about things that they care about. People also don't usually have as much tact as we would like them to.
I think the best way to deal with this is to just confidently say what you are and are not ready to get done. The social dynamic will always be this way, so we may as well take whatever criticism is useful, leave the rest behind, and move on.
Never ever give away anything for free if you intend to support it is an evergreen advice.
Selling ads? Using it as a gateway to a commercial product? Selling support? Have some genius business plan that allows you to make money in the future? Fine, give it away no strings attached but expecting that users will be grateful is a mistake developers keep repeating. The free users are just as entitled, even more entitled as they don’t have a price tag for your efforts and don’t have a document specifying what are your obligations so they can assume scope of entitlements anyway they wish.
Since you gave it for free, you can’t refund an unhappy customers to make it go away. If it looks like a product, You will be stuck with people who think they did their part by using your products and you failed them. Some may make it a full time job to take a revenge on this injustice.
I’m not even sure that these users are at fault, you actually took something in exchange(like fame, street cred etc) and you are not delivering your part.
Paying users can be incredibly entitled, sometimes even more than people who don’t pay you a dime. The problem is the moment you accept a cent people expect you to do work for them, regardless of whether the money is actually “worth” how much effort needs to go into a feature. The open source projects I’ve worked on get donations but sometimes people will put up like $10 for their pet feature which takes a week to write. Like, thanks for your contribution, but this actually doesn’t affect my priorities at all.
from what I've seen of his grandstanding on the LKML suggesting to bully people on social media, I've lost all respect for the guy. He is a person in power considering all his social media clout, and this is how he uses it. I'm glad he realizes that it's time to sit back and reflect. And I don't mean that in a disrespectful way. He will be of much more use to the community, and more importantly himself after confronting his ego.
There are two types of VIP developers: those that stay in the shadows and do their work (think the Bram Moolenaars and Daniel Stenbergs) and those that seem to spend their entire time picking fights on social media and writing very emotionally charged blog posts that routinely reach the HN front page, because gossip and drama sells.
You gotta have super thick skin to be a maintainer of an opensource project or even be popular on the net these days. Folks are going to come for you for whatever reason, if you read too much into it you're going to have a bad time.
Apple users today are just Windows users with even more entitlement.
Wasn’t always like this, I think. Personally have seen the same with other projects and dealing with proprietary Apple APIs and their walled in garden is hard enough.
It's a pity that people like him and Zuckerberg have so much control over technology and the shape it will take in the coming years. As AI gets better, these aren't the people that should be at the helm or have this much power. At this point, I don't understand people who try to explain away his Nazi salutes. He keeps hitting a new low every day.
His control over technology is highly conditional and in a more rational world we would both enforce his regulated behaviours and deny him market controlling behaviours. The problem is that the bodies willing to take him on face opposition from the US tech sector investors at large because "being a bit nazi" isn't the only reason his kind of market dominance is concerning: Zuckerberg isn't that much better, remember his roots are "babe hawtness rating". Bezos like Musk is opposed to organised labour and all of the US Tech giants oppose being regulated to European norms.
when someone applies here for job, we actually give them all this information of how our system works and that at the end everyone gets fired anyway.
They see it as a challenge to outdoor everyone else and not many companies give new junior developers without any experience beyond hobby projects a chance.
I second this. I’m not a ruby dev and I watched the whole talk. It was excellent.
Goes on to show how for many applications overly priced platforms as a service aren’t really needed but incidental complexity masquerading as essential complexity is peddled as a way to make money.
> Rye is still a very experimental tool, but this guide is here to help you get started.
While I’m really excited about this project, I’m planning on waiting until this project is in a more mature stage. I am a big fan of everything else the Astral team has put out so I have high hopes for this.
I love the idea of it being culturally okay to walk out on any meeting that isn’t adding value in the middle of the meeting. If that was culturally acceptable in my role, I would go to a fourth of the meetings I currently attend.
> What is needed is skin in the game. Misdiagnosis should have financial penalties like speeding tickets
By this logic, would you say that software engineers should be financially liable for any bugs they cause along with people who misdiagnose those bugs in the process of root cause?
> By this logic, would you say that software engineers should be financially liable for any bugs they cause
Yes. Professional engineers are held ethically, professionally, and in some cases financially responsible for the work they sign off on. Personally, I agree with Dijkstra who pointed out in a speech in 1993 that the term "software engineer" is a hollow sham:
> And also the programming manager has found the euphemism with which to lend an air of respectability to what he does: “software engineering”...
> In the mean time, software engineering has become an almost empty term, as was nicely demonstrated by Data General who overnight promoted all its programmers to the exalted rank of “software engineer”! But for the managing community it was a godsend which now covers a brew of management, budgeting, sales, advertising and other forms of applied psychology.
> Ours is the task to remember (and to remind) that, in what is now called “software engineering”, not a single sound engineering principle is involved. (On the contrary: its spokesmen take the trouble of arguing the irrelevance of the engineering principles known.) Software Engineering as it is today is just humbug; from an academic —i.e. scientific and educational— point of view it is a sham, a fraud.
I don't think we have a market failure around that. If I introduce bugs that matter the company loses money. If that happens the company will penalize me by not getting promoted or a raise our even getting fired. Both the company and the individual are already held accountable.
In contrast, how do I even know my medical diagnosis was wrong? How do I know it could have been better given the facts at hand at the time? There also seems to be no market function at all that gives market feedback to the medical institution
Edit: procedures going wrong is of course already highly penalized and insurance for this is a significant cost of our health care.
You assume that IP once created stands on its own. The programming as theory building view suggests that IP will degrade once people who have robust mental models about how the IP was created and works. So software/IP in essence has two critical parts that need to be there, the actual work that was created and robust mental models living in people’s heads who continue to work on those projects.
It also goes against the idea that programmers are replaceable cogs that management can change out as and when they want to.
I think you're misunderstanding the GP. He's not saying the people aren't valuable; he's saying they aren't assets. That is to say, they aren't property.
Which isn't what 'asset' means, but it is the central meaning; using it on people always felt squicky to me.
Maybe they should have done a TikTok or a YT short? Would that be the right length?