https://wmich.edu/writing/punctuation/hyphen

This would’ve helped

To get organized, Getting Things Done in Standard Notes and my email’s calendar app.

To work, Scrum in Taiga.

To handle life, the Healthy Minds app and Calibre to read Acceptance and Commitment Therapy books.

Europe isn’t a brand, it’s a life/style.

Huh. That’s interesting. Are the MacOS coreutils incapable or not user-friendly in some way? Or is it more that they’re too different for people who know GNU and BSD coreutils?

I also wonder if their coreutils are open source. I quickly tried searching here but couldn’t find an answer https://opensource.apple.com/releases/

Thanks for the response. I’m ignorant in this topic. How is MacOS horrific?

It sounds like you really value skill, precision, and usefulness.

Fair enough. Now that I think about it, maybe the developer experience in Apple products are not universally lauded.

For example, I remembered Pirate Software saying that he didn’t develop for Mac because it was a pain, including having to pay Apple $100 yearly to distribute code without issues. Additionally, I remember my brother meeting a Spotify developer, and the Spotify developer said that Apple makes great hardware but lackluster software.

At the same time, it seems like Swift is not a hated language. The 2023 and 2024 Stack Overflow developer survey reports that, even though few people use Swift (~5% of developers), there’s ~60% of admiration for the language.

Oh. I see I was wrong. Amazing. I should look into that! How did you enable it? I did a quick search and found I just need to do gsettings set org.gnome.mutter experimental-features "['scale-monitor-framebuffer']"; is that it?

I’m sorry for having said something untrue. For example, DannyBoy points out that GNOME and whatever Ubuntu uses do have fractional scaling.

However, is my experience untrue? Was I lying when I said that my track-pad two-finger scrolling is frustrating? Furthermore, it’s not unusual for people at work to try my track-pad and it being way too sensitive or too un-sensitive, but no in between.

Was I lying when I said that, for me, it’s hard to get software? Was I lying when I said that maybe this is a skill issue on my part, but even that is indicative of a lack of easy ways of getting reassurance in the way that Apple makes it easy to find software in their App Store?

Was I lying when I said that, to me, GNOME is gorgeous?

Was the creator of the Mojo language lying when he recounted his experience developing Swift?

Was I lying when I said that developers are leaving Linux?

I agree that GNOME and KDE are gorgeous and very polished in many ways. However, I have had some problems in GNOME, Fedora, or Open Suse:

• fractional scaling is not immediately available in Fedora or OpenSuse, at least to users who don’t know how to use the terminal [Edit: Thanks, DannyBoys for pointing out that Ubuntu may have fractional scaling enabled by default and that experimental fractional scaling on GNOME can be activated, at a battery cost]
• the track-pad two-finger scrolling is painful (compared to a Mac) to me and to people who have used my laptop with Fedora or OpenSuse
• sometimes it’s hard for me to get software, especially outside of .debs. For example, in Fedora I had trouble getting Signal Desktop installed from a source that I felt comfortable with (maybe this speaks to my ignorance in how Fedora packages are set up and distributed more than the reality of insecurity, but even this is part of the issue: I couldn’t find any reassurance). To be fair, Open Suse gave me that reassurance, because I understood that YAST was somehow more directly tied to the source (I could be wrong, but that was my impression). However, YAST’s software download software is a far cry from the kind of UX that the GNOME Software app is or the Apple App Store.

Despite these problems, I do have to say that GNOME is absolutely gorgeous. It’s precisely the kind of user-centricity that I want to see in Linux.

However, the end-users aren’t the only users. There are also developers! For example, I remember listening to the developer of the Mojo language talking with Richard Feldman, and the developer said that the development of the Swift language made it clear to him that Apple is aggressively user-centric. I don’t doubt that there are many problems with Swift as with Apple products in general, but I don’t see that kind of discourse in Linux coming from the main maintainers. Instead, there seems to be a vanguard arguing for a better developer experience (such as writing kernel code in Rust), and they find loads of friction. Heck, key developers are leaving Linux!

Edit: Clarified what is strictly my interpretation.

Today, it is practically impossible to survive being a significant Linux maintainer or cross-subsystem contributor if you’re not employed to do it by a corporation. An interviewer to the Linux dev that’s mentioned in the article: “So what did you do next to try to convince the Linux kernel devs of the need for more focus on end-users?”

I appears as if Linux is a nest that is not built with a consistent set of user-centric principles. Instead, it seems that each part of the nest is built with a specific corporation or project in mind.

Assuming I’m right that Linux is built with project-based thinking and not product-based thinking, I do wonder what a user-centric Linux or another user-centric FLOSS OS would be like, an OS that is so smoothly built that users come to think of it not as an OS for tech-savvy people, but an obvious alternative that you install immediately after getting a computer.

