As someone with a 12 year old Nissan, and buys the cheapest beer beer I'm sympathetic. But what's the point of being a millionaire if you aren't spending? You can just do that on a regular low stress job.
To add to the argument about security, the average stock market return after inflation is around 7%. With investable assets of $1 million, that means you're being paid $70k/year, just for already being wealthy. I imagine that no matter how low stress a job can be, it can be even lower stress knowing that no matter what happens, even if you never work again, you would have sufficient income to live.
(This glosses over the variability of the market, but that just adjusts the amount of wealth needed relative to the yearly expenditures in order to continue indefinitely, and the principle still holds.)
Yeah that 7% is likely an illusion. If we kept up 7% a year forever just about every professional could retire at 50. But its unlikely to continue, we've had a 50 year bull market that is long overdue to end.
Thank you for finding a simple way to describe why that book bothered me so much. The author offers no room for rational dissent. You are either with him, or you're a fool.
In his value system, the additional security offered by millions is worth sacrificing every other potential want or desire in life for. I find that ridiculous, addition non-bullet proof security is just ONE of many things which must be evaluated for its relative worth based on ones own value system.
I say non bullet proof because I feel the author completely disregards the possibility of war or the country collapsing making the "security net" the money could otherwise buy be nullified entirely.
He also implicitly disregards mortality. The opportunity cost of every year spent with a focus on accumulation is one you can never get back. I guess in this case I'm thinking a lot about travel or living abroad at a reasonably young age where the impact is absolutely materially different from retirement in one's twilight years in Thailand.
Having a seven figure liquid wealth affords you the freedom to step away from a toxic job, relationship or other situation. Things that induce a high level of stress for most middle class families like a $5-10k repair bill become mere inconveniences. College costs for the kids are manageable, health crises can be navigated usually.
Earning a massive salary and spending every last dime is a far more stressful way to lead one's life and likely much less enjoyable save for some short lived hedonic rushes when purchasing that newest toy.
So basically they're all bad except for SV? 1 Gallon of gas makes 2.4 kg emissions, so instead of swiping a card its burning a few gallons of gas, or 50 gallons for BTC.
Rather, they are all bad. Proof of stake cryptocurrencies is the state of the art in consensus protocols today, not proof of work. This is mostly a ranking of who’s the worst among the worse technologies.
I have very little experience with Zulip, so take this with a grain of salt. Just like Matrix, Zulip is open source and can be self-hosted. They both target instant-messaging use cases.
Zulip has a far more advanced threading model than Matrix. Currently, Matrix only has basic replies in the spec. In practice, everything in a Matrix room is in a single thread. It definitely makes it hard to follow conversations that are long-lived or in busy rooms or both.
Matrix is federated and Zulip isn't. You can run your own Matrix server and communicate with all the other Matrix servers that already exist. Rooms live on multiple servers and are resilient to the failure of any participating servers as long as one remains.
Matrix is far more general than Zulip. It acts as a store for arbitrary, eventually-consistent, ordered JSON data. Most of the time this is used to create an instant messaging service, but it can be used for much more.
Zulip subjectively has a nicer default client than Matrix (Element). Zulip's is special-built to handle its unique threading model.
It's also worth noting that Matrix is adding support for arbitrary threading [0]. I'm really looking forward to this. It should allow us to build a Zulip clone fully in Matrix with all of the benefits that come with the Matrix ecosystem.
I wish the Matrix/Element folks the very best of luck, because they're pretty aligned with Zulip values-wise.
That said, I don't think you should expect a Zulip-style threading user experience in Element anytime soon. Regardless of how the Matrix protocol for federation between servers is extended, providing the "Zulip user experience" would likely require a major overhaul of both their client/server protocol for Element and their client user experience. (Also, the proposal you link is for HN-style threading, not Zulip-style topics).
I don't understand Element's internals, but my basis for this claim is a huge portion of all technical and design work we do on Zulip wouldn't be necessary or would be much simpler if Zulip didn't have topics (E.g. the architectural decision criticized in https://news.ycombinator.com/item?id=27150492 is a good example). See https://news.ycombinator.com/item?id=27150196 for a few more examples. I imagine Element will only invest in all of that work that if they believe it's important to their business.
As an outside observer, Element's business focus seems to be on competing with WhatsApp/Messenger/Signal/Telegram/SMS, not Slack, so while I'd love to see Matrix/Element borrow Zulip's topics model, you probably shouldn't hold your breath.
Thanks for pointing out that the upcoming Matrix threading model I linked to isn't the same as what Zulip has. I wasn't thinking about Zulip's model correctly.
After doing some research, I think you're right that the proposal won't immediately enable Zulip-style threading. Though, it seems like a small change on top of the linked MSC (Matrix Spec Change) proposal would enable Zulip-style threading.
If Matrix had an event type that created a "topic", that's all you would need. The linked MSC is very general and allows events to reference arbitrary parent and child events, and allows updating those parent and child relationships. If the parent is some kind of "m.topic" declaration event, maybe that would be enough.
It's also entirely possible that Zulip style threading doesn't even require that new event and I'm just not familiar enough with Matrix to see how.
---
Your points about how advanced the Zulip client is, though, are very true. It will take a ton of work for Element or some other Matrix client to catch up. You guys really built something impressive there.
I look forward to seeing what Zulip comes out with in terms of federation. It's a tough problem.
On the federation front, if your goal is to connect different chat services running different chat protocols, that's been possible for years with tools like Matterbridge (https://github.com/42wim/matterbridge). Zulip also has direct bridge integrations with IRC and a handful of other protocols, e.g. https://zulip.com/integrations/doc/irc.
These integrations are a bit ugly and certainly not the ideal design, but they work and help a lot of communities that are 90% on Zulip but still want an IRC presence for whatever reason. (A fun historical note: Zulip's had a really nice puppet-powered bridge with Zephyr since 2012, because that was how we got enough usage during its early development to design the product and its data model with real users).
Longer term, we're planning to build a native Zulip federation feature. For us the technical strategy has been to first make a Zulip world-class user experience, and do native federation later.
Our strategy is motivated by XMPP, which like Matrix is extremely general (E.g. I talked to people who used XMPP as message bus for their backend infrastructure 10 years ago). XMPP is dying as a chat protocol because nobody can build a modern world-class chat application using it as the client/server protocol.
E.g. multiple people who'd worked as engineers on now-dead chat products complained that because their mobile apps talked XMPP to their server, it was impossible for them to make the apps start quickly in medium-size organizations, because of all the round-trips required.
In contrast, Zulip's client/server protocol both on web and mobile returns all metadata in a single HTTP request: https://zulip.com/api/register-queue, and then after that, another to fetch whatever messages you're going to look at.
As someone who worked on an XMPP web client that set up a whole session in a single HTTP request and response, I can say it's definitely possible to do this.
XMPP also has optimisations so you can resume a session across network disconnects etc. so that session initialization is typically limited to app start.
A more fundamental issue for many of these apps is that XMPP group chats were very presence-focused, and quite chatty (you need to join and sync every channel every new session). People have worked around that in various ways in the past. These days we have the newer 'MIX' standard for group chats which is not per session and far cheaper for many/large groups.
XMPP has evolved, and continues to evolve. But I fear that people inventing their own chat protocols is a problem that can never be fully solved.
> What's the benefit of this? Seems like a very niche feature.
Cross organizational communication, e.g. across ministries (like France realized it with 60 Matrix servers), across different offices of companies, across multiple companies, across universities (which was e.g. important for TU Dresden).
In principle it is the same with Email.
> What other use could there be?
> I'd want a software that does one thing well because to this day there isn't even a chat solution that rules all the others.
Matrix is a protocol, not a software. Specifically it is a communication protocol. So anyone can create software that needs communication which benefits from properties that Matrix provides, can use it independently of the software you are using to chat.
If you can only talk to other people on your own server, then the application is limited to just team chat.
Matrix clients have the potential to be much more. You can use the same account for various team chats and still use it like a messaging app for your friends and arbitrary personal groups.
Maybe most importantly, federation provides resilience against bad server operators. If Signal had allowed federation, it wouldn't have been a big deal to ditch its servers when they introduced a sketchy cryptocurrency onto the platform. Because they don't allow it, everyone was locked in.
At FOSDEM (I believe) earlier this year it was mentioned that zulip interoperabily with Matrix is actively being worked on. Unfortunately the release announcement does not mention it, so probably not yet ready for public release?
As a regular zulip user it's a shock to me every time I have to use the element client. I have the feeling the latter is very slack-like in tis look and feel. I could be wrong on this, luckily I haven't had to use Slack for 3 years. Unfortunately with people used to Slack, it will be a shock to them to use zulip.
> Employers are looking at your education, companies you worked at, years of experience, and maybe a vague idea of what your work area was before this.
Isn't this what a resume is? Just the list of those things that Employers want to look at.
It isn't what most people think a resume should be, looking at the very article we are discussing as well all the "resume consulting/polishing" services out there.
Plus, employers are anyways going to make you fill out all this info separately in their recruiting system.
When I look at a CV I want to see someone's achievements, ideally quantified. What are they proud of, how have they helped their previous teams/products/companies to succeed, are they passionate about what they do.
