Apple Antitrust Probe – Responses to Congress [pdf] - <AUTHOR> https://docs.house.gov/meetings/JU/JU05/20190716/109793/HHRG-116-JU05-20190716-SD036.pdf <comment><USER3> Apple's answers repeatedly suggest that the reason they require third-party browsers to use WebKit and JavaScriptCore is for privacy and security:

> It is not our experience that competing web browsers have typically offered > enhanced privacy or security that would protect users as adequately as our > WebKit protections.

Google pioneered the out-of-process architecture that Safari now uses, developed the Safe Browsing program that Safari also uses, drove the adoption of HTTPS, put pressure on misbehaving certificate authorities and shepherded certificate pinning and then Certificate Transparency, and found many vulnerabilities in WebKit through security research that Apple was not itself doing.

Moreover, on the desktop, Chrome and Firefox both have automatic update channels that allow them to push out security fixes much more rapidly than Apple's heavy OS updates. (On iOS, they would be limited by Apple's App Store approval process.)

All this to say, I'm skeptical of the suggestion that a Blink-powered Chrome for iOS would not "protect users as adequately as our WebKit protections."

One thing to note: JavaScriptCore has special powers on iOS in that it can allocate new blocks of executable memory during just-in-time compilation, greatly improving its performance. A third-party JavaScript engine would be much slower without this ability, but granting the capability to third-party engines would jeopardize the security architecture of iOS.

<comment><USER4> Apple is plainly saying that they are best positioned to protect iOS users privacy and security. One way they do that is by not allowing any app to use anything other than WebKit. If there's a flaw in some alternative browser that iOS app developers now have a dependency on, Apple would be unable to do anything about it other than wait for that other browser vendor to ship an update.

>All this to say, I'm skeptical of the suggestion that a Blink-powered Chrome for iOS would not "protect users as adequately as our WebKit protections."

Maybe Google is excellent at updating their browser to address security issues, but Apple's concern isn't purely security. It's also privacy. And Safari's track record on privacy technologies is longer and better than everyone.

Furthermore, Apple sells integrated products. They don't sell operating systems, browsers, app stores, and NFC chips. They sell a finished good that incorporates all of those things and more. They take end to end responsibility for their products and it would be frankly uncharacteristic of Apple to have any other position than extreme self-reliance.

<comment><USER5> > Safari's track record on privacy technologies is longer and better than > everyone

Uhh... Mozilla Firefox anybody? If Apple cares about privacy so much then why don't they allow ad blockers on safari? I mean, even the Brave browser on iOS is better then Safari at blocking trackers and advertisements. Firefox also tells me how many trackers they have blocked and also give me the option to completely opt out of any telemetry data collection.

<comment><USER6> > why don't they allow ad blockers on safari?

They do. I am running Crystal right now on mobile Safari. I also have ad blockers on desktop Safari as well.

