The input format of the xargs command doesn't match what any other command produces.

The input format of the xargs command doesn't match what any other command produces. Yes, it's bizarre. With -I, xargs ignores indentation, which is why the file names with initial spaces are mangled. Do not use xargs except with the -0 option or when you know your input doesn't contain characters that would confuse it.

The ls command doesn't expand wildcards, it's the shell that does. Do not parse the output of ls, it's practically never needed and often breaks something.

_

find . -maxdepth 1 -mindepth 1 | xargs -d'\n'

Do not pass arguments right into subshell, it's as unsafe as eval.

DO NOT PARSE LS.

Do not use xargs without -d when you do not want ' " \ to be handled specially.

This can lead to confusion if you expect to be able to access a Mash value through the property-like syntax for a key that conflicts with a method name. However, it protects users of your library from the unexpected behavior of those methods being overridden behind the scenes.

Comparing to Mash your custom class lacks mash-like deep initializer which is a different concern from MethodAccess. So you just need a smart initializer extracted from Mash (just like MergeInitializer but deep), probably implemented as a separate extension. So It's a initializer issue, not an issue of MethodAccess.

Wine isn't an emulator, it's a collection of code that interprets Windows executables for various different systems: "Instead of simulating internal Windows logic like a virtual machine or emulator, Wine translates Windows API calls into POSIX calls on-the-fly, eliminating the performance and memory penalties of other methods and allowing you to cleanly integrate Windows applications into your desktop." https://www.winehq.org/ FWIW, the Steam Deck relies heavily on a derivative of Wine for getting existing programs to run on the platform.Some programs will actually run faster under Linux + Wine than under Windows, which wouldn't be possible for an emulator running on the same hardware system.

Regardless of what your arguments are, the personal reasons of the developer are what matters for what platforms this game is provided on. You can choose to pay for the game, or not. Paying for the game supports the developer, and allows them to develop more. It is not reasonable to argue that someone should have put in additional unpaid effort to do something for unknown future benefit, or that they should charge less for a game because it's only available on one platform; that's their choice, and their decision.For context, development of Taiji was started in mid 2015; it took seven years to finish. That's with the Commercial Game Engine, and even with that, there were platform-based bugs that needed to be worked around (issues that won't be present on other platforms, or will have different presentations); here's just one of those, involving an issue around mouse sluggishness:https://taiji-game.com/2020/07/13/68-in-the-mountains-of-madness-win32-wrangling...If the developer is not already familiar with Linux, then there's a small mountain of language barriers around using Linux that needs to be overcome first, before being able to get to the game development phase. It's rare for game development to work on different platforms when it can't be tested on those different platforms. While it might be easy to cross-compile on a Windows system (e.g. via IL2CPP), that's only if everything works perfectly (which is unlikely to be the case). 

The high-level view of your responses are that they are an attack on the developer of this game, someone who has already put in seven years of effort to get to this point already (as demonstrated in the game development blog). The developer does not need that, and digging in deeper to become more aggressive will not help you get what you want. There are reasons for not developing on Linux, as there are for other platforms (e.g. MacOS, PS5, Switch). As great as it would be to just drop the same code on different platforms and have it work perfectly every time, that's not the reality. There are *always* platform-specific issues that crop up: "If you don't design your software with platform-nonspecificity in mind, then it just makes it harder. Nothing is truly impossible to port, disregarding hardware capabilities and computing speed. There's no such comprehensive "tool" for porting games to other platforms, though, since they all work differently under the hood." https://gamedev.stackexchange.com/questions/49375/what-are-the-main-requirements... Regardless of your own personal opinions on what should or shouldn't be done, the developer has already answered your question about Linux ports, in particular mentioning that it is appropriate for users to use Wine (in the form of Proton) to play Taiji on Linux. And, if the game not working on Linux is a showstopper for you, the developer recommends you consider purchasing on Steam due to a better refund poli

This library is no longer called vCardMate!

Why would a text message service require Location (GPS) permissions? Anyway I enabled this Location permission for testing. Heureka!!! Suddenly I was able to send text messages again to all the contacts which previously didn't work. The "Not sent, tap to try again" error was gone.

Glimmer DSL for Web intuitively supports both Unidirectional (One-Way) Data-Binding via the <= operator and Bidirectional (Two-Way) Data-Binding via the <=> operator,

