Why is there only one Snap Store? - <AUTHOR> https://merlijn.sebrechts.be/blog/2020-08-02-why-one-snap-store/ <comment><USER2> That reminds me of the stake Ubuntu Core was born with in its heart:

> An Ubuntu SSO account is required to create the first user on an Ubuntu Core > installation.

They just keep flinging shit at nothing and hoping to hit a wall they can build a gate in.

They're trying to boil the frog slowly with Snap on the Server/Desktop branches.

There is no possible genuine motive for these maneuverings to be in the position of gatekeeper.

If anyone at Canonical is listening, you should be aware it doesn't matter how slowly and carefully you approach this, or how you justify it, the first time I'm forced to kiss the ring to get my software to work, your software is gone from any system I own or manage, immediately and forever.

You're not going to get within a thousand miles of monetizing the ecosystem by gatekeeping it -- the moment you even so much as assert the position of gatekeeper you're trying to create for yourselves you're dead to me.

<comment><USER3> To be completely honest, if Canonical ever wants the theoretical "year of the Linux desktop" to happen, they need a way to get proper cloud accounts working.

A big part of the value of Apple's ecosystem is iCloud. Microsoft has done the same thing with the syncing and cross platform capabilities of their Microsoft Accounts.

Most Linux users today don't care much if they need to create separate email, cloud storage, backup storage, password recovery and application store accounts. That's because many Linux users have a preference for one service or even self host.

Normal people aren't like that. A desktop without a cloud account is like an Android phone without Google apps or a theoretical Apple phone without Apple apps. Technically fully functional and customisable via sideloading, but ultimately pointless because nobody wants to go through that. Just ask any regular Jane or Joe on the street if they can set up IMAP email on their phone; I bet they just use Gmail or Outlook.

It's not the Linux power users Canonical wants to attract; it's regular users. Their requirements are different from yours or mine. The Ubuntu Core website specifically says it's built for business. It's focus is on configurability and enterprise deployment, making it closer to a managed Windows 10 enterprise network than something you run on your laptop at home. Lockdowns and gatekeeping are practically what the service is intended to do.

<comment><USER4> For my money, the year of the Linux Desktop was 2008. It's just that nobody noticed.

Since 2008, Linux has had the best combination of performance and hardware support on older machines, and the advantage has only grown since then. Windows and MacOS keep falling further behind in usability on machines older than four years, and that's the only hardware I would purchase for personal use. Why throw your money away on planned obsolescence, on an OS that keeps getting worse and worse, when you could use Linux on an older machine and have things keep getting better and better?

<comment><USER5> In terms of usability, yes, but the problem with Linux in recent years has rarely been usability, it's the lack of workstation-level applications that are readily available on Windows and MacOS.

As long as Linux lacks native support for Autodesk, Adobe CC, Office 365, FL Studio, Pro Tools, etc. and dozens of other niche programs by ISVs it will never approach the mainstream with any sort of widespread appeal. Currently Linux on the desktop is suitable for people who are aware of these limitations and either circumvent (through technical means such as WINE, which are opaque to the typical end-user) or tolerate them, acknowledging the limitations and doing nothing to mitigate them while embracing Linux's strengths as a web and educational medium (think Chromebooks).

I legitimately have tried going Linux-only several times in my life and I've just come back to Windows every time. I know it's not ideal from a security perspective, a privacy perspective, etc. but there is just zero competition with Windows in terms of a software support perspective. Windows' backwards compatibility and range of software support is a masterclass in how to enable productivity. Even MacOS doesn't come close, with how frequently Apple breaks stuff that's expected to be supported (32-bit app support, Rosetta, etc) and how frequently they change architectures (68k > PowerPC > Intel > RISC, vs Microsoft with 32-bit Intel > 64/32-bit Intel)

<comment><USER6> That seems like a moving goalpost to me.

First, it wasn't usable. Then, it didn't have drivers. Then, it crashed a lot. Now it doesn't have Autodesk stuff? For the record, my mom doesn't know what Autodesk is. A "desktop" for me is where you can play movies, edit documents, browse the net and check email.

<comment><USER5> And Linux is fantastic for that, until you come across a use case that is outside those typical bounds.

Say your mom decides she likes photography one day and decides to buy a camera and take some lessons. Say her teacher says "we use lightroom and photoshop so you'll need to have these because they're industry standard" and she has no idea what to do and why the Adobe CC launcher won't load on Linux. Then she'll call you up and ask why it won't work, you'll respond with "there's no photoshop, you can use GIMP though" and your mom being a regular computer user won't be familiar with the eccentricities of GIMP as editing software and will be lost and unable to follow through on her new hobby.

This has literally happened to people in my life I've recommended Ubuntu to. Too many times to count.

<comment><USER6> That is a real problem, but in my opinion unrelated to whether an OS is "ready for the desktop". That's just a business problem, not a technical problem: Adobe cares about platforms where the money is.

It's not a technical problem because people like my mom can learn to use GIMP (note: people who use photo editing software are "pros" of a kind, anyway; "regular" users don't know how to edit photos, either) or Krita or whatever. But even if you fix GIMP's UX issues, it's still not Photoshop or Lightroom, so the problem remains: there's no Adobe software for Linux.

But that's not what being ready for the desktop is about. That's not what a desktop is for most people, either. All in my opinion, of course.

PS: if Lightroom magically makes it to Linux (hypothetical thought experiment), but _then_ it's Overwatch or some other high profile AAA game that doesn't run natively, is it still a problem of the Linux desktop?

<comment><USER7> > _That is a real problem, but in my opinion unrelated to whether an OS is > "ready for the desktop". That's just a business problem, not a technical > problem: Adobe cares about platforms where the money is._

Only back in the day part of the idea around "Linux for the Desktop" was that everybody would use the "better" FOSS programs, and not wait for MS/Adobe/Autodesk/Avid/etc.

But, as you note, this hasn't happened, and "even if you fix GIMP's UX issues, it's still not Photoshop or Lightroom".

> _But that 's not what being ready for the desktop is about. That's not what > a desktop is for most people, either. _

Well, pragmatically the desktop is a Windows machine, which just works, doesn't require them to think long and hard about which cpu/memory/laptop/peripherals/etc to buy, has drivers for all of their devices, has all kinds of apps they might use (beyond email and web), and so on.

<comment><USER6> > _Only back in the day part of the idea around "Linux for the Desktop" was > that everybody would use the "better" FOSS programs, and not wait for > MS/Adobe/Autodesk/Avid/etc._

That wasn't really like I and many others envisioned, no. Free software have other benefits that make them "better", not merely technical issues.

</comment></comment></comment></comment></comment></comment></comment></comment></comment><comment> gjsman-1000 "Interestingly, Canonical actually released an open-source prototype Snap store backend a few years ago, but there was very little interest from the community in in actually maintaining and running a second Snap store, so the project bit-rotted and became incompatible with the current Snap protocol."

That open-source server was a single-python-file hacky prototype written in an employee's spare time. It's not surprising it got little interest.

Not only that, but this is the biggest omission of the truth: Making your own server is no longer possible because of assertions. All Snaps are now digitally signed by Canonical, so you actually need to have the end-user install a forked snap tool on their system to access the custom repository. You cannot disable this signing - your only way around it is to manually download the snap and install it with `--dangerous` through the CLI. And you won't get auto updates that way.

<comment><USER8> > All Snaps are now digitally signed by Canonical, so you actually need to > have the end-user install a forked snap tool

Isn't the client side open source so you can put your own signature? Digital signing things seems a good idea for security.

<comment> gjsman-1000 I wish, but the signature is actually compiled into the snapd (the software on your system)'s binary. Deliberately impossible to reconfigure.

Like I said, you can change the signature... by distributing a forked binary to users that would be incompatible with the main store.

<comment><USER8> Isn't this good? I mean if you are a distribution you compile the software yourself so you can add the distribution keys (there are some that don't compile stuff ).

Probably you are thinking there should be atext file in your home where you could add new signature to be sued, but that could be a security issue so probably needs to be something more safe,did any serious patch was sent to improve this and was it rejected or why we expect Canonical to prioritize this over other issues?

<comment><USER9> > Probably you are thinking there should be atext file in your home where you > could add new signature to be sued, but that could be a security issue so > probably needs to be something more safe,did any serious patch was sent to > improve this and was it rejected or why we expect Canonical to prioritize > this over other issues?

If someone can replace that text file, they can replace the binary the key is compiled into.

<comment> gjsman-1000 Yeah, but this isn't really any worse than APT or RPM at the moment. More like, if they can change the text file, you've got bigger problems.

</comment></comment></comment></comment></comment></comment><comment><USER10> _" Although they invested significant resources in open sourcing Launchpad, there is still only one instance of Launchpad running and they have not received any significant contributions from non-Canonical employees."_

For what it's worth, there _is_ another Launchpad instance in existence: [https://quickbuild.io/](https://quickbuild.io/)

From personal experience, I found it functionally impossible to get a local instance working when I tried a few years ago. I applaud someone else managing to pull it off.

<comment><USER11> Launchpad is also objectively more complex and hard to use than alternatives, and subjectively I'd say it's ugly and looks dated. Launchpad isn't probably something people want to use because of product design, and thus there's not much activity around it outside of Canonical.