<comment><USER7> Safari has its problems: [https://github.com/el1t/uBlock- Safari/issues/158](https://github.com/el1t/uBlock-Safari/issues/158)

Though you can get some ad blockers which do less.

</comment></comment></comment></comment></comment><comment><USER8> > Why did Apple decide to build its own maps application rather than continue > to use Google Maps to power the maps applications on iPhones?

I don't get it: why hassle them over their underdog competitor? Laud them for daring to compete against the market leader. Focus the argument about the walled garden and right-to-repair instead.

Apple and Google should license the ability to create third-party app stores, or be compelled to do so. Perhaps that could come with terms on auditing apps and a process for resolving differences of opinion on whether an app is legitimate/safe/acceptable (with a standard like "poses a risk to device or owner's privacy/data").

<comment><USER9> > I don't get it: why hassle them over their underdog competitor? Laud them > for daring to compete against the market leader. Focus the argument about > the walled garden and right-to-repair instead.

Because they gave themselves an edge when competing against Google by not allowing Maps all of the same capabilities from start. And to do that, they abused their OS and store to block GMaps from having same capabilities as AMaps. Even today, GMaps isn't allowed to be the default maps provider.

No customer wishing for a healthy free market should approve of this.

<comment><USER10> That's not what happened. Google didn't allow Apple to use turn by turn directions without Apple giving Google more telemetry from its users.

<comment><USER11> That's also not what happened. I was on the Google Maps team at the time and the issues were far deeper and more problematic than "not getting telemetry" which was at any rate, not an issue - what sort of "telemetry" do you think a Maps app could report that isn't search queries or tile requests? Maps apps are just rendering frontends for giant server farms after all. Claiming it's about telemetry is just Apple propaganda.

The real problem was that Apple wrote the Google Maps app, and wasn't willing to cooperate with Google on it at all. Literally, they demanded some basic protocol specs and then wrote the app themselves. This led to several problems:

1\. They refused to tell Google what changes they were making to their app, which led to:

2\. Repeatedly screwing up their implementation in ways that very seriously threatened the stability of the entire Google Maps services (think: slamming the servers with way more traffic than any reasonable implementation should).

Apple love to claim the best results arise from integrating hardware, software and services. Well, guess what, that logic works in both directions: by preventing even basic cooperation between the Apple team writing the GMaps app, and the rest of the GMaps team, they created massive problems. Especially because at this time Apple engineering had no serious experience with large online services ... MobileMe was a disaster ... and so they kept making basic mistakes no Google team would ever make. They also refused Google's help to stop making them.

3\. The GMaps team was much larger and better funded than the iOS team, so iOS rapidly fell behind the featureset available on Android and the web. Google attempted to fix this by writing their own GMaps app, which Apple then _blocked_ on the grounds it was competitive with their own (this was back when they had this policy).

Basically the relationship was antagonistic from the start from Apple's side, and rapidly spiralled downhill as Google's own services accelerated away from what Apple was capable of.

The whole Apple schtick that Google was desperate to violate privacy or get telemetry is just an advertising attack angle: it shouldn't work on the sort of people who read Hacker News. Apple Maps is architecturally identical to Google Maps, after all.

<comment><USER12> I happen to know the other side of this. I get the impression from your post that we were probably looking at the same thing, just from very different angles. I think there were aspects to it that you either weren't privy to or just couldn't see from where you sat.

I don't think anyone involved in this from Apple still works there anymore, and it's been 10-11 years now so probably not even Apple itself really knows all the details at this point. From what I've heard the same may be true at Google; these stories are basically folklore to the current crop of the Maps team there.

In any case, as I recall it, advertising data and location tracking absolutely were sticking points. It's possible you weren't part of those aspects or you just saw it differently than Apple did.

On the other hand, this was all before Apple had a public marketing campaign around user privacy. The antagonism in the relationship around Maps also predated any discussion with Google of location data or ads and it arose from Android. Jobs saw Android as an attempt to copy the iPhone, and this lead to mistrust of Google in all things.

With that perspective, maybe you can start to see the other side of it. Apple didn't want to let slip any detail of upcoming iPhone features because the concern was about them being copied in Android. While the G Maps folks gave lip service initially to being separate from Android and the idea that features wouldn't be held back from Apple to benefit Android (and this was true initially, eg with Street View), Apple folks didn't believe that would last.

And I think it didn't last. As time went on, the Apple perspective was that Google was asking for things that were anathema, just so Google could point to them and say this is why you aren't getting vector data or nav, but only as a pretext in the larger war of being able to use Maps as a competitive advantage for Android.

<comment><USER11> Yes, that's all probably true. I didn't delve into the wider politics of the iPhone vs Android wars but that was certainly a part of the reason for Apple not working closer with the Maps team.

It's unfortunate that Android became something of a self-fulfilling prophecy in this regard. It was created largely because of the experience of Maps trying to make mobile clients in a fragmented space with poor APIs (J2ME, Symbian, etc). Then Apple effectively took over the frontends of Google's most important services and in many ways did it much worse than the Maps team themselves did, but the popularity of the iPhone rendered much of their work useless. Google didn't at that time care about phones with the same burning passion Jobs did: Android was first and foremost a strategic play. Many Googlers, even senior Googlers, were happy to be seen using and praising their iPhones. But the inverse was also true: Jobs didn't care about Maps with the same passion that Brin & Page did. It should have been possible to forge a genuine collaboration, there were certainly no technical barriers.

Unfortunately Jobs' bizarre and self-destructive belief that the iPhone should effectively never have serious competition put both companies on the path to ultimate divorce. Users are still feeling the effects of that today. His paranoia about other companies copying them was also misplaced: as far as Maps were concerned the problem was rather the opposite; Google wasn't copying Apple's features, Apple was copying Google's features, but only after much pressure and negotiation!

Apple also had a schizophrenic attitude to advertising: their total refusal to integrate ads into iOS Maps meant that Google was destined to bleed vast sums of money on mobile maps forever, and the more popular the iPhone became, the more money they'd bleed. This was no strong principle as Apple tried to launch its own ad network which sucked and was quickly forgotten about, so it looked a lot like some sort of psycho "revenge" for Android - a project which had been initiated before the iPhone project itself had. Jobs seemed to believe that the moment he announced the iPhone Android should have been cancelled and anyone not willing to pay his steep prices abandoned to J2ME feature phones for good.

Very, very few companies would be willing to tolerate another company totally controlling the entire user interface of their online service, blocking their only revenue stream and in an environment with almost no cooperation (i.e. Google would find out about what features Apple had added at about the same time everyone else did). Although it was understandable in the very first versions of their Maps app were written in house whilst the APIs and product were still baking, it became less and less tenable with time. Separate apps was the obvious way to resolve that problem, but Apple forbade that too.

If I recall correctly the straw that broke the camel's back was actually social. Google at the time was desperately concerned about Facebook. They worried that Facebook was an existential threat to the popularity of their services because Facebook had social features and Google didn't. So it tried to add social stuff to everything. This wasn't about Apple at all, it was all about Facebook, but Apple point-blank refused to add any social features to their app. I don't know why not, probably they felt it was a poor use of resources (which it would have been), but that was what triggered Google to write their own frontend app which then got banned.

Up until that point Android had been seen to a large extent as a way to drag the rest of the phone industry into the post-iPhone age, rather than something specifically designed to go after Apple. There was no shame in senior Googler executives using iPhones. But Google saw the fate of Maps as a sign of the dystopian future awaiting them, in a world where Jobs controlled access to users with an iron fist. After that Android was ramped up significantly. It was in my view a huge strategic error by Jobs. Very few companies were able to make software competitive with theirs: Google was basically the only one. If Apple hadn't blocked Google from upgrading its services, it's very plausible Android would have pivoted more strongly into the budget/low end space Apple didn't care about anyway. Social-in-maps put paid to that idea and resulted in Android becoming an OS that is a match for iOS in every respect.

<comment><USER10> _their total refusal to integrate ads into iOS Maps meant that Google was destined to bleed vast sums of money on mobile maps forever, and the more popular the iPhone became, the more money they 'd bleed._

Google wasn't giving Apple access to the Maps data for free. They were paying for it.

 _If Apple hadn 't blocked Google from upgrading its services, it's very plausible Android would have pivoted more strongly into the budget/low end space Apple didn't care about anyway. _

Android is in the budget/low end space. The average selling price of an Android phone is about 1/3 of an iPhone and Apple makes about 80% of the profit in mobile.

 _but that was what triggered Google to write their own frontend app which then got banned._

Google's app was never "banned". There were plenty of third party map apps when iOS 6 was introduced. iOS 6 was introduced in September 2012. Google Maps for iOS was released in December of 2012. Are you saying that Google wanted to release a separate maps app when Apple was still using Google maps before iOS 6?

<comment><USER11> _Android is in the budget /low end space._

Yes, and it's also in the high end iPhone competing space. We're not talking about prices here, we're talking about whether the devices have competitive specs and functionality.

Android dominates globally, even in the USA and on the top-end devices where Apple is strongest.

 _Are you saying that Google wanted to release a separate maps app when Apple was still using Google maps before iOS 6?_

Yes, long before. We're going way back here.

<comment><USER10> _We 're not talking about prices here, we're talking about whether the devices have competitive specs and functionality._

Not really, the majority of Android phones are slower than iPhones. In fact, it wasn't until 2018 that high end Samsung phones were faster in single core performance than the 2015 6S.

Android definitely doesn't "dominate" on the top end by any definition - <USER2> or profits.

Isn't it a Pyrrhic victory to sell millions of devices and make no money from them? Of course we have no way of knowing how the Chinese brands are doing.

 _Yes, long before. We 're going way back here._

There is an existence proof that this wasn't true. It wasn't until the 3GS/iOS 3 that Apple allowed any app to have real time turn by turn directions. There were plenty of third party Maps apps that had turn by turn directions by iOS 4 in 2010. So Apple explicitly banned Google but allowed other Maps apps?

<comment><USER11> You are incredibly sure you know more about this than me, despite the fact that I was there and saw it all unfold from the inside. Yes, Apple blocked Google's maps app. That's why when Latitude launched, it launched as a web app on iOS despite having a much inferior user experience to a native app.

As for people making no money off of Android phones, come on, are you serious? That's completely delusional iOS fandom: Samsung alone makes around $2.5 billion _a quarter_ off of their mobile division. The idea that Apple is the only one making mobile profits is bizarre and wrong, but also strange for another reason: why would _customers_ want Apple to make huge profits? That's good only for Apple shareholders and bad for iPhone users, who have (as far as I recall) never seen prices fall despite the actual hardware becoming massively cheaper. Someone is a sucker here, but it isn't anyone buying or selling Android phones!

</comment></comment></comment></comment></comment></comment></comment></comment></comment></comment><comment><USER13> > users have many alternative third-party browsers they can download from the > App Store.

This answer is misleading at best, bordering on lying. I define "browser" as inclusive of the engine used to render web pages.

<comment><USER14> To Apple's credit, they do talk about Webkit being the only engine a few questions later.

<comment><USER13> Only when forced in response to some very pointed questions. That doesn't make the first answer true if you understand that the engine is a vital part of a web browser and a source of competitive advantage.

<comment><USER15> > Only when forced to in response to some very pointed questions.

They weren't asked these questions one at a time.

<comment><USER13> They weren't, but they answered as if they were, not considering the obvious implications of the fourth question when answering the first.

<comment><USER16> No. Your definition of a browser is wrong, and is what leads to your conclusions.

</comment></comment></comment></comment></comment></comment><comment><USER17> Interesting non-answer:

>29\. For each year since 2009, what is the total amount that Apple has accepted from Google for the right to be the default search engine in Safari and in any other Apple products or services? Please identify the amount accepted from Google in total and broken down by each Apple product.

>Apple's search agreement with Google generates revenue based on referral traffic through the URL/search box on Apple's Safari browser. Although Google search is set as the default, this can be changed in settings on iPhone to another search engine, such as Yahoo!, Microsoft Bing and DuckDuckGo. Consumers may also conduct searches on search apps available through the App Store, searches performed on the web (through the search engine's web portal), or through virtual assistants like Siri, Cortana or Alexa that are available to users on our platform.

<comment><USER18> It's possible they gave different answers privately and requested for exact numbers not to be released publicly. Seems likely based on reading Amazon's reply to the same committee, which also didn't give specific numbers to some questions requesting specifics.

<comment><USER19> I'd imagine there's some complicated SEC-related reason why they can't provide specific numbers w.r.t revenue

</comment></comment></comment><comment><USER20> This is incorrect [1] - they block questions on independent repair from Apple forums.

> Does Apple take any actions to block consumers from seeking out or using > repair shops that offer a broader range of repairs than those offered by > authorized technicians? If yes, describe each action that Apple takes and > the reason for doing so.

Apple does not take any actions to block consumers from seeking out or using repair shops that offer a broader range of repairs than those offered by Apple's authorized technicians. Customers are free to obtain repairs from any repair shop of their choice.

[1] [https://www.cultofmac.com/620124/apple-support-forum- jessa-j...](https://www.cultofmac.com/620124/apple-support-forum-jessa-jones/)

<comment><USER21> Just a couple of months ago I called Apple to get my 2012 MacBook Air repaired. Apple wouldn't touch it because of its age, but gave me a list of independent repair shops in my area that would fix it.

If Apple blocks people from getting independent repairs, when why are there Apple authorized repair third-party repair shops?

<comment><USER22> Did you read the link in the comment you're replying to?

</comment></comment></comment><comment><USER17> Interesting that it starts off with the advantages Apple gives Safari, as similar browser issues were a focus of the antitrust proceedings against Microsoft.

<comment><USER23> In Microsoft's case, the free and privileged position of IE was specifically chosen to prevent the success of a competitor (Netscape) whose product created the potential for cross-platform applications (enterprise, early web applications). IE deliberately implemented some things counter to the specifications in order to be incompatible with the spec (and thus spec- conformant browsers) forcing developers to select their target platform. IE's substantial market position meant that more people supported it (thus all the sites that were IE-only, and some still are because banks and governments suck at IT). MS spent hundreds of millions (if not over a billion, it's been a while since I read the reports on the subject) to give away a product that would cripple a competitor's position. Netscape, though, wasn't the only target of MS's action. By doing this, they helped ensure Windows dominance would continue. Enterprises considering, or using, other operating systems but wanting to advance the state of their IT systems (that is, adopting web-based solutions) would find themselves in the same conundrum. Implement to the standards and use any OS, or implement to IE and support one OS that was already dominant within the corporation.

This worked to effectively reduce the potential market position (in businesses and for consumers) of alternate OSes to Windows.

Of course, that's not the only thing MS did. The full report of the anti-trust case was pretty interesting. There were many things MS did beyond _just_ the browser. They favored OEMs who exclusively sold Windows-based computers with lower OEM pricing, but if they attempted to use another OS then they were threatened with increased licensing costs (this was a large part of what killed BeOS's momentum).

While many people remember and focus on the browser, it was only one piece of the whole case. To draw a comparison, you'd need to demonstrate that Apple's Safari-only (or really Safari + limited WebKit-only) policy is taking advantage of its substantial market share (currently iOS is sitting at something like 55-57% market share in the US, so it isn't actually that substantial a lead) to harm its competitors. And you'd have to place that in the context of other abuses of market share position.

<comment><USER24> Forcing WebKit-only enables Apple to selectively disable key features in all browsers on iOS, preventing web apps from competing against FaceTime (WebRTC, Fullscreen API) or iMessages (Service Workers).

Instead they need to go through the App Store, driving up development costs (the Swift learning and/or contractors) and decreasing potential competition.

</comment></comment></comment><comment><USER25> > For each year since 2009, the costs of providing repair services has > exceeded the revenue generated by repairs.

Huh, that one kinda surprised me.

<comment><USER26> 2009 - 2012 would be the period where nVidia had badly-soldered GPUs affecting everyone's laptops, this was an expensive repair period for many manufacturers. Air bubbles in the solder would eventually disrupt the electrical flow, I think it was just the one year of devices but a year or so passed before anyone was affected.

[https://codingfreak.blogspot.com/2009/04/beware-of-nvidia- gr...](https://codingfreak.blogspot.com/2009/04/beware-of-nvidia-graphic- cards-in.html)

Then in 2013 Apple started soldering/joining everything which made all the repairs more expensive.

Then in 2016 Apple had to start paying for the artificially expensive repairs themselves because of the butterfly keyboard fiasco, popping speakers, broken display cables etc.

They probably really have lost money but they don't mention it's their own fault and at this point it's really just tied to the free keyboard replacement program which ends in 1 - 2 years for the worst-affected models.

<comment><USER27> It wasn't just Nvidia GPUs. The early 2011 MBP failures all had ATI GPUs.

</comment></comment></comment><comment><USER28> > WebKit is an open-source web engine that allows Apple to enable improvements > contributed by third parties. Instead of having to supply an entirely > separate browser engine (with the significant privacy and security issues > this creates), third parties can contribute relevant changes to the WebKit > project for incorporation into the WebKit engine.

All other big browser engines are open-source too, but let's not mention that bit.

</comment><comment><USER29> Apple should be punished for their nasty monopolistic behavior with banning competing browsers. MS didn't get away with doing even less than that in the past, so Apple for sure shouldn't either. They were running amok with this garbage for too long.

By banning competing browsers, Apple also has leverage on broader adoption of JavaScript features and related technologies which they oppose. For example they refuse to implement Media Source Extensions, which allows them to sabotage wider usage of DASH, because they are pushing their own HLS. If that's not an anti-competitive behavior punishable by anti-trust, what is?

</comment><comment><USER30> It is interesting to see Apple use the exact same line of defense that Microsoft did with IE back in the day: the browser is an integral part of the OS (leading to the infamous 'Ham Sandwich' quote [1]). Note also that Microsoft did allow full-stack competing browsers, whereas Apple does not.

[1] [http://community.seattletimes.nwsource.com/archive/?date=199...](http://community.seattletimes.nwsource.com/archive/?date=19980419&slug=2746018)

</comment><comment><USER31> > iPhone users cannot set another browser as the default browser. Safari is > one of the apps that Apple believes defines the core user experience on iOS, > with industry-leading security and privacy features. As noted in response to > Question 1, Safari is an "operating system app," like the Phone, Camera and > iMessage, which are designed to work together.

The third sentence does not follow from the first two, and does not answer the question.

> For each year since 2009, what is the total amount that Apple has accepted > from Google for the right to be the default search engine in Safari and in > any other Apple products or services? Please identify the amount accepted > from Google in total and broken down by each Apple product.

> Apple's search agreement with Google generates revenue based on referral > traffic through the URL/search box on Apple's Safari browser. Although > Google search is set as the default, this can be changed in settings on > iPhone to another search engine, such as Yahoo!, Microsoft Bing and > DuckDuckGo. Consumers may also conduct searches on search apps available > through the App Store, searches performed on the web (through the search > engine's web portal), or through virtual assistants like Siri, Cortana or > Alexa that are available to users on our platform.

I like how Apple answered exactly zero parts of this question :/

<comment><USER32> > Safari is one of the apps that Apple believes defines the core user > experience on iOS...

Is this not the same argument Microsoft made about Internet Explorer?

<comment><USER33> Well, I'd answer so much yes, but if we condemn them to the same penalty as Microsoft, it's gonna be 0.00.

Penalties were dropped I think in the wake of September 11, 2001.

</comment></comment></comment><comment><USER34> I'm currently dealing with the insanity of thinking about deploying my app on the app store.

The biggest challenge I have is the fact that I can't put a PWA (progress web app) in the app store.

Google allows you to do it in the play store. They even have a library (trusted web application) that you can use to bridge your web app to an android app and distribute it into the app store.

I DO appreciate that there are technical reasons why Apple and users would find this less than ideal but this is 90% due to apple being non-competitive.

I could even understand and have sympathy for Apple had a way to side-load 3rd party apps.

... but you can't even do that. Users have NO control over their phone and Apple has completely locked down the ecosystem.

They need to be broken up...

<comment><USER35> Don't really wanna bite, but you got me.

How would you even break up apple?

</comment></comment><comment><USER36> Apple seems to have given non-answers, or entirely avoided, several questions on here. Is this par for the course on probes, was information redacted, or are there going to be consequences for Apple here?

<comment><USER37> To my knowledge, this is Congress asking questions, not sending a subpeona. Participation at this stage is still voluntary, and mostly consists of political posturing.

If Congress wishes to pursue it, they have legal tools where cooperation is non-optional. The current conversation is part of the song-and-dance where Apple tries to avoid that by offering something resembling cooperation, but on their own terms. Many of the questions are meant to answer the question "if we conduct a probe for realsies, who will be the winner?" rather than the question-as-asked.

</comment></comment><comment><USER38> #7 is a little off IMO. Perhaps Apple does not earn revenue from the app itself, but it still earns revenue from the developer in the form of Dev License(s).

<comment><USER39> $99/year is not even a rounding error on their balance sheet though

<comment><USER40> But in the latest WWDC they announced they have 20 million licensed developer, 20.000.000 x 99 = 1.980.000.000 license fee.

ref : [https://techcrunch.com/2018/06/04/app-store- hits-20m-registe...](https://techcrunch.com/2018/06/04/app-store- hits-20m-registered-developers-at-100b-in-revenues-500m-visitors-per-week/)

<comment><USER41> Anyone can register an account on developer.apple.com, for free. I doubt there are 20 mil paid accounts for the developer portal.

</comment></comment></comment></comment><comment><USER11> I have to say I'm quite impressed by the quality and precision of the questions in this document. Who in Congress wrote this questionnaire?

</comment><comment><USER42> As someone with a business idea that is DOA on mobile without a browser extension (or ability to change OS default https handler to an extension- supporting browser), I really hope something comes of this.

</comment><comment><USER43> No employee non-compete? I'm surprised.

<comment><USER44> Non-compete is illegal in California.

<comment><USER31> Well, non-enforceable.

<comment><USER37> It's a relevant distinction. You're still allowed to put non-compete clauses into your contracts, even though they don't do anything. Many companies put such clauses in their contracts, either because they have a nation-wide template, or because the threat of litigation is valuable to them.

</comment></comment></comment></comment><comment><USER45> Apple's closed and exclusive ecosystem is a product in itself.

As long as users can choose different computers (PCs) and phones (Android) there is no monopoly problem.

<comment><USER42> You're right about the first. The argument can be made for the second, but many reasonable people disagree about bundling/preferential treatment being _anticompetitive_.

</comment></comment><comment><USER28> tldr; Apple does everything it does in the name of Privacy and Security, because users can only trust Apple and everything that's not Apple is a potential vector of attack.</comment>


App/Website that tracks and lists new and existing web apps? - <AUTHOR>

Is there an app out there that lists all the new apps coming out and perhaps allows you to see the ones most relevant to you by interest etc. The general reason for the question is that i get the feeling i'm missing a lot of apps out there that i could potentially use. <comment><USER2> <http://www.feedmyapp.com></comment>


Introduction to HyperCard, 1987 [video] - <AUTHOR> http://www.archive.org/details/CC501_hypercard

<comment><AUTHOR> HyperCard was mentioned here recently. Stumbled onto this old video while reading some of the history behind it. It was thought of as "Programming for the rest of us", and it's great to see how people embraced that idea.

<comment><USER2> It's still the holy grail, yet apart from Squeak and a few other initiatives, people have given up -- and I find that sad.

I'm working on something in this space. If you're interested, let me know: david 927 gmail dot com

<comment><AUTHOR> Squeak is really interesting, thanks for turning me on to it.</comment></comment></comment>


Slack Rules for Asynchronous Communication - <AUTHOR> https://great1on1s.com/blog/slack-rules-for-asynchronous-communication/ <comment><USER2> Most people in my company treat Slack as Asynchronous, unless it's something really important..and it's usually a phone call.

<comment><AUTHOR> That's great! It is surprising to find pockets where this isn't the norm in 2020, but I'm seeing it. I can remember working through this same issue in 2016 at a local Seattle startup.</comment></comment>


Rust, an Anti-Sloppy Programming Language - <AUTHOR> http://arthurtw.github.io/2014/12/21/rust-anti-sloppy-programming-language.html <comment><USER2> I've been writing a parser generator in rust as a way to learn the language, and it's been a mixed journey of being very impressed, and very frustrated. A large part of my frustration comes from what seems like a negative feedback between algebraic data types and the borrow checker. I often find myself with a piece of code that looks clean and simple, using the Option and Result monads to deal with errors in an elegant way, but then I can't compile it because of issues with borrowing. Ultimately, I usually have to break apart the nice structure that feels natural and reimplement it as either a sequence of match or "if x.is_ok()" statements, which just feels... wrong somehow. It becomes tempting to just punt on the error handling and call unwrap() on everything just to get it working for now, which leads to problems later on. It's _so close_ to being incredibly expressive _and_ great for systems programming, but it isn't quite all the way there (at least for me, at this point).

I think that higher-kinded types will probably help a lot with this if they make it into the language, and it's likely that there's a way to get around the errors and get the full benefit from the algebraic data types and monadic functions that I just haven't found yet. The language is enough of a level-up from my C++ days that I'm sure I'll stick to it, even if those things aren't true.

I thought this quote from the article really nailed it regarding my recent experience:

"Expressiveness or elegance is not a goal of Rust. It's certainly not bad in this regard, just not as wonderful as you may wish if you care it a lot."

<comment><USER3> Definitely one of the things that frustrates me about Rust, is that I feel like I can't write "pretty" code. Multiple times it was even the reason I gave up learning Rust. Clarification: I think my definition of pretty has come from a certain feel/comfort you have when reading Ruby code (which I have written/read for only a couple months).

Meanwhile, to continue learning Rust, I've done myself a favor. I just told myself: "Rust is worth writing but it isn't for pretty code. Sorry!".

The other, related, mental block I haven't been able to overcome yet: In Java/Python/Ruby/(even C++), the runtime "seems so heavy" I don't care when I "waste" allocations or memory. However, the fact that it says on Rust's home page "featuring zero cost abstractions" makes me feel guilty/incompetent every time I introduce a cost-full abstraction. Again a reason I stopped learning Rust a few times.

Sadly this feeling of inadequacy/guilt extends even to applications. Which is ridiculous since if your application isn't doing expensive things, you probably have a very simple application. This definitely plays a part in why I can't write code as elegant as Rust will allow it.

For the record, sorry, I don't usually like critiquing something I don't have a solution for. However, I thought this was worth bringing up. Mostly I needed to vent, but does anyone else feel similarly? Am I really the only one?

If other people are feeling the same way, I hope it doesn't become a habit for us to feel the only way to write good Rust is to allow it to be inelegant. It would be disheartening if the next systems programming language was memory safe but still noone enjoyed reading it. I'm curious what peoples thoughts are?

Mostly joking, but maybe just a line on the website or guide saying: "We take care of the performance so you can write expensive applications"?

<comment><USER4> Very interesting point and I also feel similar a need to "overoptimize" my code when I program something in C. This is specially notable when working with strings: In high level languages I use strings concatenation and splitting willy nilly but in C all those strcats and for loops "feel" suboptimal so I have a tendency to write hairy code full of pointers and strtok.

<comment><USER5> Developers are a strange bunch. I've never heard someone say, "Wow, look at that optimized code! I can't wait to work with this dude!". However, I have heard many times, "Working with this person is great. They do everything from expressive code, to small logical commits to make my life easier."

It's almost as if many of us would rather be seen as an elite, rather than seen as a pragmatic developer.

<comment><USER6> I usually just tell myself "bad code gets run". Optimizing string concatenations and the like is something I can do _after_ the code is done, doesn't leak, and has enough form that I can write function tests around it.

Its not something to do before.

</comment></comment></comment></comment></comment><comment><USER7> I haven't touched C or C++ in over 10 years as I've been living like a free spirit in the Perl world. I've always wanted to go closer to the metal, but Perl did everything I ever wanted. But I slowly started to feel that dynamic languages had kind of boxed me in, almost making me timid of memory management and handling resource allocation.

So I wanted to go deeper. I played with Go for a while, but kept an eye on Rust. However over the past couple of months, Rust just felt like they got it right. It made me care free about resources just like how Perl took care of everything, while being a strongly typed, static language with generics, and without the problems that might get in my way that Go has (GC and a heavy runtime).

If you still haven't had a look but are interested, take a look at the Rust Guide:

[http://doc.rust-lang.org/guide.html](http://doc.rust-lang.org/guide.html)

<comment><USER8> "Rust" was an interesting but slightly confusing language a year-ish ago, when it had chans and tasks and libuv and M:N threading and three kinds of pointers with their own funny symbol. That language, as far as I can tell, basically stopped existing (for lots of small good reasons that added up). Rust 1.0 will be an interesting head-on competitor to C/C++ without the awfulness of C/C++, which seems like a very different thing, and a thing I personally have more of a use case for.

I think, to some extent, this is why Rust keeps being compared with Go. Last year's "Rust" was definitely something that merited comparisons with goroutines and the like. Rust 1.0 is going out of its way to make sure that it can be used for writing dynamic libraries that can be called from C or any other language with an FFI, and is possibly easier than C++ for that use case. This is completely not doable in Go (I suspect that this goal is fundamentally incompatible with having goroutines or a similar built-in concurrency story). Go seems to be a good language, but it's addressing a very different use case from what Rust is (now) addressing.

<comment><USER9> _> I suspect that this goal is fundamentally incompatible with having goroutines or a similar built-in concurrency story_

Not really. Here's an example of writing shared libraries for C in Haskell:

[https://github.com/mietek/haskell-so- example](https://github.com/mietek/haskell-so-example)

<comment><USER10> The "called from C" case isn't the interesting one, even though it's what the grandparent mentioned. It's the "called from a scripting language" case. You can call Haskell or Ocaml or even Java code from within CPython or Matz Ruby. However, if you do this, you bring along an entirely different runtime system and memory layout. Usually this means that you face some very odd memory management bugs and lose any speed advantage you gain as soon as you have to marshal objects across the language boundary.

<comment><USER9> Interesting opinion. What are the applications?

<comment><USER11> One of the first production deployments of Rust is such an application: [https://www.skylight.io/](https://www.skylight.io/)

Their Ruby gem is actually written in Rust.

</comment></comment></comment></comment></comment></comment><comment><USER12> A big problem with Rust right now is that the documentation is awful. This has two implications. The less important one is that the language is harder to learn. The more important one is that there's no architectural document that prevents Rust from becoming a collection of features in search of an architecture. If you have to clearly explain in writing how something works, and the explanation is overly complex, that's an indication that simplifying the design may be necessary.

The basic concept of ownership in Rust is simple. Everything has either a single owner, or a reference counted cell as owner. Things which cross thread boundaries have a locked reference counted cell as owner. Temporary references to single-owner objects are allowed, but must have a shorter lifetime than the primary ownership, and this must be demonstrated by simple static analysis. That's straightforward.

Making those restrictions usable seems to require many features and much churn within the language. It's too soon to tell how this will come out. As I'm mentioned before, I'm bothered by the need for "unsafe" code in pure Rust that's not calling hardware or C code.

<comment><USER11> > A big problem with Rust right now is that the documentation is awful.

Could you get more specific for me, please? There's certainly much room for improvement, but I can't fix what I don't know about!

> If you have to clearly explain in writing how something works,

Are you aware of our RFC process? Changes _do_ have to have extensive, written explanations.

<comment><USER13> FWIW, I've found the Guide incredibly helpful, and in general found the docs very satisfying. (Although I do wish the pointers guide was more complete :) )

The API docs + search in the docs are incredible IMO. I'm in absolute love with rustdoc. Having links to the source right there is the most valuable thing ever, both when trying to understand how to use a given API, and when trying to write similar things its really useful to be able to look at how others have done things.

<comment><USER11> Awesome. I'll consider bumping up the Pointer Guide in my priorities.

</comment></comment></comment></comment><comment><USER14> The author's term "anti-sloppy programming" immediately brought to mind a former colleague's paper, aptly-titled "Sloppy Programming" [1]. Interestingly, Rust is a programming language, while this paper describes an editor/IDE enhancement to turn natural language style input into ASTs.

This suggests to me that the most anti-sloppy languages like Rust would benefit the most from sloppy input inference techniques. Has anyone been working on developer tools to make writing Rust code easier? (Lifetime management is the obvious new language feature to target.)

[1] [http://groups.csail.mit.edu/uid/other-pubs/sloppy- programmin...](http://groups.csail.mit.edu/uid/other-pubs/sloppy- programming.pdf) (pdf), or less-detailed: [http://groups.csail.mit.edu/uid/projects/keyword- commands/in...](http://groups.csail.mit.edu/uid/projects/keyword- commands/index.html)

<comment><USER15> > (Lifetime management is the obvious new language feature to target.)

If you haven't toyed with Rust since late summer when Lifetime elision[1] landed, it's very worth revisiting. That feature made writing out lifetime notations unnecessary in 87% of the standard library. It's made things a lot more pleasant. There's still plenty of room for IDEs and editors to help out, of course, but the language itself is making great strides in usability as it matures.

[1] [https://github.com/rust- lang/rfcs/blob/704f0060176418659698e...](https://github.com/rust- lang/rfcs/blob/704f0060176418659698eb63642e2071b109e029/active/0000-lifetime- elision.md)

<comment><USER14> Ah, great; thanks for pointing out that it has changed. The last time I looked at Rust in detail was mid-April, so I hadn't seen that.

<comment><USER16> As someone who wrote a lot of code _not_ in the standard library, I championed this RFC pretty heavily. Part of the reason is that I noticed that with the lifetime elision rules, code _using_ abstractions (as opposed to the implementation of abstractions) tends to use even fewer lifetime annotations.

Incidentally, the 87% number is a bit misleading. Before the Lifetime Elision RFC, a limited kind of elision was already allowed (when a function borrowed a value but didn't return a borrowed value). The 87% number was the number of lifetime annotations that were still required even with that limited rule that could be removed with the new rule. When taking all kinds of elision into consideration, the number _in the standard library_ is closer to 95%. (many of the remaining cases in the standard library involve the implementation of collections)

In practice, that means that the vast, vast majority of borrowed references don't require explicit lifetime annotations, and that is pretty close to 100% in "application" code built on top of abstractions.

</comment></comment></comment></comment><comment><USER17> Since rust is a true systems programming language, without a mandatory GC, I wonder if there will be any serious attempt to build a kernel entirely in Rust? It certainly sounds possible, and I suspect it would quickly be better than any FOSS kernel currently available, given the fact that Rust is so well designed against bad or sloppy code. Perhaps I'm just talking out of my ass here, but it sounds like a good idea.

<comment><USER18> There's already a high performance, formally verified, "FLOSS" microkernel: [http://sel4.systems/](http://sel4.systems/)

As it turns out, very few people are interested in having software that works.

<comment><USER19> I call BS.

The reason very few people care is that "works" is not a binary, but obviously a continium -- and people inherently understand diminishing returns...

Especially when the "works" they care about is getting shit done, by having access to software (including proprietary), drivers, a community, vendors, etc.

The "is formally verified" they could not care less, and rightly so, if their other demands are not satisfied...

<comment><USER12> That L4 kernel is in the air link CPU of most cell phones.

<comment><USER19> Nice that it found a niche there.

That's however orthogonal to what I wrote, I think.

It's not like it has a software ecosystem, community, drivers, etc, to be adopted over any major OSes as something that "all others being equal" is also "formally verified".

</comment></comment></comment></comment></comment><comment><USER20> The quickest comparison I'd say between choosing Rust and Go is:

\- if you like C or Python, you will probably prefer Go

\- if you like C++ with templates or D or Ruby (especially Rails), you will probably prefer Rust

We will see how the languages evolve, but so far I really enjoy Go having native channels, having a stable language definition, and a simple yet stable and powerful standard language API. Also the public/private access system based on capitalization is genius, and the package management is very intuitive.

<comment><USER21> If you "like C", then Go is a really poor substitute, because Go doesn't allow one to juggle with memory like what people are normally doing in C. Rust is not comparable with Go, because Go relies on a non-optional GC, a difference that changes everything, Go being in the same league as the JVM, except that the JVM is better at almost everything, like garbage collectors, tools and libraries available, multiple languages etc. The JVM is even better at concurrency.

Go in my opinion is the best proof that our industry is fashion driven.

<comment><USER22> >Go in my opinion is the best proof that our industry is fashion driven.

It's not though. What is fashionable about Go? Most testimonies I've seen state solid reasons for choosing it. Nobody claims it to be a marvelous language like Haskell. It's a simple language that's easy to pick up, implement an idea, and deploy. Much like python, but with much greater performance.

I don't see what fashion has to do with it.

<comment><USER23> OCaml offered the same proposition for 10+ years. No-one was interested. Oddly enough, now that Go and Rust are getting attention, people seem to also be taking a second look at OCaml. What's that, if not fashion?

<comment><USER24> "OCaml offered the same proposition for 10+ years."

No, it didn't. In addition to the already-observed point that Go's concurrency story has always been better than OCaml's, Go also offers it to you in an Algol-esque syntax. It isn't C, but if you know C the differences are dialectal, whereas OCaml is from the ML tradition and is radically different. ML is the language family probably most distant from C in current medium-scale usage.

I don't like or celebrate this fact, but it seems that broad-scale success right now _requires_ that you be an Algol-descended syntax.

<comment><USER25> Allow me to summarize your post as "OCaml syntax is not and never was fashionable", thus proving the OP's point :)

</comment></comment></comment></comment></comment></comment><comment><USER26> One thing the dynamic language (and Go, to some extent) comparison misses is speed: in general, Rust code is likely to be faster to execute than the equivalent Perl/Python/Ruby/Go, due to performance being a strong design choice of the language, and the use of the industrial strength LLVM optimiser.

This is a general statement, it's not always true; but the control Rust provides theoretically means one can always wrangle the Rust code to be equal to/faster than most other languages.

(In fact, the embeddability of Rust means it is pretty well suited to writing the parts of a Python/etc application that need performance, since Rust can easily make dynamic libraries which can be loaded as extension modules.)

</comment><comment><USER27> Rust is probably the best programming language I will never use. Most of the chances I get to experiment with new languages is in small and/or personal projects. None of those projects ever benefit from manual memory management so the main selling point of Rust (safe memory management without GC) is actually just a hindrance.

<comment><USER28> I'm sure Rust will be adapted to various boards for enthusiasts as soon as stable version appears and it will be suitable for small personal projects. There even have been some tries[1] and Zinc still looks pretty active[2].

1\. [https://news.ycombinator.com/item?id=8035293](https://news.ycombinator.com/item?id=8035293) 2\. [https://github.com/hackndev/zinc/graphs/commit- activity](https://github.com/hackndev/zinc/graphs/commit-activity)

</comment></comment><comment><USER29> Good post. I haven't coded C++ for like 3 years so Rust is a very new concept to me (I am a Python programmer). This weekend I spent some hours to build a hangman game: [https://github.com/mauricioabreu/hangman](https://github.com/mauricioabreu/hangman)

</comment><comment><USER30> I've been wanting to mess with Rust for webapps. But I've been wondering on how it performs with a lot of async operations. Is the idea that you write CPU heavy code in Rust then call the compiled blob in say a node.js app, or is the end goal to one day compete with node.js?

<comment><USER31> Async I/O is still an open question in Rust. Over the next year I expect third-party libraries to experiment heavily in this space, which will hopefully blaze a trail for a blessed solution to be uplifted into the stdlib at some point (or if not a complete solution, at least the infrastructure to make it reasonable).

</comment></comment><comment><USER32> Did anyone else find Rust's package/module management kind of, well, sloppy? Perhaps coming from Rubygems and `go get` has made me spoiled. (And npm, and Cocoapods, and pip...)

<comment><USER26> Have you used cargo and crates.io? It is effectively the systems-language successor of Ruby's bundler (designed and (initially) built by the same people), but also paying attention to lessons learnt in npm and Go etc.

<comment><USER32> Yes, that's what I used—however, I just realized I may have been conflating the difficulty of doing package management in Rust with some packages that I used that were enormously difficult to use or were outdated (speaks to the pre-1.0 thing, I suppose).

</comment></comment></comment><comment><USER33> Since the ownership system and borrow checker are tuted as new, wouldn't a few papers been appropriate? Sure would be fit to document development outside of the community.

<comment><USER11> [https://github.com/rust-lang/rust/wiki/Note- research](https://github.com/rust-lang/rust/wiki/Note-research)

(There is also at least one recent paper on Rust which is t linked here.)

</comment></comment><comment><USER34> Does Rust have anything like Python generators or coroutines? I don't even know if its possible on a strongly typed laguage, but it's a killer feature form me.

<comment><USER16> I would be very surprised if something like C# and ES7's `async/await` syntax doesn't land in Rust after 1.0.

<comment><USER35> It can be difficult to implement well on _nix systems. async /await works so well in C# because IOCP in Windows is completion based. I/O on current _nix OSes is readiness based (epool/kqueue).

I implemented a completion based wrapper ontop of libev and libaio in C but could never quite nail it.

It's worth mentioning that IOCP can be used on any fd in Windows, whereas Linux epoll loop can only be used for sockets. There is a caveat to that however, you can use the epoll loop if you use eventfd with some effectively undocumented behavior of the aio subsystem that allows you to register an eventfd with your aio context. There are drawbacks to this though, you have to use O_DIRECT and aligned writes. In Windows you can use IOCP to do async buffered writes...

Thankfully much smarter people work on Rust and hopefully they manage to make a completion based IO system that is portable across the operating systems.

<comment><USER4> I don't see why the IO model would be a fundamental issue here. Fundamentally, async/await is about automating inversion of control, which is a mechanical program transformation.

<comment><USER35> Unfortunately most of what you want to do with await/async is IO based, the IO model matters a lot if you want it to be scalable. Without kernel support trying to build a completion based API is not very performant. Trying to emulate it in a library proved painful, especially when trying to do IO on files.

<comment><USER36> I'm not sure that's true. The same kind of mechanical transformation that gives await/async also leads to Python-style generator functions, and I wind up using them all the time for all kinds of iteration tasks, not just I/O (or at least, not just async I/O).

<comment><USER37> You're conflating two distinct concepts.

Certainly, code rewriting to support continuation is a factor in both C#-style await and generator functions, but they are not the same thing.

Much of the motivation behind async I/O is to reduce the number of active threads blocked on I/O. Blocked threads means stack space consumed, kernel transitions, and potentially CPU contention if too many threads become runnable at once, and then start fighting over mutexes or cache.

In this way of looking at the world, you don't want to _block_ for any I/O. That's what the GP is getting at.

</comment></comment></comment></comment></comment></comment></comment><comment><USER38> Can anybody explain in simple terms how Rust can manage cycled memory, without a garbage collector?

<comment><USER39> You'll have to work hard to manage to create a cycle in the first place, regular ownership through a value or a Box<T> will not allow it. You can create cycles (that need to be broken manually) with the reference counted smart pointer Rc<T>, or you use its weak pointers to resolve it automatically.

Oh, and datastructures that need cycles (the libstd's doubly linked list, for example), can use raw pointers to manage it manually, encapsulated in the implementation.

</comment></comment><comment><USER40> i just want to know if i can call a web json api with the stdlib :(

<comment><USER11> HTTP client / server is out of scope for the stdlib. Just add one line to your Cargo.toml and you're good to go, though.

</comment></comment><comment><USER41> any valuable starting tutorial for c/c++ programmers ?

<comment><USER12> [https://github.com/rust-lang/rust/wiki/Rust-for-CXX- programm...](https://github.com/rust-lang/rust/wiki/Rust-for-CXX-programmers)

There's also [http://featherweightmusings.blogspot.com/2014/04/rust- for-c-...](http://featherweightmusings.blogspot.com/2014/04/rust-for-c- programmers-part-1-hello.html) which is longer, but not as useful.

Rust has roughly the feature set and memory model of C++. The difference is that in Rust, the safety issues C++ sweeps under the rug are addressed. As I point out occasionally, the three big problems in C/C++ are "who owns it", "how big it it", and "who locks it". C fails to deal with any of those issues. C++ sometimes deals with "how big is it". Rust deals with all of them.

In Rust you have to deal with most of the memory management headaches you have in C++, but they're detected at compile time, not after the product ships.

<comment><USER42> How likely is it that a future version of c++ would tackle this issues?

<comment><USER11> It's impossible to address 100% in C++ without breaking backwards compatibility. "Modern C++" is significantly more safe, but still isn't completely safe.</comment></comment></comment></comment>


Why did John McCarthy "discover" lisp? - <AUTHOR>

Why do people say that he "discovered" lisp instead of "invented"? Am I missing something? <comment><USER2> >Am I missing something?

Yes.

Consider the parentheses in an s-expression.

(function foo bar)

The s-expression is a universal structure that can be used for every construct in a lisp. Notice that the core structure is not changed if we replace the parentheses with say, semi-colons.

;function foo bar;

The core of the concept remains the same. McCarthy's discovery is classed as such because as a construct s-expressions can be crafted from any set of symbols.[0]

[0]: This statement is probably false in more ways than one, that still doesn't damage my point.

</comment><comment><USER3> John McCarthy himself said,

"Pure Lisp was a discovery, everything that has been done with it since has been an invention."

McCarthy said this while visiting a class at Stanford on May 7 2008 --- according to an eyewitness report here on Hacker News!

<https://news.ycombinator.com/item?id=185348>

</comment><comment><USER4> The more general question is _"Why is mathematics said to be discovered, rather than invented."_ People can, and have, written full-fledged papers about this.

Suffice it to say though, that Lisp is said to be discovered because that is the terminology typically used with things in mathematics.

<comment><USER5> It would be strange to claim to have invented something that already existed, but whose status exists only because people were unaware of it prior. People did not say that they invented gold when it was discovered for instance.

<comment><USER6> In latin, discoverer is translated as inventor. They means the same thing. In French, somebody discovering a treasure can be called "l'inventeur du trésor".

</comment></comment></comment><comment><USER7> Lisp is an expression of the Lambda Calculus (<http://en.wikipedia.org/wiki/Lambda_calculus>).

And here's an interesting discussion that should answer your question: <http://www.quora.com/Do-aliens-have-LISP></comment>


The Downfall of Agile Hitler - <AUTHOR> http://www.noscetipsum.com/blog/2009/12/16/the-downfall-of-agile-hitler/

<comment><USER2> This video describes our company using agile... in fact I thought that I was outside the office of an iteration planning.

</comment><comment><USER3> This reminds me of routergod: <http://www.routergod.com/>

Fake celebrity essays/interviews about technical topics.

<comment><USER4> It's just too bad that routergod stopped updating years ago.

</comment></comment><comment><USER5> Oh god, not another one.

<comment><AUTHOR> Yeah, I thought this at first too. But in my case I never came accross one that ring a bell that much to me, I thought I would share :)

<comment><USER5> Meh, it's just as good or bad as the other 100 that are identical but covering a different topic. This meme is seriously worn out.

</comment></comment></comment><comment><USER6> Is anyone else getting tired of this meme?

<comment><USER7> I've seen better instances than this one (like the EFF's DMCA takedown Hitler[1]) ... but ... there's more to this meme than it simply being Hitler.

It's like the Looney Tunes coyote-vs-roadrunner. Honestly, how entertaining is it to watch the same highway through the desert, inhabited only by two non- verbal animals? Very. I think it's the constraints that make it fun. It was probably a lot of fun to write for, too...

The Hitler Downfall meme is fun because of the constraints, so try to appreciate people's remixes in that light.

[1] <http://www.youtube.com/watch?v=PzUoWkbNLe8>

<comment><USER6> Funny, I always hated the Roadrunner cartoons, and for the same reason: It was the same blasted joke told over and over again with slight variations. As if those would make it funny again.

<comment><USER7> :) Well, it grew on me. I didn't like it as a kid, even though that's who (I assume) it was originally targeting. I think I saw it as a series of bad things happening to the Coyote.

Now, I really like the cartoon because of the way the writers examined every situation, then interrupted the apparent inevitability of the scenario by finding a clever, ironic, and appropriate way for the scenario to unwind unexpectedly.</comment></comment></comment></comment>


Kiss Linux – A distribution with a focus on less is more - <AUTHOR> http://k1ss.org <comment><USER2> I loved the idea (git everything!) until I read this:

"How do I remove a package and all of its dependencies? [...] The package manager does not do recursive dependency removal on removal of a package. This error-prone automation will not be added to the package manager. "

<comment><USER3> This might seem like a limitation. But you can provide a base system with a toolchain & xorg with known dependencies and a limited set of packages (like a BSD base system). Then for every big and complex app clone that base system and build the app in a chroot/sandbox or container. That way you get the app and dont pollute the base system and uninstalling is just rm -rf

On every distro uninstalling packages never really reverts the system to its previous state, always leaves some junk behind.

<comment><USER4> Isn't this basically what Docker is for?

<comment><USER5> Yes in that it's container tech, but for servers. Snap is the equivalent for desktop. Both have their merits.

</comment></comment></comment></comment><comment><USER6> > The distribution targets only the x86-64 __architecture and the English > language.

Deal breaker for me. But the author should be commended for stating it up front. Far to often, only the benefits are presented but none of the flaws so you have to investigate new tech deeply to find out if it is right for you.

<comment><USER7> Seriously? There's a link "Ports (non-x86-64)" in the side bar.

[https://k1ss.org/ports](https://k1ss.org/ports)

<comment><USER8> Sorry, but to use the port for the PineBook pro on a RPI4, NanoPI, Odroid, Beaglebone, whichever ARM else _YOU_ are the porter. Which may be simpler, because _K1SS_ , but it isn't readily available...

<comment><USER7> Well, I have Radxa Rock(RK3188) and no distro supports it. With ARM "YOU are the porter" is right for many other distros, except some very popular boards. Even O-Droid's support vary between the boards.

</comment></comment></comment></comment><comment><USER9> My 2¢. (1) When I wanted simplicity and rolling releases / bleeding edge, I found Void Linux, which is indeed very minimal. It does proper package management, though, and can remove orphans. (2) An even more minimal Linux "distro" based on git and tup was discussed back in the day: [https://news.ycombinator.com/item?id=16015105](https://news.ycombinator.com/item?id=16015105)

<comment><USER10> Void is a breath of fresh air for anyone who is fed up with the mission creep of systemd but it's also a great distribution in its own right.

I'm not familiar enough with the internals of XBPS to compare it with apt or yum or pacman, but it seems to work quite well.

I have also found the community around Void to be quite welcoming.

</comment></comment><comment><USER11> I applaud your efforts, and am happy to see more options available. I really hope this takes off. Your choice to not include systemd is a HUGE incentive for me to try this out.

1 super-small nit to pick: the sub-title "..a focus on less is more.." I took that way too literally and thought it was referencing the tool `less` and was expecting it to have used less as a wrapper for everything. (call it a brain fart, and lack of caffeine)

I FUCKING LOVE YOUR WEB PAGE.

Thank-you so fucking much for reminding people and showing that simple is beautiful. Everything is clear, obvious and legible.

<comment><USER12> On most systems these days, 'less' _is_ more:

      % cksum `which less` `which more`
      2677110273 146976 /usr/bin/less
      2677110273 146976 /usr/bin/more

<comment><USER13> I think that more is symlinked to less on your system, not the other way around. On my machine (Arch), they're separate:

      jack@jackdesktop ~ [1]> bash -c "cksum `which less` `which more`"
      3407085100 179664 /usr/bin/less
      110370394 38816 /usr/bin/more
      jack@jackdesktop ~>

<comment><USER12> OK, now you've prompted me to do proper research:

Not a symlink (or even a hard link) on my OS X laptop, but the same executable.

On my OpenBSD systems, they're hard links.

On my Ubuntu system, they're separate.

<comment><USER13> Interesting! I wonder what the historical reason is for all of those different permutations.

</comment></comment></comment></comment></comment><comment><USER14> > Uses a package manager written in less than 1000 lines of POSIX sh > (excluding blank lines and comments).

Enough to get 20 bugs :-). I wish there was a good standard alternative to bash (sh in this case) for shell programming.

Otherwise I like the spirit, it's a good match with collapse os ;-)

<comment><USER15> > I wish there was a good standard alternative to bash (sh in this case) for > shell programming.

I would say Tcl!

Tcl is one of the most underrated programming language that everybody probably has installed. It has existed for as long as ksh and even long before bash. It is simple and powerful enough that first version of Redis were written in it[1].

MacPorts is written in Tcl (including its ports DSL) and I enjoyed every moment working with it.

[1]: [https://gist.github.com/antirez/6ca04dd191bdb82aad9fb241013e...](https://gist.github.com/antirez/6ca04dd191bdb82aad9fb241013e88a8)

<comment><USER16> Agreed 100% with this. TCL is a super cool language IMO. It's mature, unixy, and has minimal external dependencies. The ecosystem is stable and slow moving. I would encourage anybody to try it out!

The syntax takes some adjustment because it's not lval/rval-based, which is maybe why it's not so widely used now. But if you want a language that's more robust than shell and more minimal than Python, consider TCL for your next project.

</comment></comment></comment><comment><USER17> This is brilliant. I also love the testimonials here: [https://k1ss.org/testimonials](https://k1ss.org/testimonials) because they pretty much capture the entire Linux community of developers.

But if you contextualize it a bit differently I think you might find it is super valuable.

One of the challenges the Linux community has is that there are so many distributions or 'distros' to choose from. What is more, the feature sets of those distros form a non-planar non-directed graph of nodes for which it is very very difficult to reason about their feature content.

Consider for the moment if you could reason about distros like you can reason about genomes. In modern genetics we can look at flora, fauna, bacteria, etc and talk about them as a base class "foo" with specific genetic changes that get them to be a "bar", we can talk about speciation where the genetics are different enough such that hybrids are infertile or impossible.

This effort tries, and I think largely succeeds, in capturing the "minimum viable Linux _system_ " (all up kernel + user land). It gives you a way to reason about two different distros like

Ubuntu is Kiss plus (list of things) and for each item in the list of things, it has dependencies, recursively until you have completely described the genome of Ubuntu as a linear directed graph from Kiss. You could do the same thing for Fedora, or Mint, or any distro.

Two such graphs could give you a complete list of differences to get from distro <a> to distro <b> and the simple algorithm of walk back (remove items) from <a>, then walk down the graph (add items) to <b> would always "work" because they all share a common ancestor node, Kiss.

As a software developer you could reason about all of the changes to a distro you would need for your software to work, and this would tell you if those changes included removing something that was part of the canonical set of things in a distro, your software would not work on that distro.

Today, individual package managers do this in a distro unique way and let you work on one distro. As a software developer you end up with the "Fedora/Redhat" version, the "Ubuntu/Debian" version, maybe the "Arch/Gentoo" version.

But if the Linux community settled on a common understanding of the "genetic code" if you will, you could do that for _all possible_ distributions. That would be a powerful thing.

</comment><comment><USER18> I enjoyed reading the list of explicitly excluded software. My current approach to installing linux on a laptop is to start with xubuntu, add dwm, and remove the desktop, ibus, pulseaudio, and a bunch of other stuff. I discovered that Firefox will not play sound without pulseaudio! My next project is removing dbus, but many things on the system seem to depend on it. I think linux is a beautiful thing, but the mainstream distributions are messes of competing, redundant subsystems and massively bloated interface layers that do very little except make the system less reliable, slow, and hard to configure.

<comment><USER19> There's a package called apulse, that tricks programs into thinking they are talking to PulseAudio while piping stuff internally to ALSA.

[https://github.com/i-rinat/apulse](https://github.com/i-rinat/apulse)

<comment><USER18> Amazing, thank you so much!

</comment></comment></comment><comment><USER20> 1000 lines of shell is about 900 lines too many for "simple".

<comment><USER21> As opposed to?

This just sounds like dumb shell hate.

I personally would have used another language, but shell ain't that hard if you have some experience with it, and are using shellcheck as the author does.

The config formats of the distro are optimized for command line tools, and writing the package manager in shell seems like a good way to ensure that this is indeed the case - basic dogfooding.

<comment><USER20> As opposed to programming languages with constructs that allow proper code hygiene. That implies an actual type system, a usable standard library, etc.

Shell is _great_ for scripting usage of other programs, far better than other programming languages. That's what it's made for, after all. It's the _only_ thing it's made for.

</comment></comment></comment><comment><USER22> I do appreciate how they don't even have a backend for the website (though saying that, I'm not sure why most Linux distributions would require a full backend for their website)

<comment><USER23> It's an operating system distribution... why bother with how its documentation is served

<comment><USER24> Because it reflects how the writers solve problems. They needed a website. Did they spin up a docker container of wordpress, install a theme and some plugins until it looked the way they wanted, and write content in an in-browser WYSIWYG editor? Or did they write their content as HTML, and copy it to a server running HTTPD? Those two solutions represent different values, different philosophies, about how to use computers. It is good to see that the author's website-building approach is consistent with their operating-system- building approach. It lends credibility to the sincerity of the project.

<comment><USER23> No, it primarily reflects the problems. For example, the Gentoo and Arch Linux run MediaWiki. Does this tell you something about their "values or philosophies about how to use computers"? No, a static site generator would simply not be practical for either project. What renders documentation HTML in the background tells nothing about either project's approach to operating system development.

</comment></comment></comment></comment><comment><USER25> > Explicitly excludes the following software: wayland

I find it curious that a distro espousing simplicity would choose XOrg over Wayland (which was created to resolve problems arising from unnecessary complexity in XOrg). It looks like this is 80% simplicity and 20% sentimentality. I don't use wayland myself, but simplicity is certainly not a factor in that decision.

<comment><USER26> Wayland strikes me as the "shiny new thing" that is not ready for widescale use. If I was designing a distro and could only choose one I would choose X unless it was specifically a distro for shiny things that break.

<comment><USER25> I think that's a completely fair reason to avoid wayland, there are many of them. Complexity just doesn't seem like one of them.

</comment></comment></comment><comment><USER27> Well all I can say is grandma won't be installing kiss any time soon, looking at the instructions.

<comment><USER28> Grandma programmed in COBOL ([https://timeline.com/women-pioneered-computer- programming-th...](https://timeline.com/women-pioneered-computer-programming- then-men-took-their-industry-over-c2959b822523)) and lisp ([https://www.gnu.org/gnu/rms-lisp.html](https://www.gnu.org/gnu/rms- lisp.html)). Don't be so condescending.

<comment><USER29> Straight to the tribal, political realm. What do you expect to change? Should we say "Grandpa" instead? Should we try to include the experiences of everyone to a point where common sayings or one off phrases must be dissected for malicious intent? Come on

<comment><USER30> The reason why I _must_ die lies in music and long toes; I simply do not comprehend many people anymore in these areas. When I was young, and yes, this is a while ago, we had real men and real women and I do understand that was way too binary but the pussyfooting around _everything_ really goes way too far. That is me and as such I have to go before I do not understand anything anymore. I cannot believe people who want to be immortal will not go clinically insane by the weirdness that they see, decade after decade.

<comment><USER31> You can always move to a more conservative society. I live right on the other side of the globe and look at what's happening in the US with its fifty genders and SJW harassment for using the word "he" as pure lunacy.

There are other, much more serious problems over here, of course.

<comment><USER30> I live in Portugal (moved from Spain) and yes, that is true on both counts. I find it difficult to live with people who get upset over everything though. I would would say 'grow a pair' but that would not be correct... My grandfather says 'if you survived through a real war you would not care about this crap', but that would not be correct (and I think that's a bit over the top, but he survived 2 world wars)...

</comment></comment></comment></comment></comment></comment><comment><USER32> Me, out loud: "Awwww! What _cute site!_ " I am not ashamed.

It's like a lil mini _haiku_ OS (not to be confused with _HaikuOS_ the open BeOS).

\- - - -

Ooo!

[https://github.com/michaelforney/samurai](https://github.com/michaelforney/samurai)

> samurai is a ninja-compatible build tool written in C99 with a focus on > simplicity, speed, and portability.

</comment><comment><USER33> 30 years ago, trying out the distribution of the month was kind of cool, nowadays they just contribute to the endless fragmentation of GNU/Linux ecosystem.

I bet that during high time of UNIX wars no imagined it could get even worse.

<comment><USER34> I can assure you that it's not worse. There are only two or three distributions that are credible at the corporate level, and they are far more similar than the major Unix wars platforms.

</comment></comment><comment><USER35> Can you run Docker and systemd on it?

<comment><USER36> Possibly. If they don't rely on glibc, since KISS uses musl. Besides, why would you? They go against the fundamentals KISS.

<comment><USER37> > Besides, why would you?

Turns out less is indeed less.

</comment></comment></comment><comment><USER38> Been a while since I've used a Linux distro, let alone one that focused on being basic, but it feels like there is a lot of overlap with what Slackware was last time I used it. To me the whole point of "Simple" is to make the system comprehendible and Slackware did a very good job of that.

(Or for that matter, given the functionality presented here, I think OpenBSD as well)

</comment><comment><USER39> * init

* repo

* community

* kiss

[https://github.com/kisslinux/](https://github.com/kisslinux/)

Which package is the Linux kernel build stuff related? I recently wanted to bundle a quick Alpine install into a shareable `qemu` image. I couldn't figure out how to add a simple kernel module that was not included in the stock config. I would love to get this problem solved.

</comment><comment><USER40> Firefox ALSA backend is no longer supported [0], disabled by default (--enable-alsa), not deprecated yet [1]. Need to fix while we can.

Hope you enabled Telemetry [2], bonus - it produces nice graphs [3].

[0] [https://bugzilla.mozilla.org/show_bug.cgi?id=1345661](https://bugzilla.mozilla.org/show_bug.cgi?id=1345661)

[1] [https://github.com/kinetiknz/cubeb/wiki/Backend- Support](https://github.com/kinetiknz/cubeb/wiki/Backend-Support)

[2] about:telemetry

[3] [https://data.firefox.com/](https://data.firefox.com/)

</comment><comment><USER41> Groan. Yet another distribution that fragments the scene with custom _everything_.

<comment><USER42> The more systemd free alternatives, the better.

<comment><USER43> Curious, what alternative do you use and why? I'm just trying to understand the dislike for systemd

<comment><USER42> Depends on the distro but mostly OpenRC, SysVinit and Runit. I find that every one of them is better than systemd. The design philosophy of systemd also goes against everything I stand for.

</comment></comment></comment></comment><comment><USER43> I'm not familiar with Kiss but it looks interesting; what's the benefit of Kiss over something like Arch Linux which is already minimal?

<comment><USER36> Arch is far from minimal. It literally ships systemd, and all kernel options enabled. Not to mention glibc, and a shitton of other crap...

<comment><USER44> While I agree that Arch is far from minimal, it is one of the distributions that encourage people to build their system up to meet their needs. This is a far cry from the attention grabbing desktop distributions that may or may not offer a server version that can be built upon (which I, perhaps unfairly, interpret as discouraging the build-up approach).

<comment><USER8> I disagree. That was true for a time, and i enjoyed it coming from NetBSD. But nowadays, if for any reason you don't want to use systemd, or have different opinions about partioning, e.g. limiting access and execution rights and usage for /var, /tmp you are in for an eternal uphill battle against the decisions of 'upstream' and therefore the 'community' which devoutly adheres to these. There are some derivatives addressing that, but at that point you can also say: "Forget it!"

<comment><USER45> > [...] have different opinions about partioning, e.g. limiting access and > execution rights and usage for /var, /tmp you are in for an eternal uphill > battle against the decisions of 'upstream' and therefore the 'community' > which devoutly adheres to these. There are some derivatives addressing that

I'm curious about which use cases wasn't supported for you, why it was an uphill battle and which derivative addressed them. I don't quickly see what would give you issues at first glance.

<comment><USER8> I don't remember exactly anymore, left ship too long ago. But it wasn't about the /usr move.

One derivative would be [https://web.obarun.org](https://web.obarun.org) , another one [https://artixlinux.org](https://artixlinux.org)

</comment></comment></comment></comment></comment></comment><comment><USER46> No Wayland, but Xorg? How is that simple?

<comment><USER24> There are lots of good, simple window managers (not to mention other utilities) for xorg. Window managers in wayland have a lot more work to do, and are typically more complicated.

There are lots of utilities that aren't available in wayland yet, so you'll often end up with an x server installed anyway.

<comment><USER47> Not using a GUI at all would be much simpler.

</comment></comment></comment><comment><USER48> Gene Simmons ./tongue -s

</comment><comment><USER49> So this is basically Gentoo with precompiled packages.

<comment><USER50> The package manager is much simpler than Gentoo's.

</comment></comment><comment><USER51> War is Peace.

Freedom is Slavery.

Less is More.

</comment><comment><USER52>
        * Based on musl libc, busybox and the Linux kernel.

As some one who is working on Go ecosystem, this drops my interesting immediately. Using musl libs means a lot of tools can't be used on this OS unless we install the glibc.

<comment><USER53> Are there problems with go on musl, then? Not a heavy go user but I'm sure I've built a working go setup fairly painlessly on musl VM before. (Maybe it's a recent problem or perhaps I'm misremembering and I did something horrid like pulling in glibc too, but I don't think I did?)

<comment><USER53> Being unsure of my recollection, I've just bootstrapped and installed the most recent go 1.14.3 release on a pure musl x86_64 chroot. Everything I can think of to test so far is working impeccably.

</comment></comment></comment><comment><USER54> Could be cool, but isn't Wayland less bloated than Xorg?

</comment><comment><USER55> Website looks terrible, practically unreadable on mobile. Black and red don't go well together either.

<comment><USER56> I enjoyed viewing it on an OLED screen.

<comment><USER55> They don't even have the "viewport" meta tag set, so it isn't meant for mobile.

<comment><USER57> Oh wow, and yet it looked beautiful in Firefox on my OnePlus 6T. Very impressive.

</comment></comment></comment></comment><comment><USER58> > Based on musl libc, busybox and the Linux kernel.

Busybox is not KISS. It's an all-in-one package, removing the ability to strip down the number of tools you have to the ones you strictly need. It's a big, bloated binary blob, in other words.

> Every installation of the distribution contains the full sources (of the > distribution) with git history attached.

This doesn't even pretend to be minimal.

<comment><USER16> That's not strictly true about Busybox. You just need to recompile it to change what's included. You can absolutely enable/disable individual tools in the menuconfig.</comment></comment>