Following a policy change by WhatsApp, many people are looking at alternative messaging options. The new WhatsApp policy requires people to share data with Facebook and associated companies.

WhatsApp is doing the exact thing it said it wouldn't do when it was acquired by Facebook seven years ago.

Driver management through Selenium Manager is opt-in for the Selenium bindings. Thus, users can continue managing their drivers manually (putting the driver in the PATH or using system properties) or rely on a third-party driver manager to do it automatically. Selenium Manager only operates as a fallback: if no driver is provided, Selenium Manager will come to the rescue.

How to use “case” to match class names? (=== not so funny)

def ===(other) @holder == other end

One way to potentially get around this is to have an object that simple holds a class and overrides the === operator to make case work properly:

The "From:" field specifies the author(s) of the message, that is, the mailbox(es) of the person(s) or system(s) responsible for the writing of the message. The "Sender:" field specifies the mailbox of the agent responsible for the actual transmission of the message.

In my experience, client software usually honors Reply-To, but I have only been exposed to a small fraction of the wide array of client software that people might use.

The autological word "eggcorn" is itself an eggcorn, derived from acorn.

our Rule 8 of Commas says, “Use commas to set off the name, nickname, term of endearment, or title of a person directly addressed.” Therefore, we would write: Good Morning, Mary. However, it is also acceptable to write Good morning, Mary. Good practice is to decide on a style and be consistent.

Formal application of punctuation with a salutation that doesn’t include an opening adjective (e.g., Dear Sir) would call for a comma preceding the person’s name as a proper form of address (e.g., Good afternoon, George). Whether to follow the name with a comma or a colon would be determined by the relationship’s context: Good afternoon, George, (comma for familiar) Good afternoon, George: (colon for formal) At the same time, you are correct in observing that current communication often omits the salutatory comma of address, particularly for shorter greetings (e.g., Hi Erik). This is becoming more common and acceptable, and it would be a matter of writer’s preference. You would be correct writing either Hi Erik or Hi, Erik. We would advise keeping the comma for longer or phrasal greetings such as Good afternoon, George.

The mortgage document which secures the promissory note by giving the lender an interest in the property and the right to take and sell the property—that is, foreclose—if the mortgage payments aren't made.

Some frameworks call this “template inheritance”. In this example, we might say that the application layout “inherits from” or “extends” the base layout. In Rails, this is known as nested layouts, and it is a bit awkward to use. The standard Rails practice for nested layouts is complicated and involves these considerations

But what if you want to reuse one layout within another?

Here’s my common practice: Every page in the app needs the standard HTML boilerplate with my common stylesheets and JavaScripts. I need a layout that provides these, but makes no assumptions on the actual body of the page. This is my “base” layout. Most – but not all – pages in the app need a common header and footer. This is my “application” (default) layout. I’d like the application layout to reuse the base layout to keep my code DRY.

ZenHub’s Issue dependencies not only help teams visualize relationships between pieces of work, but they save team members a lot of time that would otherwise be lost just hunting down information.

When relying on just a list of GitHub issues and comment references to other Issues, there’s a strong possibility that visibility into how these changes impact other tasks get lost or forgotten.

Tracking dependent relationships between Issues and whether something is blocking another piece of work is important with any project process because it creates a central hub where everyone can communicate what’s needed without relying solely on meetings or comments to uncover important connections.

his is a killer-feature which I miss since I switched from Jira to GitLab. I'm using GitLab on a daily basis even in solo-projects and I miss this every day. Everybody would find value to this when using Issues and realize, that some depend on others (so basically always).

This feature is a planned EE feature and so it is being tracked there. We currently have no plans for it to be in CE, so that is why this issue is closed.

Using an issue tracker without them is, in my opinion, a little like using an outlining program that only supports two levels of nesting, or like using Wiki software that doesn't have the concept of reverse links. Makes me sad!

It's also common to want to compute the transitive closure of these relations, for instance, in listing all the issues that are, transitively, duped to the current one to hunt for information about how to reproduce them.

Marking an issue as as a subtask of another. Having task lists in a description is a great start, but it doesn't help (AFAIK) navigating from child back up the chain to parent. Creating umbrella issues is a very common way to track the top-level focus areas for a release.

