Hacker News new | past | comments | ask | show | jobs | submit | nhumrich's comments login

Sometimes you can't quantify actual avoided things. For example you can't prove that a regulation stove actually prevented what could have been a kitchen fire.


To play devils advocate, what we don't know from the story is how effective the playform was. 48 hours after release he was fired, possibly because it was terrible.


We also don't know how big the dev team is. It's heavily implied that it was one, but not actually stated.


I will tell you exactly why we template yaml. Its the exact same reason every code base has ugly parts. And that's the evolution of complexity.

At first, you have a yaml file. No templates, no variables. Just a good old standard yaml. Then, suddenly you need to introduce a single variable. Templating out the one variable is pretty easy, so you do it, and it's still mostly for humans to edit.

Well, now you have a yaml file and template engine already in place. So when one more thing pops up, you template it out.

8 features later, you wonder what you've done. Only, if we go back in time, each step was actually the most efficient. Introducing anything else at step 1 would be over-engineering. Introducing it anywhere else would lead to a large refactor and possible regressions.

To top it off, this is not business logic. Your devs are not touching this yaml all that much. So is it worth "fixing", probably not.


I have found "micro" to be a really good "modeless" alternative to vim


Yeah, same. However, it is a pain to install on some systems because, for example, the Ubuntu package installs a debug build that puts a log text file (or similar, I forget the details) in $CWD everywhere you go. So you end up downloading a binary off Github, which feels dirty to me. And there are some other micro configuration tweaks I like to do.

I'm definitely going to compare this against micro.


Yes. Thats how competition works. The entire internet is built on this concept. Some languages even use githubs infrastructure free of charge. Npm was the way in its early days. Go still is this way. Also, there are already so many products that do this. Custom gmail apps, anything email, DNS, Anything that uses google maps

See Reddit clients vs charging for API debate

If apple wants to shut down beeper, there is a very very very easy way. Release iMessage for android. And suddenly beeper is dead overnight. All they have to do is build the product people want.


The problem isn't the API. If I build a service using the S3 API but run it on my own infrastructure, that's competition to Amazon. If I somehow write a system that uses Amazon's S3 infrastructure without Amazon's approval, I'm probably violating the CFAA.

Beeper's problem isn't implementing the iMessage API but providing access to Apple's infrastructure without authorization.


Lawmakers question why Apple doesn't provide outside authorization to their default secure messaging app, or provide their own secure means of messaging non-Apple hardware a family member might be provided by their cell carrier.

The answer seems to be Apple wants to force families to purchase an iPhone for every family member, or download and agree to the terms of a third-party app in order to securely communicate.


Source? None of the emails shown said anything about buying additional space.


The first email shown in the article ends with the call to action of "get more storage" and a link. Pretty obviously that would be buying additional space, not getting it for free.

(But it would cost something like $5k-10k/month, not the ~$10/month that he seems willing to pay.)


The second one has a link labeled "free up or get more storage."

I suspect it links here: https://support.google.com/a/answer/12005619?sjid=1774262812...


> apple's unique level of control allows it to produce a superior product with more consistency

Another way to read this: Apple has a superior product because they perform anti-competitive practices and don't allow other companies to out-product them. And when they do, they buy them/shut them down before anyone is the wiser.


editorialization. you know as well as anyone that restricting your feature development to your own platform rather than doing a retarded design by committee helps one innovate faster.


We don't need to speculate; internal emails from the Epic trial discuss the motivations.

https://www.theverge.com/2021/4/27/22406303/imessage-android...

In short, Eddy Cue proposed in 2013 that Apple owning the best-in-class messaging app would be a win, and even mentioned the cost being low. Phil Schiller shut him down, arguing it would remove a barrier preventing iPhone parents from buying their kids Android phones.

That reads like anti-competitive motivation to me. In particular, it looks like tying, where two unrelated products are connected artificially. The wikipedia article on anticompetitive behaviors has a section on tying, and mentions another case involving Apple that bears some resemblance involving iPods being artificially restricted to only playing tracks either from iTunes or direct CD rips.

So I think the anti-competitive angle has some real merit.

The innovation claim, though, I have a harder time with. I don't see how releasing Messages for Android implies design-by-committee. They could just release it, like Beeper Mini just did, but without the reverse engineering part.


They could definitely just release an app for Android instead of opening the protocol, but as an Android user I'd reject it for the same reason I reject my Apple friends suggesting we all use WhatsApp or Signal: I don't want different conversations living in different chat apps for no reason. That to me is the bad old days of Facebook Messenger+Twitter DMs+SMS where I had to remember which platform each of my contacts prefers to use and then deal with missing features and an inconsistent experience all the time.

As much as I think Beeper's work on iMessage is important, apps like that do not and have never solved this problem. Because then you have different contact identifiers to contend with, the inability to make groups amongst those users, differing features, and the list goes on.

If you look closely at what I'm saying here, it's easy to compare it to what iMessage users say about why Android users create problems for them, and that's true. That's why messaging interoperability is important.


Interestingly enough, in my life, WhatsApp has just won. Everyone I know uses it, people I meet when traveling use it. Pretty much every Airbnb host tries to contact me on WhatsApp. My physio right now in Malaysia organizes all my appointments on WhatsApp. But I only travel East of the UK, so Europe/Afria/Asia, I have no idea what South America is like, and can guess that it's not as ubiquitous in North America based on these threads.

I cannot remember the last time I've received a non-spam SMS. The whole iMessage thing feels so alien to me. My girlfriend is an Apple fan-girl and has never used iMessage in her life. I kinda wanted to see what was special about it and when I asked her about it, she had no idea what I was talking about.


Lack of competition has actually been shown to reduce innovation, not increase it. No one is asking them to do feature dev or even support for other platforms. They are asking them not to _shut out_ other platforms if others want to do the work.


Innovation is a good thing, but for many items on this list there's no more innovation happening. Google Cast and Airplay have been mostly unchanged for the last ten years, and the same is true for Airdrop and Nearby Share.

You can definitely make the argument about innovation in the messaging space, but RCS is very extensible. RCS Encryption definitely needs to be standardized, but I recommend you check out how Google layered it on top of RCS [1] including handling fallbacks for corner cases like switching your RCS client away from Google Messages before the system realizes it.

This is to say that RCS is pretty flexible, the key is handling the fallback paths in the extension design and working with other vendors to standardize promptly, so we don't end up with the same kind of broken mess that the carriers made.

[1] https://www.gstatic.com/messages/papers/messages_e2ee.pdf


They should just add a config option that says, "i use ai" which filters you off of leaderboards so you can still compete on your own personal boards without worrying about the global one


If you're logged in to the site, you can make a private leaderboard from the Leaderboard page.


Yes, but you still compete against global.


Can confirm. I wrote an OS library once for a thing. It started getting popular, then suddenly a large, well known project shipped an alternative solution (competitor?). It was the best thing ever to happen to my project. I got what I wanted (what my library aimed to solve) and no longer had to be the maintainer for that thing.


Agree, but init_subclass is new to python 3. It almost feels like OPs advice is based on old python and not modern python.


Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: