Zulip Server 1.9: HipChat import and much more - <AUTHOR> https://blog.zulip.org/2018/11/07/zulip-1-9-released/?n=1 <comment><USER2> We (the Recurse Center) have been using Zulip since early 2013, and it is the core of our online community. Zulip is excellent both for small teams (we use it for our team of 7) and big groups - we also run a realm with over 1,000 users posting 10s of thousands of messages monthly. I can't recommend it highly enough.

<comment><USER3> How do you handle high availability for Zulip? Last I looked that was a problem for it.

<comment><USER4> Zulip founder here.

It's definitely possible to run a Zulip server with essentially no downtime. E.g. the main zulipchat.com service has had approximately 10 user-facing outages with a median duration of 5-10 minutes over the last 5 years (there was one while we still only had a few hundred users that lasted overnight), most of them in the middle of the night. Happy to talk more about this for anyone curious; there are some fun stories (like migrating from MySQL to Postgres as our primary database technology with <30 minutes of downtime early in its development).

We don't have a public uptime SLA for zulipchat.com uptime yet, but we're happy to make them for individual customers (and I suppose we should add one).

If you're self-hosting, our commercial support offerings will help you setup your servers in a way that achieves your uptime goals; because Zulip is so stable, usually folks just go with a hot spare (our enterprise customers generally only report downtime related to server upgrades, which is usually avoidable).

</comment></comment></comment><comment><USER5> I've said it before (so at the risk of annoying people ;-) I can highly recommend Zulip. We briefly used Mattermost (couple of months) before realising the Zulip threading model was a way better fit for us then what Mattermost offered. It might feel a bit odd in the beginning but after you've become accustomed with it you'll love it!

</comment><comment><USER6> I love Zulip and wish it the best.