Thank you all for the detailed feedback. I want to emphasize we value your feedback. We believe it is a huge advantage for us to be able create GitLab transparently here in the community, with your contributions, whether they be ideas and analysis here or in actual code. Thank you for your excitement and passion.

@josephmarty mentioned desired outcomes as a focus. That is great. We encourage all types of feedback. Whether you want to highlight a problem, a desired outcome, have a design or implementation. Whatever you have, we welcome the ideas and encourage ongoing conversation.

(I grant that many of us contribute code to Gitlab, and would also like to participate as members of the development team in guiding the implementations, but clearly the core team has to have the final say in what direction that takes... unless someone wants to create and maintain their own fork of Gitlab ;) )

The parent/child relation is obviously a transitive, but "duplicate of" may be transitive too, but other relations like "related to" may not be transitive.

Another interesting property may be symmetry. For example "duplicate of" relation is symmetric, but "parent/child" is not.

The "meaning" will tell Gitlab how to interpret the relation. For example, a "parent/child" relation will have the meaning set to "one is a part of another", and then user may define a "subtask" and "subcomponent" relations to distinguish two situations, but Gitlab will understand because all three will have the same meaning and it can render a tree with three different kinds of edges.

There is also #8988 (closed) about custom fields. It there is some flexible architecture like in Drupal - all entities can have custom fields (and some form widget and some formatter), so building other features what needs to store data is more simple.

I thing you are doing a very subtle mistake which will become fatal in long-term. Your strategy to take small steps that cover as much functionality as possible is reasonable, but it is necessary to be careful, as it leads to a critical state when there is too much little stuff built up without proper structure to support it.

When the relations are implemented in the right way, they will simplify Gitlab, not make it more complex.

Another example are issue boards. They represent elegant use of a good infrastructure ­— it is all just a smart use of labels. It would be very complex feature without the use of labels.

Issue relations are meant to be the basic infrastructure to build on (at least that is how I meant it when I posted the original feature request). Just like the labels are just a binary relation between a issue and a "label", the relations should be just a ternary relation between two issues and a "label". Then you can build issue task lists on top of the relations like you've built issue boards on top of the labels.

That helps us keep GitLab simple as long as we can.

Introducing relationships between issues will considerably increase the complexity of GitLab. That is not a reason not to do it. But it is a reason for us to be strategic in when we do it, and ensure we have a good design that is scalable and aligns with our other initiatives.

This would be transformational in the scope of what issues can be effectively used for!

subtasks would give insight into how long it will take!

Blockers would give better insight into when an issue can be started,

Our flow is: The reporter reports an issue, and we developers create sub tasks upon that issue... in Redmine, we also had a percentage graph that would reach 100% when all sub-tasks were completed, was a great way about checking 1 item without the need to drill down all subtasks.

We use GitLab to manage software on interconnected embedded systems. What often comes up is this: New functionality on one system changes the protocol in a slightly incompatible way. Software on other systems have to be updated to understand the new protocol, take advantage of the new functionality, and stop complaining about the unexpected data. For this I would create multiple issues: Issues for the new functionality that we need. (Project A) Issue for defining the protocol changes. (Project A) Issue for implementing the protocol changes on the module. (Project A) Issues in related software projects for implementing the changes required to understand the new protocol. (Project B, C, D...)

bugzilla has had the concept of one or more ticket(s) blocking another for quite some time. We used that for over ten years before switching to GitLab and it is a feature I miss. A dependency tree between issues enables planning and workflow. This is can be seen as related to issues boards in that blocked issues should not be able to move ahead until the blockers are at least implemented perhaps reviewed.

It would be useful filter to have, also it would be useful to sort issues using topological order on Board and other issue listings, so the unblocked issues would be first.

Simple relations: [Issue A]---(relation R)--->[Issue B], which is a ternary (A, B, R) relation in a database.

We already have a very nice example of such tool and its great use: the Board, where labels are used to store metadata and the Board is built above this storage. Do the same with the relations -- simple metadata storage to build on.

Such a generic approach will allow the Relations to fit any reasonable workflow, because possible relations are defined by users, just like the Labels are.

duplicated by - Reciprocal of duplicates.