I think it would be silly to assume that a separate project that is liked wouldn't get traction outside of Canonical because of their experience with Launchpad.

<comment><USER12> > Launchpad is also objectively more complex and hard to use than > alternatives, and subjectively I'd say it's ugly and looks dated

Launchpad is _really_ old though. When it was open sourced, there were very few alternatives and those were often even more complex and harder to use.

I think part of the reason why it was almost never used was because it does so much: project management, bug trackers, build service, package hosting, ISO and distro building, ..

If you only need a few of these features, you are much better of using alternatives with a smaller scope.

<comment><USER13> Launchpad actually predates Ubuntu :) A lot of the methodologies and practices used to develop it (both good and bad) didn't even get names until years later. I even hear monoliths are becoming fashionable again.

</comment></comment></comment></comment><comment><USER14> It's not for nothing that Snap is considered dangerous by SUSE and is not officially supported. They even fail basic upstream responsibilities.

[https://blog.linuxmint.com/?p=3906](https://blog.linuxmint.com/?p=3906)

> A year later, in the Ubuntu 20.04 package base, the Chromium package is > indeed empty and acting, without your consent, as a backdoor by connecting > your computer to the Ubuntu Store. Applications in this store cannot be > patched, or pinned. You can't audit them, hold them, modify them or even > point snap to a different store. You've as much empowerment with this as if > you were using proprietary software, i.e. none. This is in effect similar to > a commercial proprietary solution, but with two major differences: It runs > as root, and it installs itself without asking you.

> First, I'm happy to confirm that Linux Mint 20, like previous Mint releases > will not ship with any snaps or snapd installed.

<comment><USER12> > Applications in this store cannot be patched, or pinned. You can't audit > them, hold them, modify them or even point snap to a different store.

This is not entirely correct. Distributions can use a "brand store" to have complete control over which packages their users get.

> You can't audit them

Many Snaps contain a build manifest in `/snap/snap- name/current/snap/manifest.yaml`. This manifest contains a log of everything that is used to build the package. For snaps built on Launchpad, this is automatically enabled and includes a link to the Launchpad build log for that snap. This is one of the build logs for the Chromium package, for example: [https://launchpad.net/~osomon/+snap/chromium-snap- firstrun-n...](https://launchpad.net/~osomon/+snap/chromium-snap-firstrun- notice/+build/1071421)

Using Launchpad as the source of truth, you can be 100% certain that the snap you're running is built from the source it presents. This is the same infrastructure that builds and provides trust for Ubuntu itself.

The snapcraft build service uses Launchpad in the background, so any snap built using that can be audited just like regular Ubuntu packages. Snaps built on third-party infrastructure can enable this manifest using an environment variable.

I don't know why Linux Mint is spreading such misinformation, but this is harmful.

<comment><USER15> > This is not entirely correct. Distributions can use a "brand store" to have > complete control over which packages their users get.

By "you" I assume they are referring to users, not distributions.

<comment><USER12> Hm, maybe you're right. So in that case:

> hold them

Users have many ways to hold snaps temporarily. If they want to hold snaps indefinitely, then they should install them using he `--dangerous` flag. That won't give them any updates, but I'm guessing that's the point. They can always get the latest version of the app manually using `snap download snapname` and install it using `snap install snapname.snap --dangerous`.

> modify them

Just like a `.deb` package, users can unpack a snap, modify any file, repack and install the modified version. Alternatively, you can unpack the snap, modify any file and install the directory using "snap try". You can then modify files and rerun the app without having to reinstall it for every change.

> or even point snap to a different store.

The signing keys are baked into the Snap binary but the URL is configurable via an environment variable. So users can change to a different Brand Store without any issue. If they want to use a store with a different signing key, they have to install a different version of snapd which is compiled with the signing keys of the other vendors.

This isn't an insurmountable problem, but it is less flexible than apt, yes. Although I think "apt remove snapd; apt install snapd-fsnap" is still pretty easy..

</comment></comment></comment></comment><comment><USER16> Semi-related:

Does anyone else feel like Ubuntu has lost a lot of its momentum over the past few years? I don't hear about things they're doing nearly as often anymore.

<comment><USER17> Things they're currently doing that benefit the larger Linux community as a whole:

\- still engaging with vendors into making hardware work on Linux

\- they're contributing optimizations to gnome 3

\- their still massive user base is testing stuff, discovering bugs and then those things get fixed upstream or at least get into Debian

\- making bad decisions so people jump off Ubuntu and go back to Debian, my beloved distro

<comment><USER16> > \- making bad decisions so people jump off Ubuntu and go back to Debian, my > beloved distro

Amen. Debian is the best.

<comment><USER18> When I fist started using Debian, it was a bit of a potato. It improved over time but still felt a little wooden. Ubuntu brought a lot of people back into the Debian ecosystem, ensured that it improved constantly to the point where it's a corporate power buster, and I feel like the next release will hit the bullseye for sure.

<comment> dane-pgp Why did you squeeze so many release names into that comment?

<comment><USER19> you would need to be a bookworm to know all of them

</comment></comment></comment></comment></comment></comment><comment><USER20> This is easy to explain if you think of it as a business decision. Why would anyone pay $30000 for a custom "enterprise edition" snap store[1] -- which among other features restores full control of updates -- if anyone could easily set up their own snap stores?

[1][https://ubuntu.com/pricing/devices](https://ubuntu.com/pricing/devices)

<comment><USER12> I don't think open sourcing the store would significantly cut their sales. Running a world-wide package distribution network in itself is an incredible cost which many companies are willing to pay for. CentOS did not cut into the sales of RHEL either, for example. It's useful to have someone to yell at when things break.

Also note that there are already alternatives. I personally know a few companies who built their own stores internally and it's actually very easy to do so if you install the apps using side-loading.

</comment></comment><comment><USER21> I do like the snap concept, but some implementations are just not that great. For instance, kustomize as snap doesn't let you read anything outside that is not in the snap fs. Not even in --classic mode. A similar issue happens with nextcloud which is good on paper, but if you tweak something inside the snap fs it will be overridden in the next update(expected behavior); however, for services that require mutable configuration there needs to be a way to preserve that data (I tested that nextcloud behavior more than half a year ago).

<comment><USER12> > For instance, kustomize as snap doesn't let you read anything outside that > is not in the snap fs. Not even in --classic mode.

Classic snaps have complete access to the host filesystem. It is up to the publisher, however, to request classic confinement. If the publisher creates a `strict` snap, users cannot override this (because strict snaps would break when their container and dependencies suddenly disappear)

> for services that require mutable configuration there needs to be a way to > preserve that data (I tested that nextcloud behavior more than half a year > ago).

Snaps have access to multiple locations to store mutable data like `SNAP_COMMON`, `SNAP_USER_COMMON`, `SNAP_DATA` etc. Snaps can optionally also access regular directories.

Afaik, Nextcloud stores its configuration in one of those directories. I think what you experienced might be an issue with the NextCloud snap because snapd itself already supports this.

</comment></comment><comment><USER22> Control.

1\. Get market share with free product.

2\. Start charging once monopoly is achieved.

3\. Profit!

<comment><USER23> Lol as if there is oodles of money to be gained from hosting a store like that on Linux. We can see all these steam game publishers desperate to release games to a community that is rather famous fo being cheapskates.

Also, snap existing doesn't hinder flatpak or appimage or debs or rpms.

<comment><USER24> They aren't going for a model like Steam where they sell software to end- users. The idea is to get enterprises hooked on using snaps to distribute their software internally, and then charge them for private repository hosting.

<comment><USER23> Then fair play for Canonical to get revenue streams from enterprise?

From my perspective the primary motivation seems rather simple in minimizing the maintenance costs/testing of having to publish software for 5-6 distributions.

That to me seems more plausible than evil mustache twisting capitalist reasons.

</comment></comment></comment></comment><comment><USER25> I tried not to interpret the article in the worst possible way, but I failed, it feels disingenuous to me.

I don't think comparing ppa's to snaps is a good comparison.

ppa's have the disadvantage of potential dependency problems which might break things like upgrades, and that has nothing to do with having a distributed store.

snaps solve this and that has nothing to do with a proprietary single company controlled store.

<comment><USER12> I'm sorry you feel this is disingenuous. I really tried to explain why there is only one Snap Store from a neutral point of view. Let me know if you have any tips to make it more genuine.

You are right that this has nothing to do with the dependency problems Snap solves. Snap does many things differently but this article only focusses on one to keep it relatively short.

This article doesn't try to present a comprehensive comparison and definitely not between Snap and PPA. The article only focuses on the question why there is only one Snap store. The answer to this question has nothing to do with Snap bundling dependencies.

I also wrote a separate blog post about bundling dependencies here: [https://merlijn.sebrechts.be/blog/2020-07-06-why-snap- flatpa...](https://merlijn.sebrechts.be/blog/2020-07-06-why-snap-flatpak/)

That blogpost lumps Snap and Flatpak together since, for the sake of bundling dependencies, the two technologies are pretty similar.

</comment></comment><comment><USER26> My main reason for disliking Snap is the fact that it allows anybody in the world to publish a package with minimal moderation. This completely undermines the inherent trust that system package managers should have.

When installing critical system packages, I want to be absolutely certain that these are legitimate/official, and that even if I make a minor error in typing a command, I won't inadvertently install some sort of typosquatted fake version of the package.

When using Apt with the default repositories, this isn't a problem at all, as only known, trusted packages are available. In other words, there's no chance of someone publishing a fierfox or apahce2 package to try to typosquat someone.

I don't even want to talk about the forced automatic updates either... these make it essentially impossible to have a stable/reliable system for specialist use cases, e.g. browser testing, bastion host, build environment, where control over updates is very important.

On the sandboxing - it's good in principle, but rarely seems to be implemented in a truly meaningful way, as ultimately once you have home drive access, you don't even need to worry about escalating privileges as everything valuable is probably in your home area! There's an xkcd about this somewhere...

<comment><USER27> > My main reason for disliking Snap is the fact that it allows anybody in the > world to publish a package with minimal moderation. This completely > undermines the inherent trust that system package managers should have.

Where do we get more maintainers? Sometimes in my development I release one new Wekan version per day. Canonical's Snap build servers download Wekan source code directly from GitHub, it is very transparent.

> On the sandboxing - it's good in principle, but rarely seems to be > implemented in a truly meaningful way

Wekan Snap has strict sandbox, so code can not access any other directory that /var/snap/wekan/common. So in case someone would find exploit for web service, it can not escape sandbox. It is very important.

</comment></comment><comment><USER28> Debian user here, who has apparently missed the memo: What do snaps do that apt doesn't?

<comment><USER29> Pollute your mount list and make your software start way slower and take up more space. Also sometimes break or require intervention for basic operation due to security restrictions on it.

The benefits are supposed to be that they're more secure, more portable, and don't junk up your system with files strewn everywhere.

Personally I'm waiting for a better solution than anything we've seen so far for the first of those benefits, and would prefer a cross-platform user- oriented package manager like Homebrew or Nix (but better-supported-on-Linux in the former case and with a UX less like studying for a math exam in the latter) for the other two. IMO every solution to these problems on Linux desktop currently sucks to one degree or another.

<comment><USER30> What's so impressive about Homebrew specifically?

<comment><USER31> Also curious. I'm waiting, or even begging for something like flatpak on mac os just due to the number of times pip/npm/python in general has broken due to homebrew.

<comment><USER32> What's wrong with elementary OS? (pls don't kill me HN — Edit: yup, downvoted for a simple question)

<comment><USER29> • Nothing available that's as lightweight and good as Apple's "office"-type suite.

• Nothing as all-around good as Preview (yes, seriously).

• Worse battery life, partly due to worse OS optimizations and partly due to not having Safari available. Solutions to this in Linux that actually yield good results usually involve hard-capping performance at a pretty low level, IME.

• Little things like screen recording and screenshot capabilities not being as nice for basic use, out of the box.

• AFAIK not only is the default English keyboard on Linux far worse at the task of writing in English than that on macOS, there's not a single alternative layout that's close to as good as the Mac default. Yes, I'm dead serious about this, and frankly it's friggin' weird they'd have such a significant advantage on something like that in the year 2020, and I _really_ wish other operating systems would catch up because I _do not_ like being forced to use Apple products just so my experience composing documents in English isn't bad. I do not understand how they still have such a large advantage here, but somehow, they do. Totally baffling.

• If you do anything serious with software-UI-related graphic design, or work closely with people who do, you _pretty much_ need a Mac because odds are good you'll be using at least some mac-only software or have things shared with you that work only in mac programs.

• You lose a variety of time-saving integrations with i-devices, if you're someone who takes advantage of those.

<comment><USER33> I'm not understanding the English keyboard complaint, am I missing something?

<comment><USER29> Look up how you type: those • characters I used in my post, an m-dash (—), a c-cedilla (ç), a german double-S (ß), basic accented characters for various Western European languages (we have many, many loan words and phrases from those in English—façade, résumé, áñ∂ §ò öñ), punctuation for French and Spanish (no, you don't strictly need these for English—but in practice, depending on the register you're writing in, actually you do), major world currency symbols ($, £, €, ¥, ¢), basic mathematical symbols and mathy Greek letters (≤, ∑) and so on.

Look up how you do that on US English keyboard layouts in macOS, Linux, or Windows. Then check AltGr and US International alternative layouts for the latter two. Marvel at how macOS manages to crush all those options in usability with their default, without affecting the experience for someone who doesn't need those _at all_. Join me in wondering how no-one else has at least matched them on this, which _is not_ some recently-added feature in macOS, but is practically ancient in computing terms.

<comment><USER32> > Look up how you type: those • characters I used in my post, an m-dash (—), a > c-cedilla (ç), a german double-S (ß), basic accented characters for various > Western European languages

No thanks! I already new how to type — (Compose - - -), and I was able to guess how to type the others simply by trial and error in less time than it would take to duck/google how to type them:

Compose + . + - → · (close enough for me Edit: Compose + . + = → •) ┃ Compose + c + , → ç ┃ Compose + s + s → ß

Compose + e + ` → è ┃ Compose + e + ' → é ┃ Compose + ` + e → è ┃ Compose + ' \+ e → é

Bonus: Compose + - + > → → ┃ Compose + = + / → ≠ ┃ Compose + / \+ = → ≠ ┃ Compose + : + ) → ┃ Compose + L + L + A + P → (Edit: HN seems to have stripped out the last two, a smiley face emoji and the \\\// / Star Trek/Live Long And Prosper hand. So I guess the compose key can type more characters than HN even allows.)

ß°ηυ5 þē 5€¢•ηⅾ: Pressing the alt key reveals underlines under selectable gui elements. Press any letter that's underlined (while still holding alt) to activate the element (menu item, button, etc.). Try this in every GUI you use regularly and then race a macOS user stuck with reaching for a trackpad or mouse everytime they need to click something. Јоⅰη ⅿе ⅰɳ wօɳԁеrⅰηg Һօw ɳօ‐օɳе аt Аррⅼе tҺօυgҺt tо аⅾԁ tҺіѕ, wҺⅰϲҺ іѕ ɳօt ѕоⅿе rесеɳtⅼу‐аԁԁеԁ fеаtυrе ⅰɳ ԌΝU⁄Ⅼіɳυⅹ, Ьυt ⅰѕ рrасtіϲаⅼⅼУ аɳсіеηt ⅰη ϲоⅿρυtⅰɳg tеrⅿѕ (¡ΝаѕtУ Wⅰηԁоwѕ, рrеҺⅰѕtоrіс Wіηԁօwѕ _95_ , Һаⅾ tҺеѕе υηⅾеrⅼіɳеѕ аⅼwаУѕ ⌵іѕⅰЬⅼе!).

<comment><USER29> Great! Linux, I assume? _goes looking_ OK yep, I'll enable it and start re- training myself on that, for when I'm not on mac. It's not quite as quick for most of the things I need frequently, but seems tolerable.

Remaining questions: 1) why would the default be bad? Like, why ever would one make a default bad if there are non-bad options? Especially for something everyone should want to be good on a computer, like composing text in the user's language, and 2) ugh of course even once enabled the default compose key is bad (there's a theme here) and both enabling it and configuring it depends on which WM/DE you're in, Wayland vs. Xorg, and so on, and from some googling it's even possible to run into inconsistent behavior between different friggin' GUI toolkits under the same DE.

OK that second one is a comment, not a question. Still.

I'd _recently_ googled the problem of (specifically) typing an em-dash on Linux, and just tried it again, and sure enough this solution doesn't come up until the sixth hit, in an unassuming Google documentation style guide. "Just memorize a 4-digit number" is the overwhelming answer to that question, on search engines, for some reason, despite plainly being awful. Maybe the configuration hurdle and bad default behavior is why that's the go-to solution, I dunno.

[EDIT] none of the above irritation aimed at you, I hope is clear, and sincerely, thanks for the pointer.

<comment><USER34> 1) why would the default be bad? Like, why ever would one make a default bad if there are non-bad options?