If Linux is indeed built with project-based thinking, then I wonder why that is. The uncharitable explanation is that someone doesn’t want Linux to have a MacOS-like smooth and gorgeous experience. If you don’t think MacOS is smooth and gorgeous, I’ll address that.

I know some people have suffered immensely with Apple products not only because Apple builds devices that can’t be repaired, but because of things simply not working. However, there are many people who love Apple. That’s the kind of passionate advocacy that I would love to see in Linux, and not just around freedom and value-based judgements. I want Linux to be thought of as the least-friction tool for professional or recreational use. I want people to think of Linux as gorgeous and usable.

Of course, we can apply Hanlon’s razor to this situation (“Never attribute to malice that which is adequately explained by [ignorance or lack of skill or practice].”). Managing a product is difficult. Managing a community is difficult. When the nest’s design is not built by a team constantly seeking to care about users, but instead by a bunch of users pecking into the nest until their corner is shaped the way they want, it’s not surprising to see a lack of user-centricity.

Agile is indeed more of a mindset than a rigid system. In my recent experience helping a tabletop game team, we applied Agile principles to great effect. Rather than trying to perfect every aspect of the game at once, we focused on rapidly iterating the core mechanics based on player feedback. This allowed us to validate the fundamental concept quickly before investing time in peripheral elements like the looks of the game.

This approach embodies the Agile value of ‘working product over comprehensive documentation’ - or in our case, ‘playable game over polished components’. By prioritizing what matters most to players right now, we’re able to learn and adapt much more efficiently.

Agile thinking helps us stay flexible and responsive, whether we’re developing software or board games. It’s about delivering value incrementally and being ready to pivot based on real-world feedback.

I appreciate your candor about not wanting to speak on topics outside your expertise. That’s commendable. I wonder if we can still talk with the understanding that we may not know it all. I truly believe curiosity is able to sidestep many of the problems related with ignorance.

You’re right to be cautious about appeals to authority. My intention wasn’t to suggest NASA’s use of Agile validates it universally, but rather to counter the OP comic’s implication that Agile is inherently incapable of achieving significant goals like space exploration.

Regarding Agile-like practices in earlier NASA projects, you’re correct that concrete evidence is limited. However, we can analyze their approaches through the lens of Agile principles. Scrum, for instance, aims to foster characteristics found in high-performing teams: clear goals, information saturation, rapid feedback loops, adaptability to changing requirements, and effective collaboration. These elements aren’t exclusive to Scrum or even to modern Agile methodologies. The key is recognizing that effective project management often naturally gravitates towards these principles, whether formally adopting Agile or not.

It’s an interesting area for further research: have complex engineering projects historically incorporated elements we now associate with Agile? If so, how?

Your skepticism is valuable in pushing for a more nuanced understanding of project management across different domains.

I can see you’re frustrated by the downvotes and pushback you’ve received. It’s understandable to feel defensive when your viewpoint isn’t well-received. I appreciate you sharing your perspective, even if it goes against the majority opinion here.

Your points about the space shuttle program’s challenges are valid and worth discussing. It’s important to note the timeframes involved though. The shuttle was developed in the 1970s, well before agile methodologies emerged in the 1990s and 2000s.

Interestingly, one could argue that NASA may have used agile-like practices in the space shuttle program, even if they weren’t labeled as such at the time. However, I did a quick search and couldn’t find much concrete evidence to support this idea. It’s an intriguing area that might merit further research.

Regarding modern agile approaches, while no method is perfect, many organizations have found them helpful for improving flexibility and delivering value incrementally. NASA’s recent use of agile for certain projects shows they’re open to evolving their methods.

I’m curious to hear more about your thoughts on software development approaches for complex engineering projects. What do you see as the pros and cons of different methodologies? Your insights could add a lot to this discussion.

Edgy meme: agile bad

NASA: “Yep, we use agile” https://ntrs.nasa.gov/api/citations/20160006387/downloads/20160006387.pdf?attachment=true

Your comparison is interesting, but let’s consider some historical facts. The Apollo program, which successfully put humans on the moon, actually employed many principles we now associate with Agile methodologies.

Contrary to popular belief, it wasn’t a straightforward Waterfall process. NASA used frequent feedback (akin to daily Scrums), self-organizing teams, stable interfaces so that teams are an independent path to production, and iterative development cycles - core Agile practices. In fact, Mariana Mazzucato’s book Mission Economy provides fascinating insights into how the moon landing project incorporated elements remarkably similar to modern Agile approaches. Furthermore, here’s a NASA article detailing how Agile practices are used to send a rover to the moon: https://ntrs.nasa.gov/api/citations/20160006387/downloads/20160006387.pdf?attachment=true