duplicates - Links issues so that closing one, will close the other (e.g. closing A will close B) For example, if issue B duplicates A: - closing B will leave A open - closing A will automatically close B duplicated by - Reciprocal of duplicates. For example, if issue A is duplicated by issue B: - closing B will leave A open - closing A will automatically close B

some of its properties needs to be specified, like whether the relation is transitive, so filtering can include or exclude issues related to related issues. For example when I want to see issues blocked by given issue, a filter needs to calculate transitive closure (recursively expand the relation on related issues until all reachable issues are found). On the other side, issue may be related to a second issue, but not to the third issue to which the second issue is related to.

Relation needs two labels, because of its direction ("blocks" vs. "blocked by").

I see specific relations in a similar way as labels. If a "label" is a binary relation between a label and an issue, "relation" between issues would be ternary relation between two issues and a label (from different set than ordinary labels).

Purpose of the relations should be to allow advanced analysis, visualization and planning by third-party tools or extensions/plugins, while keeping Gitlab's issues simple and easy to use.

One of the reasons that some projects don't use Gitlab's issues and use an external tracking platform is the lack of issues relations. Without relations issues are just flat, no way to actually track progress of big features. No way to create a "meta" issue that depends on 4 other or create subtasks and so on. The same problem exists on Github too. It would surely make a difference if Gitlab offers a full features tracking issue, instead of just flat issues. Relations is a major first step towards that.

Closing this issue down as a duplicate for now. If you feel that neither of these issues exactly fits your own proposal, pleae don't hesitate to reopen the issue. 😃

Sub tasks are just issues with a parent issue. When displaying them, always display the ancestor crumb trail.

Board view Subtasks are shown slightly indented from the main task Subtasks can be dragged out of the parent task to a new list to indicate their status. For subtasks with a different status to their parent, it displays a dummy parent (ghosted), above the subtask in the list, with the parent's status label visible against the dummy. Dragging the parent task to a different list changes the label of the child tasks as well, and any sub tasks already in its new list are re-organised under the parent and any dummy removed

From a branding perspective, it’s a bizarre and self-sabotaging move. Twitter is an established, internationally recognizable name. It’s cited in untold numbers of books, broadcasts, TV shows and news articles. Every internet-literate person knows what a tweet is. Needless to say, it will be hard to persuade regular people to refer to X as “X” instead of good ol’ Twitter. Plus, a single letter is difficult to google. These are just some of the many, many reasons why Twitter/X users are dunking on Musk’s new rebrand.

Work items can only have one kind of relationship to another (parent/child, blocking/blocked by/related).

Allow customers to set their own hierarchies

There are 2 main groups of locations for answering these questions. A single item A bunch of items (lists, boards, roadmaps, widgets)

(comment thread)

Hierarchy is about relationships between things. The most common hierarchical relationships are items that have a parent/child relationship.

Information and user interface components must be presentable to users in ways they can perceive.

By abstracting code away from "Files" and "Lines" we can offer more nuanced views like "Repeated Code Blocks" that could be refactored.

we should break down and MR into "Blocks"

Code block Metadata block Note block MR block (we should still be able to interact with the MR as a whole thing, e.g. leaving a generic comment on the whole thing)

A user wants to comment on a single parameter name in a function. It is highlighted as a unique part of the syntax tree, and they're not happy with the particular name the author of the MR chose. Problem: The user can only comment on the entire line, because "lines" are considered the most fundamental building block in our Diffs UI.

A user notices that an unchanged part of the diff already has features that are being implemented in the changes in the MR. The user leaves a comment on the unchanged part of the diff, telling the author that what they're trying to do is already present. Problem: The author cannot see that comment in the Changes tab, because the comment is outside the understood scope of the diff.

A reviewer wants to view all comments on an MR in a condensed list, and - for each one - see the context of that comment. Problem: Notes (on the MR) and Discussions (on the Diff) are treated differently, and Discussions necessarily come with Diff context. Diff context with Discussions is difficult to match with actual diffs because rendering diffs isn't designed for non-Changes-tab contexts

A reviewer would like to open a discussion on the MR description because they disagree with some of the conclusions, but want more clarification. Problem: The only way to have a conversation about the MR metadata (like title, description, labels, etc.) is to open a generic note on the whole MR. There's no way to scope a discussion to a part of the MR.

It’s a shift in mindset where the question changes from "were we busy doing the tasks?" to "did we move the needle for our organization to thrive?"