Because it is not bad, it just chooses different advantages and disadvantages.

Right Alt could be configured to do regular Alt modifier, or could be configured to enter additional characters (Alt Gr - third/fourth level).

The first case has advantage that Alt-based keyboard shortcuts on right side can be conveniently entered by one hand. That is why there are Shift, Control and Alt on both sides of keyboard.

Second case has advantage that you can enter more characters, but entering rightside Alt-based shortcuts is more awkward.

Conventionally, US keyboard uses the first approach (as there are less need for entering more characters), while many non-US keyboards use the second approach.

Also, why Compose key is not accessible by default? Because there is no Compose key on common PC keyboard (in constrast to some old Unix keyboards). Therefore, Compose key need to 'steal' some existing key, which is problematic, because users expect existing keys to work as expected. I personally use Menu key as Compose key, but other users may have different expectations.

</comment></comment></comment></comment></comment></comment></comment></comment></comment></comment></comment><comment><USER35> What does snap do that flatpak doesn't?

<comment> gjsman-1000 Well, if you are building an IoT Device, lots of stuff for reliability. Automatic rollbacks, self-repairing, immutable FS...

For a desktop user, honestly, very little.

<comment><USER36> That reliability stuff sounds good on desktop too. I don't exactly enjoy re- running apt after it has mysterious failures halfway through installs.