While it’s true that building rockets isn’t identical to software development, the underlying principles of flexibility, collaboration, and rapid iteration proved crucial to the missions’ success. Programs like the Apollo program adapted constantly to new challenges, much like Agile teams do today.

Regarding Kanban and Scrum, you’re right that they fall under the Agile umbrella. However, each offers unique tools that can be valuable in different contexts, even outside of software.

Perhaps instead of dismissing Agile outright for hardware projects, we could explore how its principles might be adapted to improve complex engineering endeavors. After all, if it helped us reach the moon and, decades later, send rovers to it, it might have more applications than we initially assume.

There’s a fair bit of bias in the terms “restrictive” and “permissive”, which make MIT seem like a ‘better’ choice than a give-and-take license like GPL.

The truth is, MIT is risky for developers. Using just one line from an MIT-licensed project will automatically allow others to exploit your work without giving back. I’d prefer to advocate for balanced licenses that protect both user and developer interests.

We are at risk

of losing many developers who would otherwise choose a license like the GPL. Fortunately, I’m glad to be surrounded by people, just like you, who care about licenses like GPL. By uploading this type of content and engaging with it, be show our commitment to it. I wish to suggest how we can deal with this threat.

We will lose developers who choose GPL if we use words that suggest GPL is “restrictive”. Sure, the word “restrictive” was avoided in this meme by using the word “copyleft”, but the cognitive jump from “permissive” to “restrictive” is minimal: just add an “opposite” and you’ve got “permissive is the opposite to restrictive”. It really is that simple. That’s how brain works (check out Relational Frame Theory to see how that works).

So what can we do about it?

Well, we can approach this with science. There is a historical global trend towards people being more meta-cognitive. That means that people are becoming more aware of how our thoughts interpret everyday reality and how to be intentional with our relationship with our thoughts so that we live better lives. We know this trend is happening to virtually everyone everywhere because of the work of brilliant sociologists like Anthony Giddens and Christian Welzel. Heck, even the history of psychology —going from noticing and changing behaviors (behaviorism) to noticing and changing behaviors and thoughts (cognitive-behaviorism), to noticing and changing the context and function of behaviors, thoughts, and emotions (functional contextualism)— reflects this trend.

We can use meta-cognition in our favor; we can use the meta-cognitive tool of framing to change how we think about GPL and MIT licenses. Effective communicators like influencers, political campaign experts, and influential activists use framing all the time. For example, instead of using the dangerous framing that suggests GPL is ‘restrictive’, we can use another one that truly displays the virtues of the license.

What would this other frame look like? I may not have a perfect answer, but here are some

ways of framing (thinking about) the relationship between licenses like GPL and MIT:

(ironically!!!, these were ‘suggested’ by an LLM; I wonder if these frames already existed)

• “Investment-Protecting Licenses” vs. “Investment-Risking Licenses” (as in developers invest by working on projects that they could (not) lose the ability to contribute to)
• “Community-Resource-Guarding Licenses” vs. “Exploitation-Vulnerable Licenses”
• “Give-and-Take Licenses” vs. “Take-and-Keep Licenses” ⭐
• “Freedom-Ensuring Licenses” vs. “Freedom-Risking Licenses” ⭐
• “Contribution-Rewarding Licenses” vs. “Contribution-Exploiting Licenses”
• “Open-Source-Preserving Licenses” vs. “Closed-Source-Enabling Licenses”

I’d be happy to hear what you think, including suggestions!

The article’s “valuing your time” argument is problematic in certain contexts. My brother has had so much trouble with his dual-boot (Windows and Linux). Yes, he could learn how to solve something in Linux every time a problem arises, but he also has to deliver his projects on time. Because of that, he mostly spends time on his Windows dual boot. Yeah, it sucks ethically and has its own pragmatic issues, but he has never had issues resolving dependencies or hunting down the most recent version that can actually be run in NixOS.

I don’t doubt these will become issues that will not be as problematic in the future, but right now my brother cannot use Linux reliably for his assignments.

Edit: My brother has tried what I use: Fedora and NixOS. He has also tried PopOS.

In Fedora, he found some of his software didn’t exist as .deb, and struggled to make .tar files work smoothly for him.

He tried NixOS afterward. He really liked the whole immutability thing, as well as the idea that apps would have their own dependencies.

His dependency problem happened in PopOS. If I remember correctly, it was a code editor that required a version of something that was different to what a package he used in his software was.

I think the order he tried was Fedora -> NixOS -> PopOS -> NixOS -> ? (Haven’t talked to him about it recently)

You could check out NixOS :)