graphql

Please gentlemen, do not argue! I think we have to bear in mind that words sometimes can be deceitful and that is why we have to be very careful when using them in order to avoid misinterpretations. Thank you maljo for being such a gentleman! And you, eddiemel7778, is it alright if I ask you to choose a little better your words in order not to sound so "aggressive"?

Although, the discussion above has only been considering Figma, we need to keep in mind that there are other design tools out there.

I'm not sure that isolating design is something I'd prefer. I'd rather have an issue tagged (labeled) as such, and then attach design artifacts. I start a design in the same way I start frontend, with a list of requirements and acceptance criteria in mind, the design is just an artifact, a deliverable, an asset.

Interest

resolution of a design widget is more like closing an issue than an MR

Design widget is an extension of the issue description coz words can only describe so much.

I feel we need a agreeable definition of work-items. It is getting confusing already. If the goal is to avoid confusion then exceptions must be avoided.

One way is to have a very simple model of the same thing like Github and let users decide on the hierarchy of things. If Gitlab really want to go one step further and give users more then its really important simplicity is not killed in the process.

A task is used further down in the workflow. When I think about planning features, they occur before development takes off. The task is used by the developer as they are breaking down the issue into smaller components.

The comparison to MRs is a good one, because MRs have a distinct workflow and JTBD. As such, they are their own object record. I'm not sure whether a decision to move them to work items has been made, but I can see a case for and against.

I feel that the current design area should be a key part of the workflow on any work item, not just type of designs. As a PM I don't schedule designs independently. It's odd to open and close a design issue when it doesn't deliver value to the customer.

Discussions tied to the design itself is solved today with design manager, which allows those design discussions to occur within the context of a bigger issue. Bringing design manager into other work item types, like epics, would help, as would surfacing discussions from designs into the main discussion space. That behavior should be consistent for any work item type with design management enabled, rather than just for a design type.

This is true for other tasks besides design — frontend implementation, backend implementation, QA, etc — would we create unique types for each? Our suggestion here to teams today is often to break down the work into issues, or now tasks, for each uniquely assignable/trackable piece of work. You could do the same for design, where the task or issue is used to track status, discuss progress and maybe even WIP, but is focused on being SSOT for status rather than design.

Why should this conversation be separate from other conversations about the work to be done? Design is one consideration alongside frontend and backend considerations, which often all intersect and require the same participants. Shifting this discussion to a separate work item can result in disjointed conversations and difficulty finding where a decision was made.

Additionally, it reiterates the need to define "What isn't a Work Item?"

For example, I don't know how doing user research fits in, is it a task or this new "design" task.

but from previous experiences like this, the feature set has to be robust at the start or I think adoption will suffer.

Connecting with Figma should be done via an integration because not all orgs use Figma.

Two way commenting is a good idea as it would allow a natural way of others to interact with designers without requiring to understand how to use Figma.

You can see how the constant jumping between these two tools in the first scenario is super annoying, and also very risky as none of the changes you make in Figma are also automatically being updated in the same GitLab designs.

As a positive example of where this works well: Our VS Code GitLab Workflow extension allows users to not only see comments that were written inside the GitLab UI, but also allows these users to respond to these comments right from the IDE, the tool where they actually have to make these changes.

I don't know how much impact the "Design management" widget vs. "Design" object decision will have, except for the extremely small number of teams that work exactly like we do.

Personally I think we could get a ton more benefits and would also be able to pull new users into our platform by finding better ways to integrate/link/connect/display Figma in our work item objects. Today the biggest downside for "Design management" is that it's basically just a copy of what's happening inside of Figma that has to be manually kept in sync and requires users to constantly switch back and forth:

Display product requirements, user flows, and design behaviors on each screen.

[With Zeplin] we started to engage both UX and engineering teams in the same conversations and suddenly that opened our eyes to what was going on, and overall streamlined our build process.

Track changes for each screen automatically – like Git for designs.

Document what to build and how designs should behave in a central, searchable, collaborative place for the entire product team.

Publish completed designs to Zeplin's platform while you iterate on designs in your design tool.

These can then be used to develop a definition that states the essence of the living thing—what makes it what it is and thus cannot be altered; the essence is, of course, immutable.