<comment> gjsman-1000 You might find Fedora Silverblue fascinating. It's an OS that uses Flatpak for Desktop Apps exclusively, which disposable "toolboxes" for non-Flatpak apps.

<comment><USER37> And all the systrm stuff is immutable and managged by OSTree. This makes it posdoble to diff only download a new system state and then atomically switch to it after reboot. And if you hit any issues with it, just boot to the previous one (you can have multiple previous states).

</comment></comment></comment></comment></comment><comment><USER38> Have they fixed the unearthly slowness of SquashFS? Is there a filesystem out there that is slower?

<comment><USER12> The fault isn't SquashFS itself but the compression they use. They use an old compression algorithm by default to support older kernels. They are working on optionally enabling quicker compression on distros that support it though.

See this for more info: [https://forum.snapcraft.io/t/squashfs-performance- effect-on-...](https://forum.snapcraft.io/t/squashfs-performance-effect-on- snap-startup-time/13920)

</comment></comment><comment><USER39> > Snap is designed so each device only connects to a single store for three > reasons: > users can easily discover new applications, > developers can > easily publish their apps, > and developing Snap itself is easier.

Just a PR bullshit to cover for lack of freedom and need for control. Disregard.

</comment><comment><USER40> The better question is why is there a snap store? With flatpack and appimage already working well, why muddy the waters with another offering, much less one that it awful.

</comment><comment><USER41> God, I could not hate Snap more. At least a .snap file can be mounted as a SquashFS and salvage what you can to run the program without snapd. Unrelated, but it is curious that some applications I have encountered depended on some proprietary library. To the bin it went. :D

</comment><comment><USER42> The author mentions popularity as a justification and good reason to go with a central snap store. I am baffled.

<comment><USER12> (author here)

I'm not sure what you are referring to exactly, where do you think I say that?

These are the reasons I talk about in the blog:

* users can easily discover new applications, * developers can easily publish their apps, * and developing Snap itself is easier.

<comment><USER42> > That said, I'm pragmatic about the proprietary back-end. DockerHub and > GitHub are insanely popular and they are completely proprietary.

</comment></comment></comment><comment><USER43> I highly recommend switching to Pop!_OS.

</comment><comment><USER44> It does not seem that the author is affiliated with Canonical. Ideally, Canonical should be the ones defending their product.

IMO, it is okay for the backend to be propriety as long there is a published, easy to implement protocol for talking to snapd (along with an accessible way for clients to configure snapd). Otherwise, there is lock-in to the service. It's not just the FOSS community that should be concerned, but business users as well. Do you want to internally distribute in-house snaps via Canonical's servers?

> DockerHub and GitHub are insanely popular and they are completely > proprietary.

These are arguments against, not for, using these services. And many proprietary SaaS companies sell installations on on-prem air gapped servers.

<comment><USER12> Canonical has defended their product in many places. This article contains a lot of the same info, for example: [https://www.techrepublic.com/article/why- canonical-views-the...](https://www.techrepublic.com/article/why-canonical- views-the-snap-ecosystem-as-a-compelling-distribution-agnostic-solution/)

</comment></comment><comment><USER45> There is only one Snap store as this is what Microsoft is actually buying if it buys Canonical and turns the Snap store into the Microsoft store.

</comment><comment><USER46> Ahaha crap on all sides. Please come to Nix (or, hell, GUIX) and side-step _all_ these issues.

<comment><USER12> Nix is really cool! You can actually use Nix to build Snap packages! Not sure if that's actually used a lot though.

One of the advantages of Snap over Nix is that snap has security builtin. Snap is built to support a store where anyone can publish any application without curation. Nix Flakes look really cool for third-parties to "publish" applications for Nix, but I wonder how they will do security..

In Snap, the default permissions of an app are stored and distributed out-of- band with the package itself. The package defines what permissions it _can_ use and the declaration defines what permissions it is _allowed_ to use by default. Users can then override the default permissions.

You could get the same level of confinement in a Nix package, but then the package contains both the app and the confinement, so the packager or software provider gets to decide what permissions a package has on your system. Any idea how Nix could address this?

<comment><USER46> The _building_ of nix packages is completely sandboxed and secure. The running of them is currently an after-thought.

\- [https://spectrum-os.org/](https://spectrum-os.org/) is a _big_ idea for secure running of applications, which leverages Nix for some things.

\- I would like to see some CloudABI/Capsicum experiments, as anything that is not capability based seems baroque, difficult to, ill-fitting the problem at hand, and generally going to end in tears.

\- There is currently some wrapping around systemd-nspawn which could be improved.

BTW when I say "The running of them is currently an after-thought" this isn't as bad as it sounds. I would say all the good solutions are not the scope of Nix, but instead the scope of NixOS, Nix home-manager, nix-darwin, etc. Still, a real problem that deserves a solution. Thanks for bringing it up.

</comment></comment></comment><comment><USER41> If I wanted spyware, I would just install Windows 10, really. Screw Canonical.

</comment><comment><USER47> Because Shuttleworth has notorious Apple-envy.

</comment><comment><USER48> This article is disingenuous at best!

<comment><USER12> Author here. I'm happy to address any issues in the article. Let me know if there are any issues.</comment></comment>


A Linguist's Guide to Pronouncing 'GIF' - <AUTHOR> https://medium.com/s/story/g%C9%AAf-or-d%CD%A1%CA%92%C9%AAf-5ac6fe8b2589 <comment><USER2> A gentle introduction to phonetics and the IPA is let down by poor argument.

MAGA (rhymes with dagger or lager?) would never be pronounced with a soft G because 'ga' is only soft in such anachronisms as 'gaol' (modern spelling jail).

And it is hardly prescriptivist for the programmer that coined a term to define its pronunciation.

Opposition to the soft pronunciation is, at least in my country, because 'Jif' TM is a household cleaning product, so I'll continue to pronounce it wrongly for that reason!</comment>


Data serialization - <AUTHOR> https://enqueuezero.com/data-serialization.html <comment><USER2> Dealing with data as my day job I've become highly sensitive to schema's. And I hate those "schemaless" (aka schema-on-read) serialization formats more and more. No, there is no schemaless, there is a schema, but it is buried in your code in a convoluted way on each line where you read and interpret your deserialised data and all tests and assumptions you have there are a horrible representation of your schema. That is an important dimension to compare serialization on, and JSON is a complete loser in that sense. Not to mention how it flawed its numeric type is.

<comment><USER3> I really wish we had a JSON 2 format which could fix JSON's obvious shortcomings. I would like to see:

\- Support for Maps and Sets (unlike objects, maps allow arbitrary types to be used as keys)

\- A standard Date format

\- Embedded binary blobs. No idea how to do this and keep it human readable, but when you need this its super useful. Maybe something similar to WS's binary message encoding.

\- Arbitrary precision integer support. This is particularly useful for cryptocurrencies and for interoperability with 64 bit integers in other languages. And bigints are coming to javascript - [https://github.com/tc39/proposal-bigint](https://github.com/tc39/proposal- bigint)

\- Maybe even fix JSON's weird unicode encoding: [http://timelessrepo.com/json-isnt-a-javascript- subset](http://timelessrepo.com/json-isnt-a-javascript-subset)

Unfortunately it seems like nobody 'owns' JSON enough to give JSON 2.0 the political weight it would need for cross-language support.

<comment><USER4> I'm not an expert, just a bio-data-scientist learning every day... But wouldn't Yaml be what you are looking for?

<comment><USER5> Json is for machines, yaml is for humans, as a general rule. They're mostly compatible feature-wise.

<comment><USER4> Yaml is well readable by a human but it's much to tightly defined to be "for humans". It's for machines but readable by humans I'd say. Plus it's got sets and you can embed csv's (just 2 things of the top of my head).

</comment></comment></comment></comment></comment><comment><USER6> re: protobufs

> It requires the program doing data parsing work to have the generated > library as well. This would generally cause problem when schema modified.

That's not the case, and is the exact reason why you need to specify tag numbers in protos - so that you can make your schema forward and backward compatible when decoding/encoding from/to the wire format.

</comment><comment><USER7> I would also recommend CBOR ([http://cbor.io/);](http://cbor.io/\);) one can think of it like a binary form of JSON. It has a few advantages:

      * datetime objects
      * binary blobs

It is very similar to MsgPack in nature. However, MsgPack, in particular on Python, poorly handles the text/bytes separation, and CBOR is backed by RFC.

<comment><USER8> CBOR is MessagePack. At least cbor-ruby started with the MessagePack sources. The story is that Carsten took MessagePack, wrote a standard and added some things he wanted, and called it something else.

I wrote [1] a pretty comprehensive (and admittedly biased) critique of the CBOR standard last year.

[1] [https://news.ycombinator.com/item?id=14072598](https://news.ycombinator.com/item?id=14072598)

Disclaimer: I wrote and maintain a MessagePack implementation.

</comment></comment><comment><USER9> S-Expressions are missing. Language support is poor (except if you're programming in a Lisp dialect in which case it's built-in), but I do believe they are the best serialization format out there:

[http://wiki.c2.com/?XmlIsaPoorCopyOfEssExpressions](http://wiki.c2.com/?XmlIsaPoorCopyOfEssExpressions)

They have a canonical representation

[https://en.wikipedia.org/wiki/Canonical_S- expressions](https://en.wikipedia.org/wiki/Canonical_S-expressions)

I swear I have seen a proposal for an efficient binary representation somewhere but I can't find it.

<comment><USER10> As far as I understand S-expressions are completely code-as-data, so how do you protect yourself from malicious code execution when loading S-expressions?

<comment><USER11> Simply not passing any of these parsed expressions to your _eval_ function.

ANSI Common Lisp presents a pitfall here in that it features read-time evaluation via the #. (hash dot) syntax. For instance #.(+ 2 2) produces the object 4. After seeing #., he reader scans the (+ 2 2) expression, evaluates it immediately, and substitutes the result. When reading untrusted data in Common Lisp, the __* _read-eval_ __* variable must be set to _nil_ to disable hash-dot.

Lisps that don't have a read-time-eval escape mechanism don't require anything.

</comment></comment></comment><comment><USER12> Serialization format has no relation with schemas. Also, Schema validation can be as strict or lax as you want it to be.

I wrote Spyne (in Python) mainly to abstract the schema from the serialization format. The protocols are totally pluggable and your code cares only about the models and not the serialization format. The latest alpha is out not long ago. Check it out if this sounds interesting.

[https://github.com/arskom/spyne](https://github.com/arskom/spyne)

Code generator: [http://spyne.io](http://spyne.io)

<comment><USER13> This sounds interesting and I would have liked to read more but currently I'm getting timeout issues trying to visit spyne.io. Could you please check?

</comment></comment><comment><USER14> Protobufs and similar projects like it (gRPC, Cap'n Proto) seem really interesting, but I haven't come across a time at work yet where it's made sense to the team to adopt it. Maybe that's just my own inexperience, but the serialization scheme is low on the list compared to optimizing DB queries, getting rid of bloat in the app, etc. I've been waiting for an excuse to adopt this stuff at work because it seems really cool!

<comment><USER15> Defining your schema upfront and have types generated in multiple languages is the real value add. The performance is a nice cherry on top.

<comment><USER16> More specifically, being able to agree and communicate schemas to other collaborators is a big win when trying to avoid interfacing bugs.

OTOH schemas seem less necessary if you are working on a completely self- contained app.

</comment></comment></comment><comment><USER17> Regarding JSON, this page says:

 _> Performance is not good when dataset is huge. Program usually needs to load all data into memory first._

This is just downright false. There are plenty of SAX-style JSON parsers.

<comment><USER18> Yes. This is a surprising claim in the IP, especially after saying that XML has high performance.

<comment><AUTHOR> I removed performance piece mostly because it's meaningless discussing performance without in the context of designated implementation and benchmarks.

Above catch is my point so I tweaked the words to `Performance is not good generally when dataset is huge unless you use a library support streaming parsing or writing.`

</comment></comment></comment><comment><USER19> Cool, in the ~same vein, SBE is definitely worth a look.

[https://github.com/real-logic/simple-binary- encoding](https://github.com/real-logic/simple-binary-encoding)

</comment><comment><USER20> Don't we do CSV/TSV anymore? It's certainly the most basic schema-less data format imaginable, and you can even have field names using the convention that the first row contains field names.

It might be considered out of fashion today in our staged this-vs-that culture, but I don't see anything wrong with it. Tab-separated-values are just data fields separated by a distinguished character, with rows separated by another distinguished character; as simple as it gets and no API required.

<comment><USER21> It's complicated enough that you need a library to properly use it and simultaneously simple enough that people think they don't need a library. Then there are the billions of possible variations. Nobody can agree on a common column (is it ',' ';' or '\t'), newline seperator, whether the first row is a header and you can only store data in the first normal form. CSV is so terrible that even excel spreadsheets are a better data exchange format.

<comment><USER20> Nice said :) but come on. CSV parsing is trivial.

</comment></comment></comment><comment><USER22> I wonder why FlatBuffers aren't a more popular option[0]. The format isn't even mentioned in the article. I have never used it (since I my needs were not that advanced), but it seem to combine quite a few amazing qualities of other serialization formats, while adding a few of its own. It even has a version without a schema called "FlexBuffers"[1]. I would expect anyone considering ProtoBuffers and MsgPack to give FlatBuffers a look.

Two five minute lightning talks by Van Oortmerssen, who created the format (another reason to take a closer look IMO), that shows off some of the powerful features:

 _Lightning Talk: FlatBuffers (2015)_

[https://www.youtube.com/watch?v=olmL1fUnQAQ](https://www.youtube.com/watch?v=olmL1fUnQAQ)

 _Going Further with FlatBuffers_

[https://www.youtube.com/watch?v=90ND0yQVYg8](https://www.youtube.com/watch?v=90ND0yQVYg8)

[0] [https://google.github.io/flatbuffers/](https://google.github.io/flatbuffers/)

[1] [https://google.github.io/flatbuffers/flexbuffers.html](https://google.github.io/flatbuffers/flexbuffers.html)

<comment><USER23> I've used it in production, can confirm it is awesome.

Flatbuffers destroys ProtoBuf both in terms of allocations(1 vs N where N is usually huge) and deserialization speed.

You also get explicit control over your data layout in memory when you write the message. So if you know what your read patterns are up-front you can get amazing cache usage even in managed languages.

</comment></comment><comment><USER24> One topic not brought up in this is versioning/change management. While I have my criticisms of Json, if I decide to add a new field to my object, most JSON parsers have the advantage that they'll just consider my old data without that field to have a full value there. XML, same thing.

How does protobuf or MsgPack handle that? Aren't they both trying to align data by byte number at some deep level? Or do I not understand them?

<comment><USER25> Protobuf has supported this for as long as I've used it. You add an optional field for the new data. And there's a couple other considerations. (Docs: [0])

Fields have a number, which you can/should mark as reserved after you take it out. Then future developers won't use a field that was something else in the past. [1]

Since version all fields are optional ( they removed the required field feature). So your app has to check that the fields you want (in that version of your app) are present.

[0] [https://developers.google.com/protocol- buffers/docs/proto3#u...](https://developers.google.com/protocol- buffers/docs/proto3#updating)

</comment></comment><comment><USER26> > Performance is not good when dataset is huge. Program usually needs to load > all data into memory first.

You could use a streaming parser, or, more easily, NDJSON (assuming your data is huge, because it's a list of stuff). Just save each JSON as a line in a file and then stream the file line by line, only parsing one line at a time. That's fairly fast and allocates very little memory.

</comment><comment><USER27> I read somewhere the problem with MsgPack is, that JSON has a rather fast parser build into JavaScript that beats the MsgPack parser. So you would have to check if the saved bandwidth would be enough to justify the slower parsing.

Would be interesting if this still holds true with a WASM implementation.

<comment><USER17> I used to think binary formats for network protocols were a really good idea until I found out how big the TCP header itself can be. Saving a few bytes from your payload by using binary representations of integers doesn't make a huge difference when the TCP header is 60 bytes.

<comment><USER28> Just to add another dimension to your analysis, if you're sending large binaries the 33% overhead of Base64 adds up pretty quickly. It may not apply to your use case but if you are delivering images or video over a websocket it can make a big difference.

<comment><USER29> On the other hand, gzip can reclaim most of those 33% with Huffman encoding.

<comment> Const-me Only in some cases. Also it increases latency.

Here's my old article about Microsoft's binary XML format: [http://const.me/articles/net-tcp/](http://const.me/articles/net-tcp/) As you see, for some payloads it compresses XML to 9% of the original size.

The data contract serializer included in .NET framework (and even in .NET Core) can read & write objects directly from/to this binary serialization format, without intermediate text XML anywhere.

</comment></comment></comment></comment></comment><comment><USER30> > Use Thrift if you're developing RPC services.

There's gRPC now, which uses Protobuf messages and is much better than Thrift.

[https://grpc.io](https://grpc.io)

<comment><USER31> Could you expand on that a bit? I'm interested in promoting gRPC over thrift at work, but so far the only benefits I see are the HTTP/2 transport which allows for better load balancing and request tracing on the transport level.

<comment><USER30> gRPC with Protobuf has been faster in our usage and also has more development these days compared to Thrift. It's also simpler and better designed by just sticking to a single well-tested serialization format.

HTTP/2 is also a big advantage since it's standardized and easily integrates into many existing load balancers and proxies like Envoy and nginx, both of which now natively support gRPC directly too.

</comment></comment></comment><comment><USER32> Our company implemented two rpc protocols(don't ask me why..)

One is based on json, one is modified thrift. The schemaless feature is among the many problems of json, but it's not the most annoying one. That would be binary support.

Imagine we need to make a upload/download storage service with json rpc...So as a rule of thumb, I would consider:

1\. Web facing? json would do.

2\. RPC? Pick protobuf or thrift or any protocol supporting native types including binary.

</comment><comment><USER28> I'm working on a product where I had to serialize 100KB+ BLOBs in two places. The first was over stdout from a c program to an elixir application and the second was over a binary websocket, specifically a Pheonix channel.

In both cases I'm using MsgPack. It was easy enough to implement and I like how it has real numeric types.

</comment><comment><USER33> Here are some benchmarks for Python and Java [https://stackoverflow.com/questions/9884080/fastest- packing-...](https://stackoverflow.com/questions/9884080/fastest-packing-of- data-in-python-and-java)

</comment><comment><USER34> If you're storing tons of numbers you might consider scientific formats like HDF5, ROOT or FITS.

<comment><USER5> Add netcdf4, which builds upon hdf5.

<comment><USER34> Ah yes! I've actually used it before (to read in atmospheric data) but I couldn't remember the name.

</comment></comment></comment><comment><USER35> OT, but I'm excited to see TiddlyWiki in the wild.

<comment><AUTHOR> nice catch bro.

</comment></comment><comment><USER36> Checkout EDN. It's about JSON, but you can extend.</comment>


Ask HN: MacBook Pro still preferred laptop for non-MS development? - <AUTHOR>

At work I've used a MacBook Pro for the past several years, and I'm planning to get another laptop soon for home development use. Is it still the tool of choice, or are the changes towards Mac App Store making it less friendly towards development? Is the extra money worth the value for a serious developer? I'm leaning towards a MBP with 15" matte screen with SSD, but I've heard aftermarket SSDs can be better quality than what Apple provides, but I hear they were Kingston drives in the 2011 MBPs, and Kingston's not terrible, is it? I know Crucial and OCZ make decent ones, too, and Tom's hardware said previously that Intel were the best.
I'm ok using Linux too, but I'd rather spend more time developing and less time messing with driver issues and a crappier user experience like I tend to in Linux. Although, I recently put Lubuntu on a x100e and love it as a fast and modern lightweight OS, though the package manager isn't the easiest to use, but it is much less buggy than the Unity one with the screenshots and icons.
Windows imo is usually not well supported enough for development tools and languages, unless you're using it for .Net/MS development. You end up spending too much time fixing issues that another developer using OS X/*nix didn't test in Windows. <comment><USER2> I've recently switched from a MBP to a System76 laptop, after about 5 years of running MacOS X, and I couldn't be much happier. The new MBPs are extremely harsh to type on between the sharp edge and the keyboard. I ultimately had to buy a Kinesis just to use it because the MBP destroyed my fingers. Most people don't have that problem, but it's nice to be able to actually use my laptop as a portable device again.

I also really don't like the direction Apple is taking MacOS. Lion chugs resources and does odd things like disable my second monitor when apps go into fullscreen mode. I don't really care much for the direction of the Mac app store, too.

LinuxMint has been great. It's the first time I've really run a Linux desktop since about 2003. What I miss is the polished apps. E.g., Adium is much better than Pidgin and Postbox or Sparrow are much better than Thunderbird. But, overall, I've been pleasantly surprised. Plus, I have 16 GB RAM now (could've gone up to 32 GB) and the OS consumes a lot less of RAM in general.

<comment><USER3> I've always wanted to buy a system76 laptop; can you please elaborate on the model that you bought? The only things I was unsure of: 1) Is it very heavy (as in weight) compared to MBP? 2) Display quality? 3) Trackpad quality?

(I don't mean to turn this into a review, but just wanted a developers experienced opinion on the issues that nagged me most)

<comment><USER2> I bought the 15" Serval Pro (sp7). It weighs about the same as my 17" MBP did. So, same weight, but smaller screen. Naturally it's thicker. I went with the 15" because at the time of purchase that was the only one with a matte display option.

I had the hi-res matte 17" MBP. No doubt about it, that screen was nicer. But, I really don't have any complaints about my new 15" screen. I've been using it actively for about 2 months now and have gotten used to it.

The other two areas the MBP clearly win out are battery life and power supply. I couldn't really use my MBP without a Kinesis, so long battery didn't mean much. But the System76 gets about 2.5 hours like most other brands. The power supply is a beast though and adds another 4 lbs or so when traveling. It also lacks the awesome mag-safe connector.

Bonuses: comfortable keyboard, nice rubber finish, no sharp edges, integrated keypad, plenty of ports and no need for dongles, replaceable battery, easy hardware upgrades, up to 32 GB RAM (I went with 16 GB), and well-supported hardware.

The trackpad is nice. It took some getting used to since I had used a clickpad for so long.

Overall, I'm pretty happy with it. I dual-boot Win 7 for dev work and set it up such that I can access that partition as a raw disk in VMWare. While it works pretty well out of the box, it's a Linux laptop so I would expect to do some tinkering. And while it's a pretty attractive system, it has nowhere near the sex appeal of a MBP or MBA. That matters little to me. I treat it as a portable workstation and really just want to get work done. But, just be aware of what you're buying.

</comment></comment></comment><comment><USER4> I think it's quite a personal choice. I've stopped using Windows six years ago, because I'm only working on webapplications that run in the browser. I also believe there will be a great shift from installed software to webapplications the next years.

If the software is going to be in the browser, you have to look for the tools that make it as easy as possible to do so.

Personally I love Apple products. Indeed, you pay a premium, but my 4 year old MacbookPro is still very fast, and makes no sounds. Second, Node.js, Eclipse, Redis, etc, have great support for MacOS, and I've the feeling Windows is not that much supported.

It is true Apple does not always uses the very best hardware components. For half the price of a MacBook Pro, you can buy an ASUS with the same hardware configuration. But what is important for me: how does the system perform with the hardware it has?

So my prefered choice is a MacBook Pro indeed. But if you don't want to spent the premium, you can also buy a less expensive notebook and install whatever Linux distribution you like.

If you want to buy a new MacBook Pro, I'd wait if I were you, the current model is almost at the end of the life cycle, and I'm waiting for the new release... If you can wait a couple of months more, I'd wait.

<comment><USER5> On the other hand, the current MacBook Pro line is quite mature which translates to stability and lack of grievous hardware or firmware issues. I'm still wary of buying a first generation Mac product after my experience purchasing a newly-unveiled Macbook (white body) in June 2006. Between the dirty-looking discoloration of the plastic and the random auto-shutdown firmware bug that bricked my new laptop in the middle of the firmware update to remedy aforementioned bug I was very unhappy with my early experience. It turned out to be a great computer after the bugs were ironed out, but I'd still rather avoid repeating the experience.

Is there any innovation expected in the MacBook Pro line that will be that much of a leapfrog over the current incarnations? I'm wanting to buy a new development laptop in the next two months as well and I can't see anything other than a better form factor coming out of the next generation.

<comment><USER6> Yes the next generation of MBP will not have a cd drive and is supposed to be like a MBA but a little bigger.

<comment><USER7> Where did you get that information?

<comment><USER8> He's referring to the usual suspect... rumors.

</comment></comment></comment></comment></comment><comment><USER9> MacBook Air 13". Small, light, cool & silent running with a high resolution and a great keyboard + touchpad. This truly is the best laptop I have ever used.

Thanks to the chipset and SSD it handles everything like a champ. It can even easily run a VirtualBox with win 7 and Visual Studio should you wish to do MS development.

So I would recommend it to every programmer (who needs a laptop).

Comparing SSD's is silly though. It's like comparing supercars. Those small performance differences are irrelevant. Especially when you are used to something very very slow. I would definitely recommend buying something with an SSD for development.

</comment><comment><USER10> I lean toward the 13" Air. My current work laptop is a 15" Macbook Pro, but I have an Air at home. If you don't need the larger screen, which I don't because I plug into at least one extra monitor most of the time, the Air is a nicer package. Less to lug to and from work. The other caveat is that, if you need to run multiple development virtual machines for testing, the 4GB memory max for the Air is somewhat limiting.

<comment><USER11> My current work laptop is a 13" air. For non-compiled development (e.g. JS or other interpreted languages) I find the slower CPU of the Air and limited memory (4GB) plenty sufficient.

<comment><USER12> The SSD and the screen make it for me.

I've also got a new Mac mini with a considerably faster processor and twice as much RAM, but the little hard drive in it makes the mini seem slow as molasses after getting accustomed to the SSD in the Air.

I can't go back to hard drives as my booting device.

</comment></comment></comment><comment><USER13> An Apple laptop is definitely the way to go - my dev laptop is an Air (late 2010) and it's still insanely fast (despite the out of date hardware). In many ways this is thanks to the SSD drive (which is an Apple one).

The premium is definitely worth it, Apple products seem to last (and stay fast) for years after their Windows equivalents. The other advantage if you're developing webapplications is OSX, which makes it very easy to replicate a Linux server (nginx, apache, RoR, node, php, mysql, redis, etc, etc all run flawlessly).

</comment><comment><USER14> It all comes down to the development you like to do. There was a time when i really didnt like paying extra cash for a macbook (that at the time) seemed like it was more expensive then the equivalent spec'd windows laptop for no reason.

However now, i cant do without my macbook because for web and mobile you really dont need anything else and the frameworks can be configured locally without silly things like cygwin.

Alot of the developer tools are built in and you can do iPhone and android development also (obviously on windows or linux you cant do iPhone dev ) which means if you ever do decide you need to develop an iPhone app as part of your offering you are going to have to get a macbook anyway.

The only downfall is if your still doing any blackberry development you can't do it on a mac though you could always circumvent that by using a VM.

<comment><USER15> I use a late 2010 MBA with nvidia graphics for CUDA development. Apple's agreement with Intel doesn't allow them to make products which use nv chips anymore, so this is probably my last Apple for a while.

</comment></comment><comment><USER16> Personally I would pick Thinkpad or Dell - you can check "compatibility" of specific model with drivers shipped in linux kernel - so you don't have to mess with drivers at all. At least that's what I always do - never had an issue with compatiblity with linux nowdays, just buy what you know will be supported best.

I think it more depends what you want to develop, i've often heard that it's less hassle to play with python etc. on linux than on a bsd.

<comment><USER17> This would be even more attractive if vendors consistently refunded the $130 if you refuse the Windows TOS (and license). Anyone had any luck with that?

[1] [http://arstechnica.com/open-source/news/2008/08/lenovo- wont-...](http://arstechnica.com/open-source/news/2008/08/lenovo-wont-refund- the-windows-tax-without-an-nda.ars)

[2] <http://en.wikipedia.org/wiki/Windows_refund>

<comment><USER3> This is the _only_ reason why I'm holding out buying a Dell laptop. I just can't bring myself to pay so much money for something I'm just not gonna use (I use linux)

</comment></comment></comment><comment><USER18> I was looking for a new laptop also, and I found pretty good deals for a i5 based Acer TimelineX, which I was able to add 8GB of ram and a 256GB Samsung SSD for ~$1000 total. I also run Ubuntu 12.04 on it, and documented all of the non-intuitive things you might run into[1]. Battery life has been 8-9 hours (my normal windows include Chrome, Sublime Text Editor and a terminal). I also take advantage of the HDMI port and hook up a much larger screen when I get home.

The Samsung SSD performs great, and the system boots up in what feels like maybe 5 seconds, I haven't taken a stop watch to it yet.

1: [http://www.sharms.org/blog/2012/04/finding-a-great-ubuntu- li...](http://www.sharms.org/blog/2012/04/finding-a-great-ubuntu-linux-laptop- for-1000/)

</comment><comment><USER19> We're a startup based in the UK, soon going to start selling Thinkpads (X121e, possibly X220) with Linux pre-installed and fully tested (Ubuntu/Debian/Arch).

We'll ship to anywhere in Europe and are also looking at shipping to the USA and other places.

If you're interested, please sign up here - <http://giniji.com/ubuntu_laptops.html>.

I know most developers (at least on HN) now prefer Macbooks, but we want to push hardware in the direction of software and make it more open. Before laptops, I never remember buying a desktop PC off the shelf. I always assembled my own from parts (as most of you probably did too). I miss being close to the machine and want to bring it back.

<comment><USER3> try to make them beautiful, will you? I've always wanted a beautiful laptop that could run linux.

</comment></comment><comment><USER20> > I'm ok using Linux too, but I'd rather spend more time developing and less > time messing with driver issues and a crappier user experience like I tend > to in Linux.

Issues 5-6 years ago. No longer a problem.

<comment><USER21> This really depends on what combination of Linux distro and laptop you use.

If you install a user friendly distro like Ubuntu 12.04 yes, everything or almost everything works as expected.

Try to install CentOS on a shiny new laptop and let me know if everything works without messing with a lot of configuration files.

<comment><USER20> When you say _linux_, it is so broad. You have choices. You choose Ubuntu / Fedora / Linux Mint / ArchLinux / Gentoo for laptops. You choose CentOS / Debian / Gentoo for (older) desktops and servers.

No one with a sane mind (or with enough Linux experience) would install CentOS on a shiny new laptop.

<comment><USER21> Thanks, I've actually used Linux from ... 1999, hopefully I'm still sane even if I need to use CentOS for RedHat compatibility on one of my shiny new laptops.

</comment></comment></comment></comment><comment><USER22> I came from a 3 year old Thinkpad T400 to borrowing a new 15" MacBook Pro with matte screen and SSD for iPad app dev. After feeling the improvements with the new E420 thinkpads keyboards I think I'm going to wait for the new T430 Lenovos to arrive for my next upgrade.

For me, as a developer, nothing is more important than having a good keyboard. The macbook has really cheap thin keys that don't have the feedback I'd like. The wrist rest edge is sharp which leaves marks on my wrists. The indentation where you cram in a finger to open the screen has knife sharp points on both sides that just makes you wonder what were they thinking. It gets rather hot underneath as well.

So ergonomically, it hasn't been that great of a transition for me even though I wanted it to be. Maybe the macbook air or the 13" pro may be better. Plus I'm too used to using the thinkpad's Trackpoint to mouse around. If you're a vim user, it's awesome with mouse support enabled while keeping fingers near the home row.

</comment><comment><USER23> I've been working with a 15" MBP for the past couple of years. I recently swapped out the standard hard drive for a Kingston HyperX SSD (it was about $200 for 120 gigs) and it has literally changed my life. I finally have a responsive computer :) Maybe Kingston SSDs aren't the most performant, but I can't imagine anything better at this point.

<comment><USER24> > I can't imagine anything better at this point

Swap out your optical drive for a second SSD/a massive HDD. I did that with a OWC DataDoubler and it's a brilliant experience: most apps and OS on SSD load in a blink, while data lives on the HDD to avoid heavy writes knackering the SSD prematurely (because it lacks TRIM)

</comment></comment><comment><USER7> The hardware is definitely solid, whether you go for macbook pro, which has faster cpu but needs aftermarket SSD, or macbook air that is slower but has SSD integrated and has better resolution.

The OS ... depends on what are you developing. Mac OS is about as good for consuming stuff as windows 7, i.e. pretty good. For developing web apps, with textmate and github you're golden. But for full scale unix coding, you can't get better than Linux, in the amount of helpful software available, and while homebrew is cool, it has long way to go from aptitude.

Also, Apple kind of screwed up things with their throwing out of gcc (which was obsolete and strange version anyway) so you can't even compile lot of FOSS on Mac OS right now, especially multimedia software.

EDIT: for the record, I'm using old old old 2007 Macbook with OCZ SSD.

<comment><USER25> You can still install gcc. There are packages somewhere on github.

<comment><USER7> Interesting. Where?

<comment><USER25> <https://github.com/kennethreitz/osx-gcc-installer>

Use the prebuilt packages in the readme.

<comment><USER7> I'll take a look, thanks. But if I understand the description (and if I remember my experience from trying it out correctly), this is just gcc with llvm backend but without Xcode. That's useful if you don't care about Xcode, iPad development and just want compiler, but it doesn't solve the problem you can't compile ffmpeg, mplayer, mysql and others on Mac OS.

It's however possible I remember wrong package, so I'll check that out.

<comment><USER25> I haven't tried ffmpeg, mplayer, or mysql but it let me build ruby using ruby- build.

</comment></comment></comment></comment></comment></comment><comment><USER26> Hm, not a lot of linux laptop love so far so I'll throw my hat in. Last December I bought a ASUS U31 (U31SD-A1 Intel Core i3 2310M 2.10GHz 13.3" 4GB Memory 640GB HDD NVIDIA GeForce GT 520M) and I absolutely love it.

The only thing that didn't work with stock ubuntu was the optimus video but with bumblebee it's fine, i only use it to switch off the nvidia anyway since 2d works fine on the intel chip. Also if you give windows a partition it's great for games too.

10 hours of battery life which is probably the most important feature. I never need to worry about bringing a charger when i travel on the weekends. I decided to replace the internal drive with an intel SSD which was spendy, but even after that the price was well below 1k.

</comment><comment><USER27> I have the top of the line MBP 17" Quad Core i7, 256 GB SSD, top video card, and 8 GB RAM. It runs Windows 7 in VMware faster than I have seen on a PC, though I am sure there are PCs that can compete with the VM, I have been thrilled with it. I also run two 27" Apple displays (2560x1440), one the new Thunderbolt, that I daisy chain with my year-old mini-display port one. Then I also have a 28" Hanns-G display that is 1900x1200 which I run with a Viewmax USB video adapter (a little powered device). This last one has slow video performance, but it is fine for word processing or e-mail. Writing this on it now.

I have had very good luck with the SSD, my biggest complaint is size. If I put all of my pictures, work files, and music on it, the drive would be full. I like having everything on all my PCs for backup and convenience, but recently bought a 3 TB Seagate GigE drive ($179) that I put on my router. It performs pretty well, so I keep all my files there, and just the work stuff and a few pictures on my 17". I like the ideal of 500 MB minimum now that I am out of space, and those will seriously sting your pocketbook.

I am not a gamer, so for that, I would not take my advice, I can just tell you that for the engineering work that I do, it rocks.

I am a "fastest you can get" computer guy, who still believes "the PC you want will always cost you $4,000." So in my case, my $3,800 MBP was a bargain!

In all seriousness, you will be very happy with the top of the line 17". Would I wait? If you can, I probably would; however, you will not be disappointed with the current model.

</comment><comment><USER28> I do development with a maxed out 2011 11" MacBook Air. It's tiny, just bigger than an iPad but has a 1.8 GHz i7, 256 GB SSD and 4 GB which has been adequate.

The screen is small but I don't do much development where I don't have a large external monitor. In my home office I use a pricey Thunderbolt Display which gives very good docking capabilities with a simple connection.

I love the nearly invisible weight and very portable size. Highly recommended if your responsibilities don't require massive hardware capabilities.

</comment><comment><USER21> Well, if you want to be trouble free and use your machine for coding I a think Mac is a good choice. But I would wait for 1-2 months to see what the new Macs will offer.

You really need to consider what kind of work are you going to do with your new machine. If for e.g. you are interested in GPU computing then, at least for now, a Mac computer is not a good choice.

If you are interested in having the best SSD and RAM on your laptop you can buy your Mac with the default configuration and simply buy more RAM and a SSD from Crucial, for example. From a economical point of view is cheaper to buy a 512 GB SSD from Crucial than to buy your Mac with a 512 GB SSD, same goes for RAM.

</comment><comment><USER29> You should consider buying an mb air instead of an mb pro. The ssd makes it unbelievable fast and paired with an extra display it's a power house for development. the mb air is just a solid piece of hardware. I have no regrets buying one so far.

</comment><comment><USER30> I've been using a 15" MBP for a little over a year. I added an aftermarket OCZ Vertex 3 SSD since it was faster and cheaper than what was available from Apple at the time (not sure if they've expanded their options) and some after- market RAM for price reasons. I've found it to be the best machine for my use. I've got Mac software (I do a lot of front-end graphics design work), and Windows when I want it (via Parallels) and enough of a Linux/Unix feel for my purposes with terminal-based stuff.

If I had to replace it, I'd get another MBP ... new ones are due out soon .... likely before June, so wait if you can if that's what you decide to buy.

</comment><comment><USER31> I develop on a 15'' MBP but running Ubuntu in a VirtualBox VM. This means that my OS in development is the same as in test and production. Plus it lets me avoid the hardware issues that can come with running linux natively.

</comment><comment><USER32> This hasn't really been mentioned yet, but to me a laptop is a big purchase, so I look at resale value as a factor. The cycle I keep is about 2 years on my Macs (and definitely buy AppleCare), then sell them off. Usually I can get about 50-60% of my original investment back, meaning I can keep the latest hardware for about $500/year (assuming a $2000 laptop). Then of course you can write off that depreciation if you use it for business.

I'm not as versed on non-apples but my impression is that they don't hold their value as well.

</comment><comment><USER33> Dell's latest XPS 14z (14") and 15z (15.6") are designed after MBP. You can easily get an i7/8G RAM/1080FHD screen/750G 7200RPM HDD XPS below $1000 ( <http://bizspeaking.com/?q=dell+xps+15z> ) compared to Apple's $2199 i7/4G RAM/1440x900 screen/750G 5400RPM MBP. How about the OS? Give all the RAM to the MacOS VM. And if you sneer at VM, with the $1000+ saved, upgrade to 16G RAM / 512G SSD and still have some change left for beer.

</comment><comment><USER34> macbook pro 13" fan here - you can throw up to 16 gigs or ram in it, and an ssd/hdd combo. wait another month for the new ones to come out though.

If I had to buy a non-apple laptop right now though with linux in mind, it'd likely be a hp envy 14 spectre at some big discount. other contenders would be the vaio z or samsung series 7. i'd usually recommend lenovo, but they haven't had any good minimal designs come out aside from the too-small x220

<comment><USER35> Is it undocumented that the MBPs can handle up to 16GB of RAM? According to apple, they all can only go up to 8GB (or 4 for older models).

<http://support.apple.com/kb/HT1270?viewlocale=en_US>

<comment><USER34> yes. It's undocumented but several people have installed it successfully, and OWC has been selling 16gb kits for the past year or so: [http://eshop.macsales.com/item/Other%20World%20Computing/133...](http://eshop.macsales.com/item/Other%20World%20Computing/1333DDR3S16P/) .

</comment></comment></comment><comment><USER36> Replacing my late 2011 MBP with a system76 lemur. I've been running linux on the MBP for a while and it works well, except for the wireless where only G is supported for now. I'll be receiving the system76 on monday so I can't tell if I like it.

</comment><comment><USER37> I'd get a 13" Air instead.

</comment><comment><USER38> Stay away from Crucial SSDs. I've had one for almost two years now — I've had lots of trouble.

I just ordered an Intel 520 to replace it. I've heard great things.

<comment><USER39> I think the key is to make sure the driver software is mature at the time of purchase (no room for optimism when it comes to your data). I've had a Crucial m225 for 2 years, perfect performance and reliability so far. The speed is not setting any records but just about maxes out my SATA II bus anyway.

</comment></comment><comment><USER40> sager quad core, 4gig ram, 500 gig hard drive. that was three years ago and my next will be a sager also as the to power/cost ratio is great. with Ubuntu on it things hum beautifully. having the extra cores is great so that I can builds, watchrs, and a movie all running why working.

</comment><comment><USER8> Replace Macbook Pro for Macbook Air

</comment><comment><USER41> I switched from Ubuntu on a ThinkPad to a MacBook Air 13" from mid 2011 and I love it.

<comment><USER42> I switched from an iMac to Ubuntu on a Thinkpad from mid 2011 and I love it ;-)

I also have a desktop, mind. Don't know how anyone can do development solely on a laptop.

<comment><USER43> > Don't know how anyone can do development solely on a laptop.

Mmmm... I work exclusively on an 11" MacBook Air with no external display. My coworkers think I'm a crazy person, but the constraints work for me. I stay focussed on the one thing that's on screen.

</comment></comment></comment><comment><USER44> Yes

</comment><comment><USER45> New MacBook Pro models are coming soon. At the very least, Apple will likely release new models with Ivy Bridge CPUs sometime between now and mid-summer.

Further, there's long been rumors that Apple was re-working the entire "Pro" line to be more like the Air. So people are speculating that the new Pros will be much thinner and drop optical drives, gain SSDs by default and (I hope) have a dual SSD & HD configuration. (so you have the speed of SSD for your boot disk and applications but an HD to store volumous data like photos and video.)

This is rumor, of course, but it seems very logical. Apple is not a company that normally keeps legacy technology around and the DVD has become pretty legacy. There is a very active modding community replacing their DVD drive with a second hard drive or SSD, enough that companies like OWC make special parts for it, so I think Apple's a little behind the curve on booting that legacy technology. (Personally I think they intended to do it last year with the 2011 models, but held off because of a delay in some aspect of the design.)

Even if you don't end up preferring the new model, the older models will get cheap when they're announced.

I've gone shopping looking at other laptops periodically, but the unibody construction of the MacBooks makes them unbeatable. You don't' realize how flimsy plastic laptops feel until you've a unibody. Even the fairly robust aluminum and titanium MacBooks feel flimsy by comparison.

These days so much of the quality of a laptop is very hidden- for instance, putting four WiFi antennas in the MacBook Pro is not something most people know about, and when shopping most people look to see that "wifi is built in" to all the other models, but I've never seen a review that compared the performance of Wifi across models and thus lowest price suppliers are naturally just going to put one wifi antenna in there. And this goes one down the line, chipsets, discrete components, etc. All of these things do have a perceivable improvement on your use of the machine (e.g.: staying in a hotel and not having to set a chair right by the door to get wifi, but being able to sit on the bed. Would you, sitting by that door, think "gee, if I'd gotten a macbook I wouldn't have this problem"? unlikely.)

Plus, if there is ever a problem, getting warranty coverage from other laptop makers is a PITA. Especially compared to walking into any Apple store worldwide and having your machine fixed within 30 minutes on the spot. (They do repairs in the store, and since they have a minimum number of models they have the parts they need on hand, but if they don't they're only a day or two away...)

So, I'd say the Apple Store itself is a big advantage for MacBook Pros, but that only works if you have an Apple store nearby.

Finally, I'd be wary of non Samsung SSDs. I've owned two SSDs: an Intel and a Sandforce based one, and I've had _four_ SSD failure so far. The Intel failed 1 year after buying it taking all of its data (and it had been 2 days since I'd backed up) with it. The replacement is still working. The Sandforce drive failed _THREE TIMES_. First time sent it back and they flashed it, second time they replaced the drive, third time I gave up on SSDs and went back to spinning rust.[1] Those three failure were within 8 months- the first time it failed was within 2 weeks.

The problem with SSDs doesn't seem to be flash wearing out (not within 2weeks-1year) but with the controllers wedging themselves because they've got a very difficult job managing the flash (and not a lot of RAM and are screwed if they lose power while live data is in the RAM). Since they're doing compression and all kinds of magical tricks to get performance and "manage" the data, that's what causes trouble. Samsung SSDs which aren't nearly as managed, and are just just a bunch of flash, seems to be much more reliable.

So, I won't use an SSD again until its under Apple's warranty because I can just then drop it off at an apple store if it gets wedged, and I think the ones Apple ships are a lot less likely to get wedged and I'll have my time machine drive connected all the time so the oldest my backup would be is an hour.

I can't speak to running Linux, but a recent interview with Linus on TechCrunch he said he was using a Macbook Air (because he wants a silent computer) and so I presume that means that Linux will run fine on MacBooks.

[1] I'm using only spinning rust. my co founder now has that intel ssd. Still likes the speed but I worry that it will fail again.

</comment><comment><USER46> The 15" Air's will probably be out soon, I'd wait for that.</comment>