Sorry, no one is gonna prefer to watch flag football over full contact tackling. This is an absurd article. And the fact that the Olympics are holding a flag football event is a joke.
Roman gladiatorial combat rarely went to the death. Fighters were valuable media personalities, much like pro athletes today, supposedly including product endorsements and billboard advertising! Battles and fighters were focused on spectacle. It was basically just the WWE
Really, no one? Flag participation is already higher for 6 to 12-year-olds than tackle. Lots of girls participate in flag. I suspect they'll be interested in watching the sport they grew up playing. It might never be more popular than tackle, but to say no one will prefer watching it is silly.
The part where they had a poll was very unscientific, it left comparisons to random audio equipment on the listeners end. Results would be based on the listeners situation more than the source.
That’s a bad process. The review of the feature should start before it’s merged into main branch, not after. It totally reasonable for people to be upset with a breaking feature in main branch without discussing it with the community at large. Changes merged in like this are how long standing tool lose community support.
The review of the feature was happening in public on the mailing list. All those who contributed to that review had their concerns addressed, and the change was merged into the main branch (which is the development branch of Emacs). Only afterwards did others complain.
The article is just his author view. Please read the emacs mailing list threads to get the full picture.
GP is correct, and this is quite normal: some people using Emacs master will not follow all the mailing list discussions and commits. So they will notice a change only after it is merged. Nothing wrong with this, and nothing wrong with being unhappy about such a change. What's wrong in my book is the nature of the reaction show in this article (see my comment in reply to @tarsius).
That's what the article says, but I checked the actual mailing lists. Any replies that asked for a change of this kind came in after the patch was finalized. Even this author's own complaints. And, the author in particular didn't understand, or seek to understand, why the patch was added in the first place. Instead, their proposed "fix" that they complain about in the article reverted all of the improvements the author and reviewers made. Upon being informed of this, they simply complained that those are useless changes:
> Indeed, I only reimplemented the parts I saw as clearly beneficial.
Most importantly, my patch improves stuff without breaking other stuff.
> Perhaps you can explain your use case for the rest of the changes, and
if there's a good and compatible way to add them I'll be happy to look
into it at some point.
> > - No filtering.
> > - No navigation.
> > - No default registers.
> > - No possibility to configure a new command added to register.
> If you could elaborate about these bullets, and explain their use,
that'd be great.
I think it's quite obvious that engaging further with someone who came in with this attitude after a review was finalized (after ~5-10 rounds of feedback, I should point ou) and a patch applied did not seem worth it.
On the job, I wouldn't go implementing whatever pops into my head without input from my manager and product management.
Even if the change could easily pass a technical review and get merged.
First you have to determine: do we need this for the product? If this change is made, does it break user workflows? What difficulties will users have if they pick up this change?
Emacs is a community-driven project. And the author of this patch identified several issues with the feature, created a fix, proposed it for review, debated the impact with other devs on the mailing list for weeks, addressed all concerns raised, and then finally other more senior devs merged the change to master, where all new unstable changes go.
Then, people who agree to test out all changes to Emacs by using the head of master found, basically the QA department of Emacs, came back with feedback that they like some of the improvements, but that they don't like one particular aspect (the extra RET). Thierry started addressing them, and a setting to disable the feature was added - but the initial version missed the mark. The article author also was part of this process, and even proposed a patch, but their attitude made others ignore it after the initial review (their patch reverted all changes and only implemented a tiny subset of the original, behind the discussed flag).
Thierry opened this as a simple bug, but then implemented something with multiple enhancements rather than addressing the bug, while causing UX regressions.
It looks like only one developer was engaging the content, a Michael H., and he pointed out early, as far back as in October, both the problems that Eschel later latched onto.
Eschel came up with a patch that just addresses #66394 in a small way.
"But your patch only fixes this bug, reverting half a dozen features mine adds."
Using a bug ticket as a vector for introducing enhancements is a software engineering no-no.
They should merge the simplest patch that closes the bug without regressing anything or introducing extraneous enhancements. For those, a new enhancement ticket should be opened.
If Eschel's patch can close #66394, and not break anything, the consideration of that it doesn't implement another solution's enhancements is actually a plus.
There is possibly another bug ticket hiding in there based on the remark [y]ou reintroduced the old implementation which was not wrote correctly about handling various keys, particularly C-g. Existing behavior of not correctly handling various keys sounds like a problem different from the 66394 issue.
If the project doesn't want the simplest fix for an issue, but to address something architectural, like with a view for adding enhancements or whatever, that can be turned into another ticket where you articulate that. The original bug can then be marked pending or blocked by that with a note that we don't fix this until that one.
Does Emacs even do enhancement tickets? It is a community driven project where people implement what they want to scratch an itch and get merged as long as they convince enough people; it is not a PM driven one with roadmaps, sprints and narrowly defined features.
My partner works for a company that uses thin clients to aws instances and they get about half of the hardware back. They don’t even attempt to get the monitors back.
I use Jellyfin on Roku and Apple TV and the Jellyfin apps work just fine. Sometimes the Roku app loses its credentials, but they’re working on these issues and the apps keep getting better. Although I only use Jellyfin on a local network.
Depends on the field, in real-time application and games it’s gonna mostly refer to data driven design more than domain driven design. Honestly haven’t heard domain driven design inside the games field since the early 2010s.
Is software architect a common title in game dev ? It's been a decade since I've looked at the field but it kind of antithetical to the industry as I remember it.
The new phones aren’t more compelling than the one I already have. I have an iPhone 11 Max Pro and it’s been great since 2019, the newest iPhones just aren’t compelling to upgrade, and I’m also not wanting to make that usb-c leap because all my accessories are currently lightning based.
So how would you solve the AOT (ahead of time compiling) problem without code generation? An entire ecosystem (Unity) that uses C# requires that code must be AOT for supporting IL2CPP (a low level translation of IL to c++). Dynamics and Reflection of non-AOT types are unavailable at runtime. IL2CPP came from Apples requirement that no JIT be run in apps and to get more performance; especially, for features like burst that allows writing C# that directly translates to high performance multithreaded c++.
Different usage, I think: if people are talking about "language not expressive enough", they're referring to mechanisms for generating C#, or IL, not things further down the toolchain for AOT.
System.Xml.Serialization, for example, relies on generating assemblies at runtime to work. That's "code generation", but of a kind that directly conflicts with the AOT meaning of "code generation".
You’re just wrong, Amazon controls around 35% of all US e-commerce. Not being able to sell on Amazon instantly removes most of your available customers. The second largest is Walmart and it’s closer to 7%. Walmart, target, whatever, don’t add up to Amazons market.
> Amazon controls around 35% of all US e-commerce. Not being able to sell on Amazon instantly removes most of your available customers
Math doesn't check out. Not to mention that if sellers stopped selling on Amazon they wouldn't control so much. How exactly is making everyone sell on Amazon going to solve anythin?
Sellers should stop using Amazon if they don't like their policies, and the issues will correct themselves.
And even if they price the same on Walmart as they would on Amazon: ($5 selling price - $0 fees - 0.80 COGS) * (100k * 7%) = $29,400
See the issue? The problem is that one seller on Amazon moving to another platform won't change the fact that Amazon has the majority market share. That's how market momentum works and it's why we have antitrust laws.
Even with exorbitant fees, they are still where sellers need to be. And they are using this market share to force sellers into overpricing on other platforms so that they maintain this unfair position.
If a seller raises prices to match Amazon, they can be undercut elsewhere by those willing to forgo Amazon for the larger overall market share.
Amazon is convenient to small sellers in that they offer more customers on a single site than any other, and with limited bandwidth sellers logically want to minimize how many different sites they need to interact with, but charging for convenience is not inherently anticompetitive behavior. Amazon may have abused it's position in the particulars of its MFN implementation, but MFNs in general are fine.
There are two reasons why that 65% number is wildly unrealistic:
1. We're ignoring fixed costs associated with onboarding with an ecommerce platform. Selling on one website has significantly lower fixed costs than it is to sell on every ecommerce site on the internet minus one. We're talking thousands upon thousands of retailers, not a handful. If what you were thinking is that they could sell across the next 5 to 10 most popular ecommerce marketplaces, you're somewhere between 15% and 20% marketshare.
2. Not all ecommerce sites represented in that 65% permit third party sellers. You can't just sign up and sell your stuff. You may have to convince their buyers to stock your product. This is not easy or cheap.
> Not to mention that if sellers stopped selling on Amazon they wouldn't control so much.
This is a problem in terms of organisation. If lots of people stop selling on Amazon this would be true. The problem is individually each seller is motivated to deal with Amazon so long as lots of other sellers are. A mass exodus from Amazon would in short order make the Amazon store far less relevant, but nobody wants to leave before everyone else is doing it because until then it costs them
Or, hear me out here, The Federal Trade Commission orders a study done and the study corroborates the general sentiment here that Amazon is abusing their power in the marketplace. So, the FTC then sues Amazon.
Your 'feelings' about how this works only matters to you. The US branch of oversight for trade has declared (with a lawsuit) that this behavior is unconscionable and either is or will be illegal by the time this suit is finished.
You're welcome to dispute the FTC and the crowd here on HN, but you need to provide some sort of data to back up your claim of: Sellers should just stop using Amazon...the issues will correct themselves.
The FTC's suit alleges the exact opposite of what you allege. The FTC states that there is harm to the entire economy if Amazon is allowed to continue this practice.
Please cite the studies, data, or metrics you used to claim '...will correct themselves."
And if lots of items became available on other sites, but not Amazon (as per the theory being propounded), then Amazon would no longer control 35% of all US e-commerce.
This is a classic coordination problem: you need all the sellers to leave together so that individual merchants don't take a loss. And coordination problems like this are one of the main areas government action can help!
Also, I'd imagine that coordination would probably leave them vulnerable to their own set of anticompetitive allegations (i.e., some variant of cartel behavior/price-fixing). To the extent anyone acts, it would probably have to be government.
There are companies that do not sell on Amazon. I seek them out. They will tell you that if their product appears on Amazon, it's counterfeit.
It's probably an impossiblity if your business model is selling cheap imported Chinese garbage at a profit, but that's the businesess you chose. Others have chosen to sell quality items on their own terms. Those are the businesses I want to reward.
Even so, a lot of those corporate web applications rely on .net frameworks for integrating with shared point, ad, and many other established enterprises services and applications so they’re still stuck to windows. An example, all my partners medical software is through a browser but requires multiple system frameworks to function. Also they’re all using Remote Desktop to Amazon workspaces that are running windows.