The Aristotelian method dominated classification until the 19th century. His scheme was, in effect, that the classification of a living thing by its nature—i.e., what it really is, as against superficial resemblances—requires the examination of many specimens, the discarding of variable characters (since they must be accidental, not essential), and the establishment of constant characters.

taxonomy, in a broad sense the science of classification

Taxonomy is the scientific classification of organisms.

Classification is the process of grouping organisms together either based on features they have in common, or based on their ancestry, or sometimes both. This results in the arrangement of living things into groups.

We’re focusing on classification and taxonomy (which still trips me up on occasion and I live in this space all the time)

Taxonomies are more concerned with providing exhaustive lists while classification is not exhaustive.

Both terms reflect the fact that we encounter large amounts of information in everyday life and our brains need some way to synthesize and contextualize that information.

"Classification" and "taxonomy" are two closely related words that some people find confusing.

It prevents duplicate work as the DRI has a complete picture of the entire project.

DRI: Directly Responsible Individual — A title given to the person who is ultimately responsible for making sure a project or task(s) is completed.

It assigns accountability for the whole project, which means it’s less likely for small details and tasks to “fall through the cracks”, those of which could be missed when responsibility is spread among multiple individuals.

It can sort of be achieved with the current setup (via labels), but I really like where this is going -- turning everything into a similar "object" in a hierarchy rather than separate standalone structures that connect and get "labeled" to show what they are.

The third is the brain of the observer. This is also a strong element in film criticism where the camera is the third eye, the eye of the artificial narrator. The most intelligent film about the third eye spying on the action is `Snake Eyes,' where we last saw Gugino. (You may want to check my comments on that film to see what I mean.)

Most art refers to itself in some way, but nowadays almost every film has some straightforward self-reference in the form of being about some kind of show. There must have been a very influential executive producer some time back pushing this idea for it to be so common.The notion of these kinds of films is to create another world, so combine that with the self-reference gimmick and you have a fantasy kiddie show about a fantasy kiddie show.

More, essentially all research in self-reference for decades has been in artificial intelligence, which is the device around which this plot turns. The language of AI is LISP, the name of the archvillain. In the heyday of LISP machines, the leading system was Flavors LISP Object Oriented Programming or: you guessed it -- Floop. I myself worked on a defense AI program that included the notion of a `third brain,' that is an observer living in a world different than (1) that of the world's creator, and (2) of the characters.

I suppose that what movies should be aiming for: entertainment. Obviously a good movie needs good plot; score; direction; writing; cinematography and acting (all of which this movie has), but what makes me actually care about the movie is the question of 'if I enjoyed the movie'

People on imdb have a bad habit of giving movies they think are overrated 1s, or movies they think are underrated 10s. This movie is an example of the former.

less secure sign-in technology

To help keep your account secure, from May 30, 2022, ​​Google no longer supports the use of third-party apps or devices which ask you to sign in to your Google Account using only your username and password.

Instead, look for the option to "Sign in with Google," which is a safer way to sync your mail to other apps. Learn about Sign in with Google.

To keep your account more secure, Gmail no longer supports third-party apps or devices which require you to share your Google username and password. Sharing your account credentials with third-parties makes it easier for hackers to gain access to your account.

Prepare to transition away from Google Sync Google Sync doesn’t support OAuth authentication, 2-factor authentication, or security keys, which leaves your organization’s data less secure.

One friendly place to start learning more about the technology that holds the Internet together is Julia Evans' blog.

For consumers, the equivalent of "build or buy" could be called "ads or nerds". "Ads" meaning ad-supported services, like consumer Gmail or Facebook. "Nerds" meaning hobbyist services based on free software and commodity hardware.

If you already have computer-based hobbies such as gaming or a social-media addiction, why not learn to run your own services as a hobby? Note, this is very different from learning to code. It's more about learning to be your own sysadmin and tech support, rather than being a programmer.

this is kinda the concept of Patreon and other "tipping" services ... honestly I am pleasantly surprised at how widespread this has become! :) Almost all the YouTubers I follow, who still rely on Google/YouTube ad revenue to some degree, also rely on their Patreon funding to a significant degree. (Crucially the Patreon funding is more dependent on audience desires than advertiser desires, e.g. less sensitive to "The Algorithm.")It's pretty interesting ... given the voluntary dynamic of paying for the media. I personally doubt Hollywood (or any national newspapers or "magazines") would ever adopt this "voluntary" model (instead attempting to enforce per-unit sales via DRM), but without question "pay what you want" is remarkably sustainable for smaller creators.

Actually, that subscription or donation model is fairly different from micro-payments. I want to pay for exactly what I find useful, not all output of some artist or organization. I want the payment to be shared if there are multiple authors or ownership. I want everyone to be able to pay on the spur of the moment, not only in some planned monthly subscription or something.

(my bias is showing through - marketing people don't call it surveillance capitalism, to be fair. That's a pejorative term. They just call it doing their job, generating leads, and increasing conversions.)

The model of Spotify in particular - paid tier alongside a free tier with ads - seems like the simplest sustainable solution I see. Having paid features is the most obvious way to make money, but you want to enable adoption as much as you can. It's the same idea as companies dangling "free trial" in front of you at every turn - in a competitive environment, you want to remove barriers for users to try your product or service. This is essentially the idea of a "loss leader" for a grocery store, or any business really.

just shooting from the hip, to me, I'm glad that subscription services like Netflix and Spotify are becoming more popular. That means that the companies (as opposed to Google & Facebook) don't have the incentive to follow this "surveillance capitalism," i.e. building increasingly sophisticated advertising technology predicated upon the behavioral history of users.(my bias is showing through - marketing people don't call it surveillance capitalism, to be fair. That's a pejorative term. They just call it doing their job, generating leads, and increasing conversions.)

It's better than Chrome, sure. But Firefox, and Mozilla as a company, are going downhill and have been for a few years. How can they be truly against the kind of web that Google pushes for if they're entirely reliant on their partnership with Google to be featured as the default search engine?

Also just by observing what they’re doing it becomes pretty clear. For example: Facebook recently purchased full-page ads on major newspapers entirely dedicated to “denounce” Apple. Why? Because Apple has built a system-level feature on iPhones that allows users to very easily disable every kind of advertising tracking and profiling. Facebook absolutely relies on being able to track you and profile your interests, so they immediately cooked up some cynical reasons why Apple shouldn’t be allowed to do this.But the truth is: if Facebook is fighting against someone on privacy matters, that someone is probably doing the right thing.

Completely get away from everything Facebook: FB, Messenger, WhatsApp, Instagram, Oculus. (Yes, I know it’s hard because people are on these platforms, but it is possible to explain your reasoning to those who care about you and establish contact with them on different apps. I moved a ton of people to Telegram for example.)

I use Messenger but not FaceBook. I think the split was useful.

The answers you seek are difficult ones. The internet isn't free, so someone somewhere along the chain will need to pay for the content. As consumers we pay for internet access, and may sometimes pay for premium content (news site subscriptions, Patreon, etc.) but usually the content that we consume is free to us. Instead, it's the ad services that are paying. The internet content being "free" to consumers can really be a great thing, and equalize the playing field for people of different means. But it does come with its issues.

I share your frustration. This was how I felt when they split off Messenger as a separate mobile app from the main Facebook app. Messaging had been working just fine in the Facebook app, so there seemed to be no discernible reason other than pure greed. No attempt to make anything better or easier for the consumer, no innovation, nothing good for the people using the product. It was really just to inflate their download numbers and somehow make more money off of us. No thank you. I have stopped using Facebook since then.

What they say is this is due to is new EU policies about messenger apps. I'm not in the EU. I reckon it's really because there's a new Messenger desktop client for Windows 10, which does have these features. Downloading the app gives FB access to more data from your machine to sell to companies for personalized advertising purposes.

Instead of using a backup service like Google Photos or iCloud, you host your own backup and viewing platform using Nextcloud Photos, PhotoPrism, or such. Instead of using a password management system like LastPass or 1Password, you host your own password manager like BitWarden.

“We believe that this is a simple matter of standing up for our users,” said an Apple spokesperson in response to Facebook’s first full-page newspaper ad yesterday. “Users should know when their data is being collected and shared across other apps and websites — and they should have the choice to allow that or not.”

This practice offers a sense of control over one's time and allows for personal decision-making. Most importantly, it grants time for reflection before tending to others' demands.

The conflation of this vast array of companies, in and out of Silicon Valley, into the singular “Big Tech” does blur some of the important differences in the unique problems they each pose to society,