But this comment on the zuplipchat web site [https://zulipchat.com/security/](https://zulipchat.com/security/) feels like a pretty gross generalisation and detracts from Zulip's vibe IMO:

> With many SaaS providers, essentially all engineers have direct shell access > to production servers storing user data. Zulip Cloud is different: only a > small handful of security-trained engineers have access to production > servers or to sensitive customer data.

<comment><USER4> Yikes, I'm not sure how "essentially all" ever got in there; it should have been "the majority of". And even with that edit, our practice is, where possible, to cite sources, and while there's a lot of anecdotal data on this topic, there aren't great published sources for this topic. So whether or not it's shockingly common for companies to have dozens or hundreds of people with shell access to production, we've removed the commentary on what other organizations do here, and just explain our practices.

I really appreciate the feedback!

</comment></comment><comment><USER7> We've been using Zulip for just over a week in xi-editor and related projects, and I'm thrilled. Huge improvement over the pastiche of IRC and Reddit we were using before.

<comment><USER4> Zulip founder here; I should add that Zulip hosting is free for open source projects: [https://zulipchat.com/for/open- source/](https://zulipchat.com/for/open-source/).

A bunch of other cool open source projects use it, including Python Core, parts of the Rust community, MariaDB, Coala, the Lean Theorem Prover, the HL7 standard, and many more.

<comment><USER8> How do you get the standard plan for an open source project? I don't see anything on that page or anywhere else, should we email the team for the bump?

<comment><USER7> "Just contact email@example.com and we'd be happy to discuss your situation!" ([https://zulipchat.com/plans/](https://zulipchat.com/plans/))

That's what I did. Thanks again to them, I really appreciate it.

</comment></comment></comment></comment><comment><USER9> I'd looked into Zulip a few months ago when it appeared on HN and it looks great to me. But this announcement mentions a new beta terminal client! That seals the deal for me! Love the idea of Zulip on a terminal: too good to be true for my organization at least.

</comment><comment><USER10> I'd love to set this up at my part time workplace, but it's a forensics shop where the network is offline, and doesn't have email. Team is small (<20) so manual accounts would be fine.

Am I reading the docs correctly in that email is absolutely required? I haven't checked thoroughly for this new release, but previously it was for missed message notification as well as account creation, if I'm remembering right.

It's not a for profit place, so I'm simply looking to self host, sans email, to make communication easier across the teams. Current solution is definitely inferior to Zulip!

<comment><USER4> We support this, it's just enough of a corner case that it's not well documented. If you don't care about missed-message emails, you can install the Docker image (easiest to setup when offline), and then use [https://zulip.readthedocs.io/en/latest/production/authentica...](https://zulip.readthedocs.io/en/latest/production/authentication- methods.html#apache-based-sso-with-remote-user) with an Apache .htaccess file as the thing that sets REMOTE_USER.

Send a message in "#production help" in chat.zulip.org if you have trouble figuring it out, and I'll extend the docs until you can get it working.

<comment><USER10> Well, that's a great reply. Having read quickly through the docs, I think in particular the "Life of an Apache-based SSO login attempt" had enough information to clarify the process for me - until then I wasn't as sure.

I don't think I would have located this option while filtering for "works without email, and I'm okay missing messages". If it was present a year ago I definitely didn't. Very glad it's a supported corner case!

<comment><USER4> Yeah, the front-page documentation focuses pretty heavily on "you should setup email" because it helps folks in a normal environment successfully setup Zulip quickly and reliably. I'm not sure whether this use case is common enough that we should put it in the front-page docs, but possibly we should write something that Google will find...

<comment><USER11> I looked at Zulip vs Mattermost several months ago and, if I recall correctly, this was one of the primary reasons I went with Mattermost. I just wanted something I could spin up in docker on a vps without having to setup anything else (like an email server). Mattermost lets you generate "invite links" that you can just paste in a chat or text message.

The other really neat feature was having multiple "teams" on a single server.

<comment><USER12> Hi, I don't know enough about Mattermost to be sure I understand you correctly about 'multiple "teams" on a single server' but you can host multiple organizations (realms in zulip-speak) on a single zulip server [https://zulip.readthedocs.io/en/latest/production/multiple-o...](https://zulip.readthedocs.io/en/latest/production/multiple- organizations.html)

edit: link updated to point to official documentation instead of github

<comment><USER11> That's neat, I may look at zulip again if I need to setup another server.

From a quick glance, the differences I see are: * In mattermost, different "teams" (or "realms" or "namespaces", whatever) exist on the same server (same url), and a user account that logs in will only see the teams they are assigned to. A single user account can be assigned to multiple teams (they appear on the left, similar to how the slack desktop app shows multiple server connections).

* Zulip requires a different subdomain for each "realm", and it sounds like users have to log into each one separately. It is not clear if the same account is shared between organizations or a user must have separate accounts.

So it sounds like Zulip's approach is separate, isolated "organizations", like slack, just hosted on the same server. Where Mattermost's approach is more like having separate, but integrated teams/groups/namespaces that a single account can be part of.

<comment><USER13> > So it sounds like Zulip's approach is separate, isolated "organizations", > like slack, just hosted on the same server.

Correct. But Zulip does allow to import settings, profile picture etc from an existing account during signup if the email remains the same.

</comment></comment></comment></comment></comment></comment></comment></comment><comment><USER14> It's pretty cool that he included the output of

        git shortlog -ns

in the release announcement.

<comment><USER15> I liked that too. But I prefer to hide merge commits using:

        git shortlog -sn --no-merges

<comment><USER4> Zulip has a rebase-based development workflow and doesn't use merge commits because in my experience, it produces a much more readable commit history (which is really important for understanding historical changes). We've been very happy with this approach. Some relevant reading on our version control approach for those who might be interested: * [https://zulip.readthedocs.io/en/latest/git/overview.html](https://zulip.readthedocs.io/en/latest/git/overview.html) * [https://zulip.readthedocs.io/en/latest/contributing/version-...](https://zulip.readthedocs.io/en/latest/contributing/version- control.html)

<comment><USER16> Doesn't using rebase generally mean you have to rebase on top of master and thus with your local branch you may need to git push --force ?

<comment><USER17> You rebase your feature/topic branches on top of master and then merge the feature/topic branch back onto master, enabling a fast-forward merge.

<comment><USER18> Is this a common workflow? Googling suggests almost religious feelings about this.

<comment><USER19> it comes down to whether you want your version history to reflect the true version of development's history (merge), or a simpler, doctored version of history which reflects the final deliverable (rebase). advocates of the latter, myself included, argue that it eliminates noise and tells all the story that needs to be told -- and that the original history can be preserved by not deleting the feature branches. others argue that changing your parent commit is dangerous and occlusive.

i think the core of it comes down to the UX for "git log", which attempts to display history linearly when in fact it absolutely is not. ask yourself: what is the _contents_ of a merge commit? if you know git well, you know that the merge commit contains everything from the feature branch... and that the feature commits you see when you run "git log" on master are actually not on master at all. so the rebase strategy makes master truly linear to match the tools and reduce cognitive load.

however, the rebase strategy does introduce new possibilities of tool-driven bugs and requires more rigor. this article has a good run-down of the risks:

[https://medium.com/@fredrikmorken/why-you-should-stop- using-...](https://medium.com/@fredrikmorken/why-you-should-stop-using-git- rebase-5552bee4fed1)

the classic example of a rebase pitfall is:

a) you branch from master,

b) on your feature branch, develop a feature utilizing dependency x,

c) meanwhile, on master, another developer removes dependency x,

d) you rebase back on top of master -- there are no conflicts, and things look good, but the build is completely broken.

</comment></comment></comment></comment></comment></comment></comment><comment><USER20> I'm a matrix - really via riot client - user, but never used zulip...Can anyone cite 1 or 2 big benefits of using zulip over matrix clients? I'm genuinely curious.

<comment><USER21> [https://zulipchat.com/why-zulip/](https://zulipchat.com/why-zulip/)

For me it's Zulip Topics - they make it very easy to organize the communication. You have channels and they contain topics. This is one of the most useful features of Zulip.

Most features of all chat clients (riot, slack, mattermost, rocket.chat, zulip) are pretty similar.

</comment></comment><comment><USER22> last large discussion of Zulip (6 months ago): [https://news.ycombinator.com/item?id=16863675](https://news.ycombinator.com/item?id=16863675)

</comment><comment><USER23> We looked at it briefly, but the number of components make it look more of a tech demo than a product meant to be installed on-prem.

Redis, Postgres, Rabbitmq and Memcached just to run a chat?

<comment><USER24> > more of a tech demo than a product

It is neither a tech demo nor a product, it is a mature open source project.

In fact, in my mind tech demos tend towards having fewer mature components.

> Redis, Postgres, Rabbitmq and Memcached just to run a chat

That set of dependencies seems quite normal to me for a mature project. Mastodon (the most popular open-source-twitterish-thing) has a similar set of dependencies, and is also effectively just chat as you say.

Discourse, a popular open source forum, is also basically just chat, and has a similar set of dependencies.

In the case of zulip, you can even use a hosted version and avoid running anything yourself.

I don't understand why its totally normal set of dependencies turns you off so harshly. I'll happily take a project using redis/postgresql/etc instead of trying to build its own versions of those baked into the binary because components like postgres/redis/etc have great documentation, tooling for metrics and monitoring, etc... If the project bakes its own stuff in itself to avoid taking on dependencies, I doubt it will either be as good or as easy to manage.

<comment><USER25> IMO it would be nice to have scaled-down implementations of caching, queueing, etc. for "small" installations of self-hosted apps to reduce the number and complexity of dependencies. But first there would have to be a market for self-hosting.

</comment></comment></comment><comment><USER26> As I commented here [1], one of my biggest issues with Zulip is that the mobile apps don't have a "jump to most recent" feature, and whenever I open the app I have to manually scroll past hours (or days or weeks, since I dislike opening the app so much) of old conversations.

Has this been fixed/improved?

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

<comment><USER27> The mobile app does a "jump to the first unread message" by default, which is the same behavior the web app follows. If you don't want to read through all the messages in the current stream you can press "Mark as read" and then the app will be jumping you to the latest messages. Would that improve your navigation flow in the app?

</comment></comment><comment><USER28> How does it compare to mattermost?

<comment><USER29> Exactly.

We're looking at paying for Slack and mattermost seems to offer most of what Slack does and is something that would be pretty easy to run. It's slick. Well documented and installs nicely in a container.

Has anyone here used Mattermost?

[https://mattermost.com/](https://mattermost.com/)

<comment><USER30> Have you tried out Zulip? You may find the user experience pretty compelling. It's an entire alternative interface to the slack or IRC-style of chatrooms, and it's OSS and documents how to make it containerized.

<comment><USER29> Not yet.

Both mattermost and zulip look well worth it for saving quite a bit of money over slack for a fair sized company though.

The responses from people here are really interesting.

</comment></comment></comment></comment><comment><USER31> The one good thing about not having an on-prem Slack is communications after your company network goes down.

<comment><USER32> The one good thing about having an on-prem Slack is communications after the Slack network goes down.

<comment><USER33> That's why you should run both.

<comment><USER34> Or print out all your conversations.

</comment></comment></comment></comment><comment><USER35> Anybody knows why this over rocketchat?

<comment><USER36> Zulip has a thread based Instant messaging model which helps facilitate multiple different conversations in the same channel without losing track / context.

More on their homepage - [https://zulipchat.com/](https://zulipchat.com/)

<comment><USER37> What is the advantage of threads over just more specific top level channels. e.g. in their example why not #annual-summit-name-tags etc. One immediate thing slack does wrong is it makes channels too hard to make and destroy and leave and join, but if that was fixed... What is the advantage of the nesting?

<comment><USER38> zulip ends up being a bit like e-mail where you can add people to threads and they immediately have the history. I've used mattermost, not slack, but that basic model fixes a lot of issues I have with mattermost.

<comment><USER37> A more specific slack channel (and I assume mattermost channel) is a thread that you can add people to any time and they will immediately have history. Or put in the inverse, a Zulip thread that is too general is a channel with information overload and becomes useless. Does the nesting have intrinsic value over simply more top level channels?

<comment><USER38> Mattermost has threads inside channels as well, but they end up underused since posts need not be to any specific thread.

The idea is you subscribe to a channel, but then any post to the channel needs to also have some sort of logical subject.

<comment><USER4> Right, in my view it's important that every message have a topic/thread. The reason is that you spend most of your time/effort in a busy team chat tool consuming other people's messages, and that flow is a lot more efficient if you don't have a giant "catch-all" bucket of unthreaded messages about fundamentally different things to wade through in order to find what's important to you.

Zulip, used well, ensures that the messages are partitioned into different conversations, so you can easily do things like skip to the bottom of a long thread to see if it ends in a satisfactory resolution, without missing the unrelated question that you need to answer.

</comment></comment></comment></comment></comment></comment></comment><comment><USER39> Judging from the zulip.org server it looks like there is a need for a chronological topic decay feature.

<comment><USER4> Zulip founder here; I'm curious why you think that?

Here's our thinking. Topics within a stream are ordered by the time of the most recent message. We keep the complete history, both of messages and topics, because it's useful for search and following up on things. Personally, I regularly reply to a conversation whose last message was a month or more ago to follow up with new information (often after getting there from one of the permanent links in our issue tracker). Because the context is all there and available with just a single click on the topic, I find it to be a really nice workflow.

<comment><USER40> Hi there! I just started using Zulip (first-time user) looking forward to migrate off Slack and unfortunately I've been really disappointed. In Slack I can just load the website and begin typing into whatever channel I'm at (or use 1 click to select the right one if it's not the current one). In Zulip, it seems there's been a deliberately goal of explicitly designing it to be excruciating painful. For some reason Enter doesn't work by default (in which chat system is Enter an unfamiliar command for sending?!), and then I _always_ have to press 'R' or click something to reply to (which often takes multiple clicks and several seconds)... why make things deliberately complicated/painful without even an option to turn off this 'feature'?

<comment><AUTHOR> Slack and Zulip are implementing pretty different communication models.

In Slack, most messages are a single line, and are very real-time. E.g. if a channel is getting 100 messages a day, and a conversation starts in the morning, you're not going to try to engage with that conversation even that afternoon.

In Zulip, communication is asynchronous by default. This has a lot of secondary implications; e.g. it means that by default you can assume people will see your message, rather than just the people that check in the next few hours. This means you can have substantive discussions on the platform, and the medium correspondingly encourages more multi-line, thoughtful posts. So we've currently decided that having to type an extra letter to compose is worth the tradeoff.

As an example, not having compose open by default allows us to use single letter keyboard shortcuts for navigation.

In any case,

* You can enable "Enter to send": [https://zulipchat.com/help/enable-enter-to-send](https://zulipchat.com/help/enable-enter-to-send)

* Private Messages (called DMs in Slack) in Zulip work the same way they do in Slack, with an open-by-default compose box.

<comment><USER40> Thank you for the reply!

If this is the intention, then I'm baffled at how you intend your product to be used. Your advertisement of Zulip is completely at odds with... its fundamental principle? What I mean is, your website says _" Zulip combines the immediacy of real-time chat with an email threading model"_, but it seems you're explicitly designing _away_ the immediacy and requiring people to spend significant time thinking about what to type and clicking around to find the appropriate thread to reply to, just like with email. It can't function as a team chat system if it doesn't facilitate instant messaging -- "chat" systems are designed pretty much by definition to allow instant communication. (Like what "chatting" meant, before computers were around.)

What you really seem to have is a shared-inbox email service -- kind of like a mailing list, but in a shared workspace, which would produce something that's more close to the exact opposite of your description... something like: _" Zulip combines the deferred/asynchronous model of email with the shared-inbox nature of a mailing list"_.

So here's my question: what do you expect teams to do when they actually need _instant_ communication with the rest of the team? Do you expect them to have another (actual) chat system in parallel for that, or do you intend a model where you intentionally insert obstacles to make that viable somehow? I'm not talking about stuff you'd put in a email, so I'm not talking about something like _" Let's discuss item 2 on the design doc. I think it would be better to approach the problem by doing X, then Y, then Z. This benefits us because Y helps us with Z and [blah blah]."_ I'm talking about stuff where there is something urgent going on and immediacy is the #1 priority, like _" can s/b urgently cover me here I gotta run"_ or _" what's up w/ the projector in C13?? I have a meeting"_ or _" who's covering the slot rn? s/b's waiting"_ \-- you know, the day-to-day stuff where the extra 10 seconds finding the right topic to reply to and the extra O(minutes) trying to articulate an eloquent email- like message for your team is going to tick everyone off (especially outside clients etc.) rather than please anyone. This kind of immediate communication is what teams need instant messaging systems like Slack for -- if your software is explicitly designed to discourage it, what do you imagine continuing to fulfill this need after teams switch to Zulip -- another parallel Slack?

<comment><AUTHOR> Got it, thanks for the concrete examples.

I think the short answer is that there is some learning curve to using Zulip, but once that's done, sending messages like that takes essentially the same amount of time it would in another product.

The actual extra actions are:

* up to one extra keystroke to open the compose box

* typing a subject line like "projector C13"

You wouldn't have to search for a topic to send a message like that; you would just start a new topic. And "what's up w/ the projector in C13?? I have a meeting" would still be a perfectly fine Zulip message.

And then on the receiving end, you actually save a bunch of time.

* There's a simple keyboard shortcut ('n') to see the message that just came in.

* The fact that there's a subject line means that everyone sees "projector C13" and decides if they're a person that can respond to that, even if they aren't caught up on the rest of the channel.

* If someone does respond, you can see that they responded to your message, and not to some other conversation that's going on in the channel. That makes it easier to keep an eye on the conversation while the rest of you is improvising a solution.

<comment><USER40> > I think the short answer is that there is some learning curve to using > Zulip, but once that's done, sending messages like that takes essentially > the same amount of time it would in another product.

The thing I don't get here is you have two competing claims/goals, both of which I could buy in isolation and in fact agree are perfectly reasonable goals, but both of which actively contradict & fight against each other. On one hand you believe it'd take the same amount of time as before if people would only learn to use the system as designed (which I'll take at face value here), but on the other hand you say "the medium correspondingly encourages more multi-line, thoughtful posts". Writing more thoughtful messages and coming up with subject lines _by definition_ requires more time... how can it not?

<comment><AUTHOR> I agree that on the benchmark of time-to-send-a-message, Zulip is slightly slower than Slack, which is in turn slower than just putting the whole company in a WhatsApp group.

But the end goal is not sending messages, the end goal is getting the person who knows about the projector to see your message and respond, for you to see that response, etc.

In a moderately sized company, Slack is better than the WhatsApp solution, since you can direct the message at roughly the correct set of people, by spending the extra time to choose a channel. In turn, those people are more likely to get the message in time to act on it, because the message won't be buried under tons of messages meant for other people in the company.

Zulip takes that a step further, by adding subject lines to messages. The same tradeoff applies.

I think in the end the question really is how much more work it is to add the extra signal. The best case would be you could send messages like in WhatsApp (no subject line, and every message goes to the entire company), and read messages like in Zulip (subject lines, and with channels limiting audience). For both Zulip and Slack, the premise is that we can drive down the cost of adding the extra signal to low enough.

</comment></comment></comment></comment></comment></comment></comment></comment><comment><USER41> Am I the only one that just can't stand the way zulip looks?

I really don't understand it myself, since it looks more or less the same as other apps, but my instinctual reaction is still 'yuck!'.

<comment><USER12> The first time I saw it I had the exact same reaction. Using it I encountered two things:

\- The UI looks better the more streams you are subscribed to

\- The UI just "works"

I'm still not sure if the UI works because it is not distracting me with good looks ;)

</comment></comment><comment><USER42> For me the most severe lacking feature of Zulip vs Slack is that you cannot mark messages as unread.

</comment><comment><USER43> New to Zulip. So is it sponsored by Dropbox now after acquisition of Zulip Inc.?

On the bottom of the page, it reads:

      Tim Abbott is the lead developer of the Zulip open source
      project. He previously was CTO of Ksplice and then Zulip
      Inc. (before it was acquired by Dropbox).

<comment><USER4> Yikes, we haven't updated my blog bio in a while. Fixed to remove the confusing reference to Dropbox (which no longer has any formal involvement in Zulip); [http://zulipchat.com/history](http://zulipchat.com/history) has further context for anyone curious.

</comment></comment><comment><USER44> We are heavy Slack users. We tried Zulip. No one in the team liked the ergonomics of Zulip and how difficult it was to integrate. Just for threaded discussions we felt the switch was not worth it. It didn't stick and we stayed in Slack.

<comment><USER41> Might want to look at [https://twist.com/home](https://twist.com/home)

It seems a bit like a slakey zulip to me, though I haven't had opportunity to use it yet.

<comment><USER45> No self hosted option :(

</comment></comment></comment><comment><USER46> As someone who follows technology closely, I find it a bit frustrating that chat is making such little progress, and that for our communication we've essentially moved from federated email to silo-based chat solutions (which is hardly a feature), and lock-in that comes with these. How is "IT" going to save the world if we get stuck like this as a profession? I suspect one problem is that at universities there is no credit to be earned from coming up with a chat protocol that can serve us the coming decades, and hence we're stuck with solutions from corporations and their inherent problems ...

But of course that's not to say that there is anything wrong with the quality of the product being promoted here.

<comment><USER47> For what it's worth, Zulip is one of a few projects to support federated chat. From the linked document:

"Zulip now has an IRC bridge powered by matrix.org"

<comment><USER46> Yes, they probably support email as well, that's not the point.

See: [https://en.wikipedia.org/wiki/Embrace,_extend,_and_extinguis...](https://en.wikipedia.org/wiki/Embrace,_extend,_and_extinguish)

(not saying this is the case here, just that it shouldn't be a concern)

</comment></comment></comment><comment><USER48> We looked at it, wanted to like it, but for self-hosted there were problems with app notifications, something that plagues most self-hosted hipchat replacements (except for xmpp).

<comment><USER4> When did you look? [https://zulip.readthedocs.io/en/latest/production/mobile- pus...](https://zulip.readthedocs.io/en/latest/production/mobile-push- notifications.html) has been available for over a year, so self-hosted has the same notifications experience as Zulip Cloud.

<comment><USER48> It relies on Zulip's central notification service, so not entirely self- hosted.

<comment><USER45> At the bottom of that link[1] you can find instructions on how to send notifications directly from your server, but it involves recompiling the apps (which is hardly Zulip's fault).

[1] [https://zulip.readthedocs.io/en/latest/production/mobile- pus...](https://zulip.readthedocs.io/en/latest/production/mobile-push- notifications.html#sending-push-notifications-directly-from-your-server)

<comment><USER48> Yes, this was covered under our evaluation, I appreciate it's not your fault.

For what it's worth Zulip was at the top of our list when we evaluated hipchat replacements. Happy to look at it again if you ever will have direct notifications.

<comment><USER49> What zingmars wanted to say is that it's not possible to have "self hosted" notifications without recompiling the Android and ios Apps.

</comment></comment></comment></comment></comment></comment><comment> rob-olmos If anyone has tried G Suite Chat, it looks like they've added "threads" at some recent point but the UX has some ways to go.

</comment><comment><USER50> I also recommend RocketChat

[https://rocket.chat/](https://rocket.chat/)

<comment><USER51> Depends on your security requirements: [https://github.com/RocketChat/Rocket.Chat/pull/10793#issueco...](https://github.com/RocketChat/Rocket.Chat/pull/10793#issuecomment-395195356)

<comment><USER50> What is your affiliation with RocketChat?

</comment></comment></comment><comment><USER52> How well does the Hangouts integration work? I found it involved too many steps when using Hangouts in Slack

<comment><USER4> It's pretty simple: There's a button you can click at the bottom of the compose box that generates a new Hangouts video chat link; once oyu send your message, users can click the link to join.

</comment></comment><comment><USER53> Title is somehow linking to the blog instead of the actual product page ([https://zulipchat.com](https://zulipchat.com)).

<comment><USER54> Because it's an announcement of a new version. Not that hard to figure out.

</comment></comment><comment><USER55> I mistakenly assumed there wasn't a paid offering.

So it's becoming clear that the only revenue model going forward is open core model.

<comment><USER25> It looks like the paid edition of Zulip is the same as the open source version so it's not open core. Of course if Zulip becomes too popular then we may see AWS GroupChat followed by a license change...

<comment><USER56> AWS already has Chime. They don't need anything else.

</comment></comment></comment><comment><USER57> Whaaat!? I who always thought irc was the on-prem Slack alternative. Its a pretty cool thing that recently got created (around 1988). Try it out! Will blow you mind straight out of the water tbh. There's even some public chat rooms you can hang around in.

<comment><USER58> IRC: No code-block formatting. Can't even receive messages when you're offline, out of the box. No message delete/edit. No built-in file hosting, must upload elsewhere and link it. No drag-and-drop. No real ergonomics in general. Way behind on community-building/-management features. Only particularly liked by the sort of person who considers tweaking their .conkyrc as a Friday well-spent.

I hang out on freenode every day. But I have higher expectations of chat in 2018 when it comes to what I would choose for an actual organization. So does everyone else.

IRC isn't blowing anyone's mind. Especially that first time they try to reply to someone but their message is never received because the other person closed their laptop.</comment></comment>


Two-hundred-terabyte math proof is largest ever - <AUTHOR> http://www.nature.com/news/two-hundred-terabyte-maths-proof-is-largest-ever-1.19990 <comment><USER2> Darn, I had no idea one could get into the media with this kind of stuff.

I had a much larger "proof", where we didn't bother storing all the details, in which we enumerated 718,981,858,383,872 semigroups, towards counting the semigroups of size 10.

Uncompressed, it would have been about 63,000 terabytes just for the semigroups, and about a thousand times that to store the "proof", which is just the tree of the search.

Of course, it would have compressed _extremely_ well, but also I'm not sure it would have had any value, you could rebuild the search tree much faster than you could read it from a disc, and if anyone re-verified our calculation I would prefer they did it by a slightly different search, which would give us much better guarantees of correctness.

<comment><USER3> I have a question about computer-generated proofs, as I am doing something similar.

When you encode the search tree as a proof, is there a technical name for that technique?

In my situation I encoded the proof as a sequence which is just the depth- first linear labelling of the tree. Then I proved why the sequence represents a proof. But if there is a most standard terminology/literature on this step, it would make it easier for me to talk about.

<comment><USER2> I've had a similar problem, there is nothing that useful I'm afraid. Probably best to look into general discussions of trees.

One thing worth trying to do (if you can) is separate the generation of the tree from the tree itself -- hopefully you can imagine the tree existing as a complete object (even though you never store it all), and formulate proofs based on that.

</comment></comment></comment><comment><USER4> Probably the code used to generate the 200TB was not 200TB itself, right?

So in a sense, the code is the proof, and the 200TB is just something it generates as a side effect.

<comment><USER5> In fact you can encode any proof to a few hundred lines. Just write a program that brute forces through all possible proofs. If that counts, then no proof need be longer than it's conjecture plus a constant.

<comment><USER6> I'm not sure: doesn't the halting problem apply to this? In other words, can you write such a brute force program that is guaranteed to halt after a finite number of steps, providing a yes or no? I guess not.

<comment><USER7> It doesn't, and it's interesting why. You can enumerate all possible proofs. If there is a proof of a given statement, you will eventually find it. But if there is no proof, you will never know, because it always could be the next proof you haven't looked at.

For the same reason, for any program that halts, you can run it long enough, and see that it halts. But (unless you are lucky enough to detect a loop), if it doesn't halt, you will never witness that, you will only be able to say "it hasn't halted yet".

It definitely can take a while until that kind of asymmetry becomes intuitive.

<comment><USER6> > But if there is no proof, you will never know, because it always could be > the next proof you haven't looked at.

But that's exactly what I meant. So the brute force program proposed in the post I replied to doesn't exist, right?

Let's say, you have proposition A. You write a program to brute force proofs for A. If it finds a proof, it will halt and output Yes, if it finds a disproof it will halt and output No, otherwise it will check the next proof.

So if you say that your brute force program can proof/disproof proposition A (and A1, A2, A3, ... for that matter), you will have to proof that your program will halt for sure after a finite number of steps. Now that's proposition B.

If you find a clever proof for proposition B, then you can claim that you wrote a program that can proof or disproof proposition A - maybe in a zillion years, but it can.

If you can't find such a proof for proposition B, you can always try to write a brute force program to proof/disproof proposition B... then C, D, E, etc. :)

And here comes the halting problem: you may be able to proof that a specific program will halt on a specific input, but it can be very hard to proof. But you can't proof that a specific program will halt on every input. This is directly related to Godel's incompleteness of formal systems.

<comment><USER8> Every conjecture that is provable can be proved by the proposed program of length (conjecture + constant) in finite time.

That was the original statement:

> you can encode any proof to a few hundred lines.

This type of encoding is funny of course. You can not determine from the encoding of the proof whether the encoding is the encoding of a proof (as you point out). But if you have a proof, and thus know that a proof exists you can "encode" it very succinctly in this program for whatever that is worth.

<comment><USER6> > you can encode any proof to a few hundred lines.

Yeah, I misread that. The sentence implies the existence of a proof. So I was clearly talking about something different. Thanks.

</comment></comment></comment></comment></comment></comment></comment><comment><USER9> There is an increasing appreciation that large proofs need "proof engineering" that is similar to software engineering. See e.g.

\- D. Aspinall, C. Kaliszyk, Towards Formal Proof Metrics.

\- G. Klein, Proof Engineering Considered Essential.

\- G. Gonthier, Engineering Mathematics: The Odd Order Theorem Proof.

\- T. Bourke, M. Daum, G. Klein, R. Kolanski, Challenges and Experiences in Managing Large-Scale Proofs.

<comment><USER10> Links, unfortunately non-free:

Towards formal proof metrics: [http://link.springer.com/chapter/10.1007/978-3-662-49665-7_1...](http://link.springer.com/chapter/10.1007/978-3-662-49665-7_19)

Proof engineering considered essential: [http://link.springer.com/chapter/10.1007/978-3-319-06410-9_2](http://link.springer.com/chapter/10.1007/978-3-319-06410-9_2)

Engineering mathematics: [http://dl.acm.org/citation.cfm?id=2429071](http://dl.acm.org/citation.cfm?id=2429071)

Challenges and experiences …: [http://link.springer.com/chapter/10.1007/978-3-642-31374-5_3](http://link.springer.com/chapter/10.1007/978-3-642-31374-5_3)

</comment></comment><comment><USER11> A relevant article on large proofs: [http://gallium.inria.fr/blog/large- proofs/](http://gallium.inria.fr/blog/large-proofs/)

</comment><comment><USER12> "but when you reach 7,825, it is impossible for every Pythagorean triple to be multicoloured"

So they didn't know in advance how long it was going to take or the size of the output?

<comment><USER13> Correct. They didn't even know if there was a finite number where colouring became impossible, but it was strongly believed there was such a limit. Privately, people had their own ideas - sort of Fermi estimates. I don't know anyone who made such estimates public.

</comment></comment><comment><USER14> I think "brute force math" would be a good name for this technique --- that diagram reminds me of finding hash collisions:

[http://www.links.org/?p=6](http://www.links.org/?p=6)

</comment><comment><USER15> Is the data compressed and piped into a known compression algorithm, or is there some other technique used? I'd love to know how the actual program is run. Side note... the visual output is really interesting to see, and I'll admit I crossed my eyes at it to see if I could see some sort of pattern (read: there was no sailboat).

<comment><USER16> The authors used this tool:

[https://www.cs.utexas.edu/~marijn/drat- trim/](https://www.cs.utexas.edu/~marijn/drat-trim/)

There are publications and examples on the website that explain how the compression the authors used works.

</comment></comment><comment><USER17> > _Although the computer solution has cracked the Boolean Pythagorean triples > problem, it hasn't provided an underlying reason why the colouring is > impossible, or explored whether the number 7,825 is meaningful, says > Kullmann._

Kind of reminds me of why we were always taught to avoid proof by induction (the mathematical kind[0]) when possible.

Also, funny coincidence, but the shortest math paper published in a serious journal[1] was also a "no insight into _why_ " kind of proof.

[0] [https://en.wikipedia.org/wiki/Mathematical_induction](https://en.wikipedia.org/wiki/Mathematical_induction)

[1] [http://www.openculture.com/2015/04/shortest-known-paper- in-a...](http://www.openculture.com/2015/04/shortest-known-paper-in-a-serious- math-journal.html)

<comment><USER18> That's the problem with counterexample proofs, though. If something is only true for a large-but-finite range of numbers, there might not be a satisfying reason why.

</comment></comment><comment><USER19> If you verified the code performed the correct function, ensured it ran correctly and computed the result, then the code itself serves as most of the proof (not the 200TB). Really what you want to be peer-reviewed is the code, not the swathes of data.

<comment><USER16> _> If you verified the code performed the correct function, ensured it ran correctly and computed the result, then the code itself serves as most of the proof_

But then you have to trust their program doesn't have any bugs, and checking the proof requires a lot of computational power.

Instead, the authors produced a very large input file to a very small program. This way, instead of trusting the program they used to produce the input file, you only need to trust:

1) the input file corresponds to the theorem statement in their paper; and

2) the certificate checking program is correct

The benefit of this approach over the one you suggest are numerous:

* The effort of part 2 amortizes and isn't specific to any particular problem.

* The computational cost of re-checking their proof is considerably smaller than the cost of finding the proof certificate, allowing for the proof to be re-checked by anyone with a bit of spare computing power (as opposed to requiring a super computer in order to replicate the result).

<comment><USER20> > But then you have to trust their program doesn't have any bugs

This is no different from a typical math paper. Proofs can have "bugs", too; and sometimes they're fatal. That's -- in theory -- one of the points of peer review.

<comment><USER16> _> This is no different from a typical math paper_

It's substantially different from a typical math paper.

First because programs are typically much larger than even large mathematical proofs (more on this below).

Second, because even after you trust the program, you then still have have to _run the program_ to make sure the paper's result is correct. Far better to run the program _once_ and then produce something you can _check quickly_ than to require every peer reviewer to buy hundreds/thousands of dollars of compute time. Think P vs. NP: why force the reviewer to solve an NP problem when you can just as easily hand them a P problem.

 _> Proofs can have "bugs", too_

But the reviewer's bug checking obligation is typically isolated to the paper at hand; i.e., the reviewer doesn't have to worry about the correctness of cited papers -- it's assumed those results are correct. By contrast, software implementations -- even for purely mathematical code -- often contain tens of thousands of lines of implicitly trusted code [1].

Reviewers therefore (rightly!) say of ad hoc programs submitted as a portion of a proof: "sorry, I can't possibly know whether there are any important bugs in these tens of thousands of lines of code upon when you depend".

As a result, the SAT and theorem proving communities have developed highly trustworthy proof checkers so that the portion of code the reviewer has to trust can be meaningfully peer reviewed (and, more-over, peer reviewed apart from any particular theorem).

[1] This is true even if you don't include things like the underlying operating system. Standard libraries, mathematics packages, compiler implementations, solver implementations, specialized software packages for the application domain, etc. etc. Some of this software a reasonable person will trust, but some of it really isn't interrogated well enough for the purpose of mathematical proof... and even just sorting out what's trustworthy and what's not can take a significant amount of time.

</comment></comment></comment></comment><comment><USER21> Surely the value of this is that it provides a counterexample to a long- standing conjecture. The proof that it is a counterexample may not be too enlightening, but that's hardly the point.

</comment><comment><USER22> This isn't mathematics, this is data analysis.

A mathematician doesn't come up with a research where he says: "Ei look, we are now extremely confident that this theorem applies in every case... we don't have a full mathematical proof for it but I can show you all these cases where it holds true."

No, a mathematician proposes a result and then goes on to prove or disprove mathematically that it holds true under specific conditions in absolutely every case where those conditions are met.

<comment><USER23> IANAMathematician, but, a brute force proof is still a proof though, isn't it?

If I have the theory, that all positive integers smaller than 5 are also smaller than 6, I would assume I'm mathematically allowed to 'brute force' the proof by enumerating all the numbers > 0 and < 5 and then testing for each that it's also < 6.

If I can prove I enumerated all the positive integers smaller than 5 and didn't find any exceptions, I guess I proved my theory...

It's a silly way to prove my silly theory, but it is a proof. (I have also a truly remarkable proof, which this comment is too small to contain. ;) )

<comment><USER24> Computer assisted proofs are historically frowned upon because you eventually end up in a black box you have to blindly trust. Can you verify that your code is correct according to the language spec? Can you verify that your compiler is bug free and follows the spec? Can you verify that your CPU is bug free and runs the output from your compiler correctly? Can you verify that your storage medium is correct and hasn't corrupted any of your intermediate results etc. etc.

Practically people will eventually say that if your test has been run N times using M different compilers and P different computers and they all give the same answer then you're probably correct, but having a proof that humans can reason through from beginning to end makes people feel more comfortable.

That being said computer assisted proofs are becoming more and more common and mathematicians are getting more and more comfortable with them as the verification tools surrounding them keep getting better. And even if computers aren't used for the final proof they are often used for intermediate tests. For example if you're making a statement about all primes it makes sense to quickly test the first few hundred million primes to make sure there aren't any obvious counter-examples.

<comment><USER25> >it makes sense to quickly test the first few hundred million primes to make sure there aren't any obvious counter-examples

It's kind of absurd the sorts of endeavors which computers have rendered not only possible, but relatively trivial.

</comment></comment></comment></comment><comment><USER26> I have discovered a truly marvelous demonstration of this proposition that this margin is too narrow to contain.</comment>


It's Not Just Writing: Math Needs a Revolution, Too - <AUTHOR> http://www.theatlantic.com/national/archive/2012/10/its-not-just-writing-math-needs-a-revolution-too/263545/

<comment><USER2> It is extremely true that mathematics curricula for schoolchildren in general require reform, and most mathematicians will agree on this point. The problem with previous attempts is that they have been designed by people who do not fully understand mathematics and executed by the same. The by now infamous example of the "New Math" was satirized by popular culture because _everyone_ seemed to miss the point. <http://en.wikipedia.org/wiki/New_Math>

While pieces like the well-circulated "A Mathematician's Lament" (PDF: <http://www.maa.org/devlin/lockhartslament.pdf>) by Paul Lockhart argue that the mathematics taught to schoolchildren ought to resemble "real math", the sort of math that mathematicians think of as math (with theorems and proofs and much less of an emphasis on computation), they neglect the unfortunate reality that compulsory childhood education still exists largely towards a pragmatic end. Children must be able to compare prices at the grocery store and be able to reason about quantities.

Hung-Hsi Wu has done a great deal of work into how to fix the mathematics curricula of today. This is in contrast to the revolutionary approach that we have tried and failed at. His work focuses largely on fixing specific weaknesses in the core standards and fixing the _way_ mathematics is taught, rather than what is actually being taught, in many cases. <http://math.berkeley.edu/~wu/>

In addition, Pólya's _How To Solve It_ is the sort of text that teachers should read and become familiar with, in order to better understand how to teach problem solving, which is much of what mathematics at the grade school level is - instruction in problem solving. In fact, I would recommend it to every HN member - it's a wonderful little book about the art of solving problems, mathematical or otherwise. <http://press.princeton.edu/titles/669.html></comment>


Charlie Stross on iPad Writing - <AUTHOR> http://www.antipope.org/charlie/blog-static/2011/12/why-i-dont-use-the-ipad-for-se.html#more

<comment><USER2> I recently got an android phone and I've been deeply impressed by Swype, which is an interesting idea. You put down your finger and move it over they keys you want to press without lifting it until the end of the word. The system then uses a lot of machine learning techniques to figure out what word you were going for. It works far better than I think it has any right to, and when typing english text i can now get pretty impressive speeds. I don't know about wpm, but I'd say it's pretty much the same speed that i can type with one hand on a normal physical keyboard.

I think this is one important area where Android is far ahead of (non- jailbroken) iOS.

<comment><USER3> I also recently purchased an Android phone and have been very impressed by the accuracy of Swype. However, I notice that in landscape mode, because of having to move through a larger region, input entry slows down significantly. I find myself always switching to portrait mode for text entry (with a 4.3'' screen phone).

I wonder what the experience is on tablets where non-swype entry becomes _easier_ as the keyboard size increases (unlike, in my experience, what happens with swype).

</comment></comment><comment><USER4> This criticism holds for Android devices also (including the Kindle Fire)

At least my old HTC Incredible had an optical joystick that made text navigation much easier.

Please device designers take note: FINGERS ARE NOT PRECISE ENOUGH FOR TEXT SELECTION!!!

 __at least adult male fingers...

</comment><comment><USER5> I wonder if vim would work on the iPad.

</comment><comment><USER6> He's right about positioning the cursor. It currently sucks, really really badly.

</comment><comment><USER7> +1 for emacs mention</comment>


Why No Science of Nerds? - <AUTHOR> http://slatestarcodex.com/2014/09/25/why-no-science-of-nerds/

<comment><USER2> Quote: "Of these nine classic characteristics, we can imagine people scoring either "nerdy" or "anti-nerdy" on each. If that were true, there's only a 1/2^9 = 1/512 chance that any given person has all of these characteristics."

Not if the traits are correlated with each other. The chosen binary math treatment works only if the traits are independent, i.e. mutually orthogonal. They aren't -- nerdy traits are strongly correlated, so much so that if you find any five of the nine traits in an individual, you're most likely already done identifying a nerd.

Also, there's a more efficient way to express a fractional probability: 1/a^b = a^-b.

<comment><USER3> It was perhaps badly put, but the author is obviously aware of that, as shown by the paragraph immediately thereafter, in which the possible correlation of the variables is discussed.

It is true that there is a certain amount of informality in the wording of the quoted paragraph, however. I agree that the author shouldn't have glossed over it. He does clarify later though, which makes the whole thing not so much of a big deal, especially as it's the very next paragraph.

<comment><USER2> Yes, true, but the irony here is that the introductory paragraph is itself a nerd litmus test. No nerd deserving the title would accept it as written.</comment></comment></comment>


LG Unveils Internet-Connected TV Running WebOS Acquired From HP - <AUTHOR> http://www.businessweek.com/news/2014-01-06/lg-unveils-internet-connected-tv-running-webos-acquired-from-hp

<comment><AUTHOR> My take is that they simply want independence from Android. Maybe no longer possible in phones, but they could make a go in TV.

There were reports of bad behavior from LG w.r.t smart TVs [1].

[1] [http://arstechnica.com/security/2013/11/smart-tv-from-lg- pho...](http://arstechnica.com/security/2013/11/smart-tv-from-lg-phones-home- with-users-viewing-habits-usb-file-names/#p3)</comment>


Record-Breaking Amateur Rocket Launch - <AUTHOR> http://www.popularmechanics.com/home_journal/workshop/4315103.html?nav=RSS20&src=syn&dom=yah_buzz&mag=pop <comment><USER2> An acquaintance of mine is building a rocket of roughly the same size. But with two important differences:

1) It will go into space (defined as 100 kilometers above the surface of the Earth)

2) He will be aboard

He recently finished building the worldst largest amateur submarine, so I think there's a pretty good chance he's going to pull it off. They plan to launch from a barge in the North Sea, and have apparently just gotten the official go-ahead from various agencies. The boosters will run on pure oxygen and epoxy, and they have had multiple successful booster tests.

<http://www.copenhagensuborbitals.com/>

<comment><USER3> That is just plain awesome. This is the type of Hacker/Tweaker/Discoverer attitude that makes me smile from ear to ear.

<comment><USER2> Interestingly he is doing it all basically without any money, just a lot of smart and dedicated people. He also says that his biggest problem isn't technical, it's getting all the official licenses, approvals and documents in order. The government doesn't really know what to do when some guy calls up and asks if it's OK that he fires himself into space from a home-made rocket.

<comment><USER4> Surely it's not too different from what Scaled Composites had to do when they built/launched SpaceShipOne. (Yes, stationary launch is different from air- launched, but the regulatory approvals as I understand them have to do with _space_ , not ground launch.)

That of course doesn't mean it's not a pain in the ass...

<comment><USER2> They are currenly thinking about using the submarine to tow the barge with the rocket from Copenhagen to the North Sea, and just getting that journey approved is a huge problem. The department of defense seems to have a negative opinion about a submarine towing a huge rocket through Danish territorial waters :-)

There are many obstacles like that.

</comment></comment></comment></comment></comment><comment><USER5> I was there at the launch!

Some of the ingenuity that went into building a model rocket of this size is remarkable. Talking to some of the folks involved afterwards, it turns out that the mechanism to separate the rocket into two parts at apogee was built from car seatbelt tighteners and an airbag.

It was heartening to see how many people showed up -- easily a thousand or more.

</comment><comment><USER6> I submitted another article about the same rocket a week ago, if anyone is interested: <http://news.ycombinator.com/item?id=571971>

</comment><comment><USER7> The space elevator can probably use some amateur innovatordom, although I don't know how if at all that is possible. I have the impression that no matter how good the amateurs get, boosters will always be a colossal waste of fuel. Cool factor 1, space advancement factor 0.

<comment><USER8> This is a bit off topic but I always thought the easiest way to build a space elevator was from space lowering it down to the planet. Not building it ground up.

That being said I'm all about more amateur involvement and less regulations. Or to say it another way, regulations should not be the limiting factor like it is today.

<comment><USER9> I think it's the only way to make them. You start at a geosynchronous orbit and play out a cable towards earth and another as a counterbalance towards outer space. The counterbalance can be used to launch payloads towards the planets.

</comment></comment></comment><comment><USER10> That's awesome! I used to launch model rockets in the early 90's at a De Anza College parking lot.

</comment><comment><USER11> wright brothers 2.0</comment>


International System of Units overhauled in historic vote - <AUTHOR> http://www.npl.co.uk/news/international-system-of-units-overhauled-in-historic-vote <comment><USER2> See, the US wasn't being stubborn in not adopting metric, it was just waiting patiently for it to progress from beta to 1.0. :)

(Fun fact: all the US customary units have been officially defined in terms of their metric counterparts since 1893: [https://www.nist.gov/sites/default/files/documents/pml/wmd/m...](https://www.nist.gov/sites/default/files/documents/pml/wmd/metric/1136a.pdf))

<comment><USER3> I'm one of the weird people that actually _really_ likes imperial units. For instance:

1 foot -- base 12. This is a superior base to 10. It can be easily divided into 4ths, 3rd, and 2nds. Base 10 can only easily be divided into 2nds.

1 inch -- an easily identifiable unit of measure for smallish things. About the width of my thumb. A pretty good unit.

For low precision, inches become 1/2, 1/4, 1/8, 1/6, 1/64, etc. Each one is half the size of the previous one. I actually like this one a lot. An eight being half of a quarter is a really easy way to work with things when you're building stuff. Think about drilling a bolt hole in the center of a piece (half the width), or drilling two bolt holes with something in the center (divide those halves in half again) etc. Fractional is really good for building stuff.

For precision: thousands of an inch. Harder to visualize, but precise (has the same problems as mm imho). Millionths of an inch when you get into serious metrology.

Okay temperature: In imperial units:

0 = REALLY cold. 100 = REALLY hot. 50 = somewhere in the middle. Put on a sweater, but not dangerous.

100 = about the temperature of a human body.

Water boils at 212F and freezes at 32F. There are 180 degrees (degrees!) between freezing and boiling. 180 is, again, base 12. It's the 15th order of 12.

I actually _love_ imperial units. I greatly prefer them to metric (even though I do use metric very frequently, and can see the appeal). I think I just actually prefer base 12 to base 10.

I also think that F is seriously superior to C.

<comment><USER4> You are definitely (and thankfully) not the norm. Imperial units are awful. They're more ... human, maybe, in that a foot is about one human foot long, and that an inch is about one human thumb width, and how 0F feels "pretty cold" and 100F feels "pretty hot", and to me the charm of imperial units begins and ends right there.

Those are literally the only redeemable qualities about imperial units, and they have nothing at all to do with their utility as a tool for measurement.

I am glad that you like them. Use them all you like. I won't.

<comment><USER3> >They're more ... human, maybe, in that a foot is about one human foot long, and that an inch is about one human thumb width, and how 0F feels "pretty cold" and 100F feels "pretty hot", and to me the charm of imperial units begins and ends right there.

As far as we know, humans are the only thing in the universe that care about any of this stuff. A computer couldn't care less if you are using 1 foot or 0.3048 meters.

Why not optimize for humans, the things actually using these things? Optimizing for the computer just seems...silly. It seems like something somebody from the 1970s would have thought was a futuristic idea.

<comment><USER4> Because adding 7/16ths of an inch to 7/8ths of a mile and getting an answer in inches isn't easy for a human. Adding 1cm to 982m and getting an answer in centimeters is dead easy for a human.

THAT'S why human intuition about measurement doesn't mean a damn thing.

Using metric means using the system optimized for humans. Period.

<comment><USER5> Your absolutism is a bit silly. I don't think the Imperial system is good for anything beyond construction or cooking, but there's a reason it excels those areas. And it's exactly because it's more usable by humans in certain contexts (like construction or cooking). 1/3 of a meter should not be an irrational number - how is that "optimized for humans"?

A scalable system that shares the divisibility of the foot would certainly trump both systems.

<comment><USER6> Nit: 1/3 of a meter is rational. You're looking for "whole number."

<comment><USER5> Correct - I've admittedly had a few beers.

Which might be obvious due to me debating the merits of the number 12 on the internet.

<comment><USER7> Well 12 is amazing, but arguably there are too many other negative aspects in the imperial system as a whole.

</comment></comment></comment></comment></comment></comment></comment></comment></comment><comment><USER8> The actual text of the resolution, for those with low tolerance for dumbed- down PR releases:

[https://www.bipm.org/utils/en/pdf/CGPM/Draft-Resolution-A- EN...](https://www.bipm.org/utils/en/pdf/CGPM/Draft-Resolution-A-EN.pdf)

<comment><USER9> I have low tolerance for long ass papers ;)

<comment><USER10> Isn't that just toilet paper? (long ass-papers)

<comment><USER11> One of the OG xkcd's: [https://www.xkcd.com/37/](https://www.xkcd.com/37/)

</comment></comment></comment></comment><comment><USER12> How would you use the new definition to calibrate instruments? My current understanding is that there is a lineage of artifacts calibrated against another artifact until one of those was calibrated against the one true artifact. So how would NIST or another certifying source say that my 1kg standard is 1kg +/\- tolerance?

Is it anyone with a kibble balance can now certify calibrations? How do you know your kibble balance is as accurate as the next guy's kibble balance?

[https://www.nist.gov/si-redefinition/kilogram-kibble- balance](https://www.nist.gov/si-redefinition/kilogram-kibble-balance)

Edit: Found some information explaining this from NIST: [https://www.nist.gov/si-redefinition/kilogram- disseminating-...](https://www.nist.gov/si-redefinition/kilogram- disseminating-new-kilogram)

<comment><USER13> Essentially this brings it one more step away from using another artifact for calibrating things. Instead this lets us define the kilogram against what we believe are universal constants, in this case properties about the electromagnetic force.

It's much simpler to understand looking at it with a watt balance, even though it's not going to be as precise or accurate as a kibble balance [1]. Basically now anyone with access to a kibble balance and the right set of numbers/information can make an exact 1kg object.

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

<comment><USER14> Or potentially more usefully, ascertain an accurate measurement of how closely a given measuring device is to the target to calibrate it's use in actual measurements (outside of the expensive validation mechanisms).

</comment></comment></comment><comment><USER15> This is probably the dumbest thing I'll type on HN.

In university I just gave up trying to understand why we even needed the Avogadro constant / mole as a fundamental constant. It still confuses me. Why have a difference between molar mass and mass? Why couldn't it just be "1" and everything else change around it?

<comment><USER16> Understanding mass in molar terms is necessary to do a lot of chemistry correctly. The mole is effectively a count of the number of molecules kicking about, although the count is large enough that terms like "quadrillion" don't cut it. (One mole is about 600 sextillion molecules). Knowing how many molecules are around lets you actually compute how much stuff can react in a given chemical environment, and other aspects of chemistry end up being pretty related to molecule counts. Vanilla mass doesn't cut it since an atom of iodine weighs about 6.6 times that of fluorine but can still only react with one other molecule.

The flip side is that the molecular count is less useful to us in the everyday world. We can gauge the weight of a kilogram much more than we can gauge a septillion molecules. And if we're trying to figure out how much stuff a shelf can hold before it collapses, it's the weight that matters, not the actual molecular count. (Note for pedants: in the familiar environment of Earth's surface, mass and weight can be treated as the same quantity in most cases.)

So mass and molecular count are both very important quantities that have importance in different fields of science, and they don't have a trivial relationship to each other. Avogadro's constant and molar mass is a way to express their relationship.

<comment><USER17> I think the GP is making the claim that Avogadro's constant should be 1 (effectively eliminating it), not that there's no need to count molecules.

<comment><USER18> An Avogadro's constant number of molecules is one mole. One mole of hydrogen has much less mass than one mole of iron. You have to choose an arbitrary mass of a single element as the base quantity. Hydrogen might be the best theoretically, it's just a proton and an electron, but it is tricky to work with because it's a gas at room temperature. So instead the mole has been defined as the number of molecules in a specific mass of carbon-12.

<comment><USER19> I think this is exactly the rationale. But, from a more practical perspective...

If instead of g/mol, we referred to molecules/g -- we would end up populating tables and charts with really big numbers. This would make lookup tables hard to read, difficult to publish, and hard to work with. Imagine if you had to do math with a bunch of 10^23 exponents all of the time.

Instead, it was agreed to effectively pull out a constant value from each of those to make the math significantly easier. Now, instead of dealing with a lot of big numbers, all of the lookup tables could now list smaller g/mol values. And we would be left with just the one single large (Avogadro's) number in the equations.

Honestly, we don't _need_ a set mole constant, but it makes chemistry significantly easier to do so. Unlike the other constants mentioned in the OP, Avogadro's number is completely arbitrary. It could be '1' as the parent suggested, except then it makes the rest of the math more difficult.

Even for this SI overhaul, we didn't really even need to redefine the mole, except for the fact that it was previously defined in terms of the old kg. This was just "fixing a glitch".

<comment><USER20> > Even for this SI overhaul, we didn't really even need to redefine the mole, > except for the fact that it was previously defined in terms of the old kg. > This was just "fixing a glitch".

I came to complain about the article calling the mole a "base unit of the SI", and this seems like an appropriate thread.

Why is the mole a defined unit at all? As far as I understand things, "one mole" is the same thing as Avogadro's number -- neither can be a unit, because they're both dimensionless constants (well, they're both one and the same dimensionless constant). Applying actual units, "one mole _of water molecules_ " is the same thing as "Avogadro's number of water molecules". Avogadro's number, and therefore the mole, is the conversion factor between atomic mass units and grams. Similarly, 3 is the conversion factor between feet and yards, but nobody thinks 3 is a fundamental base unit of the imperial system. The foot is a base unit of the imperial system, measuring length, the yard is a non-base unit also measuring length, and 3 is a number with no special relationship to the system at all. It would be total nonsense to say that yards are defined by reference to 3. How is Avogadro's number different?

Wouldn't "fixing the glitch" be abandoning the idea of calling the mole a unit in the first place?

<comment><USER21> The new definition of mole is exactly that - it's just 6.02214076×10^23 items of whatever, and no longer depends on kilogram.

<comment><USER20> That's not a base unit, or a unit of any kind. What's it doing in a list of SI base units?

<comment><USER7> Or you can say it is the conversion between a gram and a dalton, which is the same but more complex as it is now intertwined with the gram

<comment><USER20> I already said exactly that:

>>> Avogadro's number, and therefore the mole, is the conversion factor between atomic mass units and grams.

But that doesn't intertwine anything with grams. I went on to say

>>> Similarly, 3 is the conversion factor between feet and yards, but nobody thinks 3 is a fundamental base unit of the imperial system.

>>> It would be total nonsense to say that yards are defined by reference to 3.

</comment></comment></comment></comment></comment></comment></comment></comment></comment></comment><comment><USER22> I get that this is a significant milestone but this seems extremely overstated:

 _" the new changes will have wide-reaching impact in science, technology, trade, health and the environment, among many other sectors."_

Am I missing something?

<comment><USER23> With the old definitions, the values of the known constants were just approximations, but now that the unit is defined based on the constants, we can consider the constant as being the exact value, no matter how imprecise it was when it was measured using old definitions of the units.

<comment><USER24> So it's the equivalent of removing a magic number from your code and putting it into a const variable.

</comment></comment></comment><comment><USER25> I read the uk address and was afraid they had voted to leave the metric system, as some sort of Brexit associated madness.

</comment><comment><USER26> Veritasium did a great video [0] on this leading up to the vote.

[0] [https://youtu.be/c_e1wITe_ig](https://youtu.be/c_e1wITe_ig)

<comment><USER27> I wish he would spend a bit more time exsplining were some of the constants come from, although that would probably make the video a bit weaker overall. Wasting time on such information.

<comment><USER28> He's probably done videos on many of them already.

</comment></comment></comment><comment><USER29> Recently I have been thinking about if any of our units makes sense in cosmic perspective. Let's take speed of light for example. It's approximately 300000 km/s. But then what is a second? It's 1/60 of a minute which is 1/60 of an hour which is 1/24 of a day(and so it goes) and all those numbers are arbitrary. A day doesn't make any sense outside our planet anyway, I doubt that there is another celestial body in the universe that takes the same time to complete a rotation. Period of some natural phenomena (like atomic electron transition) sounds better as a unit but it's a really tiny period of time so we have to scale it to make it practical for us. We will use decimal numeral system to do that, another arbitrary choice. What if we had 12 fingers or 8? This can be extended to all kinds of measurements so I wonder if any of this would make sense to another civilization. What would a cosmic system of units would like? Any reading about this would be greatly appreciated.

<comment><USER30> The definition of a second isn't based on the Earth's motion, but some natural phenomena like you recommended. "The second is the duration of 9,192,631,770 periods of the radiation corresponding to the transition between the two hyperfine levels of the ground state of the caesium-133 atom." [1]

[1] [https://www.scientificamerican.com/article/how-does-one- arri...](https://www.scientificamerican.com/article/how-does-one-arrive-at- th/)

<comment><USER31> Of course, _that_ definition was made to make our current definition of the second continue to work.

</comment></comment></comment><comment><USER32> The Wikipedia entry is pretty informative [https://en.wikipedia.org/wiki/Proposed_redefinition_of_SI_ba...](https://en.wikipedia.org/wiki/Proposed_redefinition_of_SI_base_units)

</comment><comment><USER33> Very cool explanation of the math as well as the concept behind the standard:

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

</comment><comment><USER34> Has a "metric" version of time ever been proposed? Seems odd to me that we're "ok" with divisions of 12 for time but not length.

I guess for science _seconds_ are basically the only measure of time that usually matters?

<comment><USER35> Heinlein's "Starship Troopers" has the space marines using "kiloseconds" and "megaseconds" conversationally, and it was always tricky for me to convert those to hours and minutes in my head accurately.

<comment><USER36> Odd choices... since 1000 seconds is ~17 minutes and 1M seconds is 4.6 hours.

<comment><USER37>
      $ units --verbose
      Currency exchange rates from FloatRates (USD base) on 2018-10-25
      3070 units, 109 prefixes, 109 nonlinear units

      You have: 1 megasecond
      You want: 1 day
              1 megasecond = 11.574074 * 1 day
              1 megasecond = (1 / 0.0864) * 1 day

<comment><USER38> Gee, I never knew about _units_ , thank you. Very cool. It can convert meters/s to furlongs/fortnight, cm^3 to gallons.. Write fractions like '1|2'. And you can add your own units to the units file.

</comment></comment></comment></comment></comment><comment><USER39> >The definition of the kilogram for more than 130 years, the International Prototype of the Kilogram (IPK), a cylinder of a platinum alloy stored at the BIPM in France, will now be retired. It will be replaced by the Planck constant

Maybe I interpreted it wrong (non-native English speaker), but does it say that the Kilogram will be equal to the Planck constant? Shouldn't it be that the definition of the Kg will be _based_ on the Planck constant?

>Although the size of these units will not change (a kilogram will still be a kilogram)

Are our current measurements of the IPK _that_ exact so the old kg is _exactly_ equal to the new Kg? How can they measeure it with 0 error?. It doesn't make any sense to me.

<comment><USER40> > but does it say that the Kilogram will be equal to the Planck constant?

No, this statement means that Kilogram will give up its place as a fundamental unit to Planck constant. Earlier, Kilogram was used as a fundamental unit, defined by a physical object. Not anymore.

The kilogram will be defined by Planck constant. Namely, m = E/c^2 = hf/c^2.

> How can they measeure it with 0 error?

We can't, all measurements have errors. But we _can_ measure things better than a physical object, which _has_ changed with time. So we only have to measure Plank constant with precision higher than variation of physical object's mass for the purpose of replacing the definition of mass.

</comment></comment><comment><USER41> Never understood why the reference weight was one and not a maintained average over several or tens. This could have included aperiodic less used reference weights stored differently, different washing cycles &c.

I know several bipm participant nations had clones but they were always understood to be daughter weights.

Level surfaces (for instance) used to be made as triplets and never pairs: pairs can form lenses.

Not that a kibble balance definition isn't better: I just don't understand why the kg definition was a Singleton and not statistically satisfied.

<comment><USER42> Decay would be exponentially greater with more weights. Causing a larger decrease over time.

<comment><USER41> Except some kg reference weights gain weight. The washing regime ablates, but the metal matrix is porus at the atomic level (I am told) and so they accrete.

Therefore there would be gains and loses. Not just losses

</comment></comment></comment><comment><USER43> Finally there is order in units for science community. Hopefully such transformation will come to US one day.

<comment><USER44> The US units are defined in terms of SI since the Mendenhall Order[0], so they also benefit from this change.

[0]: [https://en.wikipedia.org/wiki/Mendenhall_Order](https://en.wikipedia.org/wiki/Mendenhall_Order)

<comment><USER45> It wasn't until 1959 that the yard was metricized. This still affects precision machinery manufactured before the changeover.

<comment><USER44> It was metricized with all the rest before that. What happened in 59 was harmonization with other countries including Canada, who had a different agreement on the metric yard. The older american definition was 1 yard = 3600/3937 meter. The international metric yard is exactly 0.9144m. (A difference of 0.002mm)

</comment></comment></comment></comment><comment><USER46> So...How many Planck's is one Kilogram then?

>The mass of the international prototype of the kilogram m(K) is equal to 1 kg within a relative standard uncertainty equal to that of the recommended value of h at the time this Resolution was adopted, namely 1.0 × 10-8 and that in the future its value will be determined experimentally,

Is the Planck simply the most standard deviation the kilogram can stray from now?

<comment><USER47> This wikipedia section breaks down the new definition nicely [https://en.wikipedia.org/wiki/Redefinition_of_SI_base_units#...](https://en.wikipedia.org/wiki/Redefinition_of_SI_base_units#Kilogram)

<comment><USER46> It is still not apparent to me. Is a kilogram of something now it's joules x seconds or something? Does the kilogram now vary depending on what the kilogram is of? Like, is a kilogram of Iron a different mass from a kilogram of Aluminum?

>The kilogram, symbol kg, is the SI unit of mass. It is defined by taking the fixed numerical value of the Planck constant h to be 6.62607015×10−34 when expressed in the unit J⋅s, which is equal to kg⋅m2⋅s−1, where the metre and the second are defined in terms of c and ΔνCs.

So mass is now some sort of length times a given elapsed time?

<comment><USER48> I believe it means something like:

Given the definition of metre and the definition of second, the kilogram is whatever value that makes the Planck constant h precisely 6.62607015×10−34 kg m^2 s^(-1).

<comment><USER46> But isn't that a bit of a recursive definition? What might one use as the value of kg in that example?

<comment><USER47> There is only one value a kg could be in that example, everything else is constant. The question I think you're trying to ask is "why 6.62607015×10−34 instead of some other simpler value" and the answer is a bit longer.

Original 1 kg was the mass of a cubic decimeter of water at 4 C at 1 ATM. Why a cubic decimeter at 4 C? Water is densest at 4 C and a cubic decimeter of it is a weight that people can work with on a day-to-day scale. Unfortunately this was a bit hard to measure so they made the IPK (international prototype kilogram) which was a lump of metal. Fast forward 100 years and the lump of metal proved to be too unreliable for modern standards as it kept losing very small amounts of mass, also it Earth's gravity isn't even so it requires you average it out and then calculate the local offset and a whole bunch of other weird things that can mean a microgram or two. This is inconvenient but we still needed a way to say "1 usefull measurement of mass" but unfortunately in the universe 1 Planck's constant is far too small to ever use daily. Thankfully it has become easier to accurately measure Planck's constant against the IPK so now we have solidified 1 kg to be exactly what we measured.

The nice thing is 1 kg will forever be the same thing now and is easy to measure to extraordinary accuracy. The downside I think you're asking about is 1 kg by itself isn't some significant relation of the physical world, it's just a useful-in-daily-life multiple of mass as defined by Planck's constant.

</comment></comment></comment></comment></comment></comment><comment><USER49> I can imagine that in 100-200 years we'll have to adjust some unit because our understanding of some constant was just slightly wrong.

<comment><USER50> According to the new definitions, some of the fundamental constants can no longer be wrong. We could even have defined them as 1 (which is what physicists have been doing for a long time already.)

<comment><USER51> If you do that, magnitudes of resulting units will either be huge or very tiny, depending on the composition of fundamental constants in said measure. The constants are _very carefully_ chosen to match old units.

</comment></comment></comment><comment><USER52> So there was a definition of a kilogram based on an actual physical thing with an arbitrary amount of mass.

Does this new definition essentially try to approximate that mass as close as possible? What is the margin of error there?

I would love to know this for a second as well, although I don't know what we used to measure a second before we locked it to the vibrations of a cesium atom.

<comment><USER53> The Earth?

<comment><USER54> Yes. In two ways.

First, the assumption was that the Earth's rotational period was 86400 seconds. Mechanical clocks had given us no reason to doubt this was so.

By the mid-20th century quartz timers were able to discern that the Earth has longer and shorter days, as numerous factors cause the spin to speed up or slow down. Instead of a single day the second was taken to be one 86400th part of an average day over the whole year.

A few decades later the availability of atomic clocks made this seem silly and we uncoupled the second from the variably spinning Earth. The completely arbitrary seeming atomic clock definition of a second was basically chosen to be indistinguishable from our last guess at the "averaged over a year" second.

</comment></comment></comment><comment><USER55> Something I've considered recently is the case of estimating heighth (or any length) in customary vs. metric.

In the US, if I'm describing someone, perhaps to a police officer, I can fairly easily conceptualize the difference between 5ft, 5ft 6in, 6ft, or even smaller degrees of difference.

Though I'm certain this is likely just a result of me having grown up with the customary system, it seems like it would be more difficult (or at least more tedious) to estimate the heighth of a person using meters, given that most humans are in the 1.5-1.8m range (by my estimation). Especially when looking only at one gender, the range of possible heights is quite small in meters, requiring more precision to describe.

For example, I can reliably understand and visualize the difference between 5'0" and 5'4".

I'm curious for those in the rest of the world - can you meaningfully visualize the difference between 1.5m and 1.6m? Or perhaps 1.55m and 1.58m?

<comment><USER56> This is _only_ due to you being used to certain units.

I was raised in EU using Celsius scale and can relate to full scale. In US I can relate only to 70-80 range as this is what I consciously experienced (ie. adjusting air conditioning). I still need to convert Fahrenheit to Celsius for anything outside of that range.

Also imperial sucks utterly as metric allows almost seamless exchange of mass measurements with volume for of pretty much anything in the kitchen (1g of water is roughly 1cm^3, almost everything we eat is very close in density to water).

</comment></comment><comment><USER57> I curiously wonder on what ground the future overhauls will happen. ToE? [https://en.wikipedia.org/wiki/Theory_of_everything](https://en.wikipedia.org/wiki/Theory_of_everything)

</comment><comment><USER58> The main problem with imperial units is that it isn't a system. It's a hodgepodge of pieces of different historical systems, many of which made a lot of sense in their original context, but the context has been stripped from them and they've been mashed together with completely unrelated systems. A base-12 system would actually have some advantages, but very few of the imperial units are actually defined in terms of base-12, so it doesn't qualify.

</comment><comment><USER59> > a cylinder of a platinum alloy stored at the BIPM in France, will now be > retired. It will be replaced by the Planck constant – the fundamental > constant of quantum physics.

I thought they did that long time ago.

<comment><USER60> I wonder how much the cylinder will auction for.

<comment><USER61> At least there will be no disagreement about the shipping weight on the auction listing.

<comment><USER62> The real question is how many boxes will the fulfilment center place the kg in. If Amazon is anything to go by my money is on 3

<comment><USER63> OT, but _this_!

I recently ordered a picture frame from Amazon. It came in its packaging box, which was placed in a box by the manufacturer. That box was put in another box by Amazon and shrink wrapped to a large piece of cardboard, which was then put inside yet another box.

On the surface, it seems crazy, but Amazon did manage to get it to me undamaged.

<comment><USER64> My wife recently ordered five storage boxes. They arrived in two packages on the same day. One package neatly fit four of the boxes. The other package was large enough for five, and contained one storage box and a excessive amount of packing material. Not an Amazon purchase, so it must be an industry issue.

</comment></comment></comment></comment></comment></comment><comment><USER65> The US didn't adopt the metric system because it was considered blasphemous since the French used it. I'm not joking. We got screwed by a bunch of demagogues.

<comment><USER66> The US officially adopted the metric system in 1975 with the Metric Conversion Act.

<comment><USER65> The act does not require the US to use metric in any capacity. It is optional. If it did kids would not be taught using the imperial system.

<comment><USER67> The US uses customary measures. Imperial is the old UK system. It has some important differences like the size of a gallon - and perhaps most importantly if you like beer: the size of a pint.

</comment></comment></comment></comment><comment><USER68> For an engineer it's quite an anventure throughout your career discovering how many "languages" people speak: imperial, metric, IEC, ANSI, metric thread, NPT thread, all the units and industrial standards. And still foreign ISS parts mate in orbit on their first date. Or ITER parts fit toghether in plant. That's electrifying and inspiring.

</comment><comment><USER69> The old definition of kilogram (with IPK) is no good, so it is very good that they are correcting it.

Of course you can still use imperial and other units in whatever context they are useful, and so SI units can also be used in the context where they are useful. But still I am glad they change it, because the old definition of kilogram is no good.

</comment><comment><USER70> The Doubleclicks write a song about the IPK, the international prototype kilogram, and how it must feel about this.

[https://youtu.be/VHd4HPmz5aE](https://youtu.be/VHd4HPmz5aE)

</comment><comment> Digit-Al Can anyone tell this poor ignoramus whether the kg is getting heavier or lighter - and how much by (approximately, I know it's not going to be an exact figure given the reason they are changing it)?

<comment><USER71> This doesn't impact the actual weight of a kg. What this impacts is how the kg is defined, no longer does it rely on a physical kg.

It used to literally be defined as the mass of "IPK" \- the international prototype kilogram. [https://en.wikipedia.org/wiki/Kilogram#International_prototy...](https://en.wikipedia.org/wiki/Kilogram#International_prototype_kilogram)

This switch now defines it in terms of the force equivalent of the energy exerted by a single photon - if my understanding is correct.

Theoretically a more scientifically sound way of keeping 1 kg a constant permanently.

<comment><USER72> That doesn't make sense to me, the definition has changed.

The IPK was 1 kg and the copies of it were all slightly heavier or lighter, for argument let's say IPK1 was 1.1 kg and IPK2 was 0.9 kg. Now that we have a constant for the mass of 1 kg, all of those IPK's will now have a new mass relative to the new definition.

Unless the new definition was based on the current IPK and set its mass as of today as the standard, and that standard now will be unchanging?

<comment><USER73> > Unless the new definition was based on the current IPK and set its mass as > of today as the standard, and that standard now will be unchanging?

Correct. The current IPK will still be 1kg to within margin of error at the time the new definition comes into effect, but any further changes to it will make it, for the first time, drift away from that value.

<comment><USER72> Ah I see, that makes sense, thanks!

</comment></comment></comment></comment></comment><comment><USER74> So now packages relying on older values would have to be updated, right? In that case, wow, all those ancient - but usable FORTRAN/C code. Correct me if I am wrong.

<comment><USER28> Ideally the weight of a kilogram defined by the new definition should be identical to the weight of the old physical " _the_ kilogram" object. The goal of this isn't to change how much a kilogram weighs, it's just to change how it's defined.

For a comparison, it used to be that we measured the speed of light as being 299,792,458 meters/second. Since then, we have _defined_ the meter to be 1/299,792,458 of the distance that light travels in one second. An object that was 1 meter long before is still 1 meter long, but the way we communicate how long a meter is has gone from "it's how long this particular stick in France is" to a precise definition based on fundamental properties of the universe.

</comment></comment><comment><USER75> Welcome news.

Of course the U.S. will continue to be be the leader of the 3rd world by measuring in Royal Hangnails, Princely Bladders and Regal Farts.

</comment><comment><USER76> About metric vs imperial. We all adopted 10 based numbering. That puts any system not 10 based at disadvantage.

</comment><comment><USER77> I guess the next redefinition will happen if and when there's detectable drift in "fundamental" constants?

<comment><USER63> _I guess the next redefinition will happen if and when there 's detectable drift in "fundamental" constants?_

And until then, all the metric fanbois will constantly tell you that metric is superior to imperial because its measurements are immutable. Until suddenly they are.

<comment><USER78> As opposed imperial constants? How is a foot standardized anyway? I suspect most manufactures rely on SI metrics for that.

<comment><USER54> There are no other standards. Metrology is expensive and doing it over again would offer no benefit whatsoever. All prior standards in widespread use were abandoned during the 20th century in favour of defining the relevant units in terms of SI units.

Specifically the international yard equals 0.9144 meters and the international pound equals 0.45359237 kilograms

There literally isn't another definition, in the US when you say "100 yards" the only legal meaning that has is 91.44 metres, which is whatever CGPM / BIPM says it is.

</comment></comment></comment></comment><comment><USER79> My poor textbooks! Welp, I guess there will be some great bargains next year.

</comment><comment><USER80> This is massive news.

<comment><USER81> The went to great lengths working on this announcement.

<comment><USER80> No they didn't, the lengths stayed the same!

</comment></comment></comment><comment><USER82> if civilization fails....how we are going to measure these things? Or then, we'll have bigger problems so who cares

</comment><comment><USER83> On the rare chance that anyone here missed today's XKCD:

[https://xkcd.com/2073/](https://xkcd.com/2073/)

<comment><USER84> Thank you for linking this, just made my day!

</comment></comment><comment><USER85> Too bad US doesn't use them.

<comment><USER86> Fun (?) anecdote - metric apparently has been used in US engineering for quite a while; a petrolhead buddy of mine was puzzled as to all the fractions used on the drawings of his (I think) Chrysler Hemi V8 from the fifties - on a hunch, we converted a few to metric. Bingo.

(Just making up a number here) 3.937" stroke? Why on Earth... Ah. 100.0mm. That's why.

<comment><USER87> Another anecdote - In structural engineering, US units are way easier to work with, and even in Canada, about 90% the buildings I work on use kips, ft, ksi, etc.

<comment><USER88> They aren't easier to work with for any reason other than that sizes of standard components (pipes, beams, etc) are sized conveniently in US units and have US units printed on the spec sheets.

If you go overseas outside of North America, you find that the sizes of everyday objects are conveniently sized in metric, and building codes and standards and material strengths and densities are specified in SI units, and suddenly working with the metric system in those industries is easy and convenient.

Do you deal with building insulation? How would you interpret a material spec of "1 BTU ft/(in^2 hr °F)"? I had to work with these units in the US and it was not at all convenient.

<comment><USER87> I don't deal with building envelope. Its not surprising or unexpected that there are differing opinions among various professions on which set of units are more convenient.

In Canada, all our building code, material design codes, etc are in metric, and yet we are still using US units for day to day design.

<comment><USER88> What lengths and widths of wood can you buy from the lumberyard?

What is the common width and thickness of drywall sheet you can buy and the hardware store? What door sizes are available? What size of screws are cheaply available in Canada?

I think these factors are far more likely to affect what unit of measure is commonly used in construction, rather than any intrinsic merit of the measurement system. If you were shopping at a Japanese or German hardware store, you'd probably suddenly find all of those 12 foot dimensions quite frustrating and not be at all surprised to find the hard-hat-wearing locals happily using the metric system for the same tasks.</comment></comment></comment></comment></comment></comment>