Hacker Newsnew | past | comments | ask | show | jobs | submit | werecat's commentslogin

Neat prototype. While the key layout is unfamiliar, I could definitely get used to this. The layout reminds me of old cell phone typing, where each number had a set of letters associated with it and you had to press multiple times to get the letter you wanted. I wonder if testers at the time got confused trying to type like that.


Yeah i had the same vibes and could definitely see a refined version of that being very quick to type on


The problem is there is no alternative to the App Store on iPhones. Epic Games couldn't open their own Epic Games App Store and sell their games there because Apple has a complete control over how apps can be used and sold on iPhones.


There doesn’t need to be an alternative App Store in iOS. There just need to be alternatives to iOS.

This whole “Apple have a monopoly inside their own product” is an absurd line of questioning when their product has anything but a monopoly. This argument is akin to saying that Disney has a monopoly on hotdog sales inside Disneyland and should be forced to allow competitors to open hotdog stands inside Disneyland.


> Apple have a monopoly inside their own product” is an absurd line of questioning

Didn't MS get into trouble for the exact same reasons, they were using their monopoly in the OS market to force Netscape out of business.


MSFT had a monopoly outside of their own product. This is my point. Windows had essentially 100% market share, whereas iOS has somewhere around 25% market share.


> whereas iOS has somewhere around 25% market share.

I dont think that is the point, Apple has 100% market share on its devices and its using its dominant position in that market to make that market anticompetitive (as per Epic)

Apple also has secret deals with other big companies where they can negotiate the commission Apple gets, apparently they did not give such treatment to Epic and other devs


> I dont think that is the point, Apple has 100% market share on its devices and its using its dominant position in that market to make that market anticompetitive (as per Epic)

No, it's exactly the point and was the catalyst for my comment. Apple sells a product. If you don't like it, buy something else. The only time that doesn't hold up is when there are not any practical alternatives (a la Windows) and thus the product (perhaps) satisfies the conditions for a monopoly.

> Apple also has secret deals with other big companies where they can negotiate the commission Apple gets, apparently they did not give such treatment to Epic and other devs

And? They're completely free to do this.


> No, it's exactly the point

I guess its upto the judge to decide that now whether they are abusing their dominant position or not.

> And? They're completely free to do this.

But then why lie about it, Cook said they have the same rules for everyone but then its revealed that they have secret deals with some others.


Microsoft got slapped for the anti-competitive behavior in the userland of their OS and they didn't even prevent installing the alternatives.


See my above comment:

> MSFT had a monopoly outside of their own product. This is my point. Windows had essentially 100% market share, whereas iOS has somewhere around 25% market share.


This is not a valid analogy.

I am not renting my phone from Apple, I own it. So when I am buying an instance of Disneyland, being able to install my own hotdog stands is a perfectly reasonable expectation.


True, but it doesn't make a situation unfair. It's just how it is.

The court shouldn't be able to change business models that you don't like.


Just because you may have a functional compiler running on a another architecture, doesn't mean the compiler actually outputs code FOR that architecture. The compiler would still only support the architectures it did when you bootstrapped it, which in that case would not include that specific architecture.


The Rust compiler is a cross-compiler by default, so the usual way that you bootstrap on a new platform is to add it to the existing compiler, and then cross-compile to the new architecture. Which is what I read your parent as suggesting.


The discussion is not about bootstrapping. Bootstrapping using mrustc on riscv64 would get you a working rust 1.19 compiler that runs on riscv64 and knows how to emit x86 code. It wouldn't even allow you to go up to the latest version. That's not very useful, Debian already has a rust compiler that emits x86, it needs a rust compiler that emits riscv64.


Right. They could add the riscv64 backend to the current compiler, and then cross-compile it from x86_64, meaning that the bootstrap chain for riscv64 would start at 1.37.0. No mrustc even needed.

That said, I feel like we may be talking past each other... what I'm saying is, to get support for riscv64, you don't need to do a full new bootstrap. Maybe I'm misunderstanding the point of the thread.


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

Search: