Show HN: An open-source media hosting site that's anonymous and fast - <AUTHOR> https://blog.mediacru.sh/2013/07/19/MediaCrush-for-nerds.html <comment><USER2> Stellar work. Your openness about everything is incredibly refreshing, and integration with RES was an awesome move. It's an easy choice to make the switch!

I am seriously impressed. I loaded up your README on github and had your app running within 10 minutes locally---including `gif` uploads. That's just really nice craftsmanship that is usually missing in fresh projects. Giant kudos to you guys.

(There were a couple trivial steps I had to do that weren't documented. I submitted a pull request. [1])

[1] - [https://github.com/MediaCrush/MediaCrush/pull/108](https://github.com/MediaCrush/MediaCrush/pull/108)

<comment><AUTHOR> Thank you so much! It feels awesome to know you've managed to run it smoothly. Really makes all the effort we've put into it worth it!

PS: Merged your pull request, thanks!

</comment></comment><comment><USER3> "The only thing we store about you is your hashed IP address"

The IPv4 address namespace is so small that brute-forcing hashes would be trivial, so this isn't an effective approach.

<comment><AUTHOR> True. We use 12 rounds of bcrypt, though, so they should be at least moderately secure. It's the best solution we've found so far... we'd be happy to hear alternatives that allow us to generate secure hashes for the IPs and allow us to ban people by IP if necessary.

And yes, I know that 12 rounds of bcrypt doesn't mean much. It will delay brute force attacks, though.

<comment><USER4> Ban all .gov and .mil known IPs. Ban all IPs owned by the MIC (KBB, BAA, Etc)

<comment><USER5> What makes you think these people aren't capable of purchasing or routing through commercially available address space?

<comment><USER4> They are certainly capable of paying for it... the facts show though that they are typically not good at shielding their source IP. The wikipedia edit from the senate IP, the tracking of the SAIC IP to NSA etc...

Its not a 100% guarantee - but it's a start.

</comment></comment></comment></comment></comment><comment><USER6> Hi, I made this site with jdiez17 over the past few months. We'd love to hear your thoughts on our work.

</comment><comment><USER7> This is awesome, and I really appreciate the effort toward privacy/transparency. Along those lines, supporting do not track is great, but why use GA at all? Just implementation ease? Is this something you plan to move away from?

<comment><AUTHOR> Thanks!

Well, GA is quite convenient - we get pretty graphs, realtime analytics and so on. It's not something we have considered moving away from, since it's trivial to disable it entirely. And it's not significantly worse than any other tracking tool.

<comment><USER7> I'd say it's substantially different from hosting your own Piwik, OWA, or even something like snowplow - where you could elect to avoid IP storage.

That said, those all entail a lot of work and/or additional cost. You're also absolutely right that allowing users to disable it (and ads) is an amazing feature.

<comment><USER8> I've found piwik to be unusable for large datasets

<comment><USER7> How large?

Piwik is really ancillary to the discussion at hand, but I often see the claim that Piwik can't handle busy sites, and it's important to quantify the claim.

I've had success (and others report similar behavior) with 500,000+ hits per day. [http://piwik.org/docs/optimize/](http://piwik.org/docs/optimize/) reports adequate support to higher levels. It's quite easy to set this up with EC2 + RDS, and using autoscaling gets you a very resilient solution that can easy handle those numbers. Also, in the case of mediacru.sh, many of the optimizations have little impact since they optimize for reporting on the already-gathered analytics. With only two analytics viewers/users - this is not much of an issue.

If you're doing more than 1mil per day, then I think something like snowplow, a commercial solution, or a fully custom solution are appropriate anyway.

</comment></comment></comment></comment></comment><comment><USER9> Demo page [1] uses gif made from Chuunibyou demo Koi ga Shitai! [2] anime. Was it totally random choice or MediaCrush crew did it purposely (aside from showing big difference)? Apparently many geeks are after anime, but sadly overall plot-quality of them deteriorates slowly almost each year. That said, Chu2koi was actually one of better series in 2012 Q4 (with nice visual side too).

To be less off-topic: good job on making it, openness and finally shipping it.

      [1] https://mediacru.sh/demo
      [2] http://en.wikipedia.org/wiki/Love,_Chunibyo_%26_Other_Delusions

<comment><AUTHOR> Heh, it's certainly not random choice. Sir_Cmpwn is a massive anime geek. Personally, I'd have used a cat gif.

</comment></comment><comment><USER10> This is great!

Any plans to have an API that other products/services can use? Is it against the TOS to post to /upload from a different domain?

I'll be working on a site soon that might allow some type of media upload. Would it be okay to use mediacru.sh for something like that?

I could see "free hosting" getting really expensive for you guys though, especially if you allowed hotlinking, etc.

Anyways, best of luck to you. Hopefully this becomes profitable for you.

<comment><USER6> You're free to use our API. There's some shitty "docs" here: [https://github.com/MediaCrush/MediaCrush/issues/50](https://github.com/MediaCrush/MediaCrush/issues/50)

<comment><USER10> Awesome. Thanks again!

</comment></comment></comment><comment><USER11> Hmm. Weird i tried this with two of the same MP3 files and it didn't change the file size & quality is the same? :/ Original: [http://126.96.36.199/mp3/2.mp3](http://126.96.36.199/mp3/2.mp3) Converted: [http://188.8.131.52/mp3/1Vzigd0EXPo1.mp3](http://18.104.22.168/mp3/1Vzigd0EXPo1.mp3) Any suggestions?

<comment><USER6> Actually, we don't do any processing on mp3 files yet. The following files are compressed to the best of our ability: GIF, JPG, PNG, MP4, OGV, SVG.

Got an idea for a good way to compress mp3 files?

<comment><USER12> Don't.

<comment><USER11> Well go figure it can be done with the mp4s so why not give it a try with mp3s?

<comment><USER12> I'm a stickler for quality. I may be an outlier - but the future shouldn't be in 320kbit/s

<comment><USER6> We aren't planning on using lossy compression. We're sticklers for quality, too.

</comment></comment></comment></comment></comment></comment><comment><USER13> It would be nice if you could convert videos from Youtube and convert them into a GIF

</comment><comment><USER14> from what I've seen this is all free. which is ofcourse great. and open source too. But I wonder if you guys have a business model? I mean somebody has to pay for those servers right?

<comment><AUTHOR> We don't have a business model right now. At this stage we're just trying to build a service with the best possible experience for the users. Monetization will come later, we can afford to pay server and bandwidth bills for now.

Our only source of income is donations and the advertisements that we show exclusively on the home page. You can check all of our accountability at [https://mediacru.sh/transparency](https://mediacru.sh/transparency), by the way.

<comment><USER14> Brilliant. I wish you guys the best of luck. I hope all of this pays off in the end and you guys can make this awesome product profitable, because I hope to be using this for a long time :)

</comment></comment></comment><comment><USER15> Maybe I'm blind, but what's the file size limit?

<comment><AUTHOR> 25MB. That's not actually stated on the website (good catch) but you can see it here, on the nginx config: [https://github.com/MediaCrush/MediaCrush/blob/master/config/...](https://github.com/MediaCrush/MediaCrush/blob/master/config/nginx.conf#L41)

<comment><USER16> Those rewrites you're using

[https://github.com/MediaCrush/MediaCrush/blob/master/config/...](https://github.com/MediaCrush/MediaCrush/blob/master/config/nginx.conf#L4&L10) (BTW, how to hightlight two separate lines?)

are considered taxing

[http://wiki.nginx.org/Pitfalls#Taxing_Rewrites](http://wiki.nginx.org/Pitfalls#Taxing_Rewrites)

and you could replace them with just a "return."

I love the idea, the fact that you provide all the configs, that it's written in python... it's a really great project.

<comment><AUTHOR> Oh, didn't know about that. Well, that's the good thing about being open source - you have some knowledge we didn't have, so submit a pull request fixing it, I'll merge it, and we'll all be a little bit happier.

Thanks for the heads up!

</comment></comment></comment></comment><comment><USER17> Any plans to feature a site search?

<comment><AUTHOR> Nope, kind of goes against the idea - there's no way for you to "discover" uploads to mediacrush. We don't even allow crawlers to index media pages.</comment></comment>


Why the Adam Tablet Almost Failed to Exist - <AUTHOR> http://nextparadigms.com/2010/08/10/why-the-adam-tablet-almost-failed-to-exist/ Investors that don't understand your vision from the beginning will fail to support you at tough times, and this is what happened with Notion Ink, too. <comment><USER2> almost? it still doesn't exist yet</comment>


Segwit2x Bitcoin Fork Suspended - <AUTHOR> https://lists.linuxfoundation.org/pipermail/bitcoin-segwit2x/2017-November/000685.html <comment><USER3> So bitcoin went up because they were going to fork, and now it's going up again because they will not?

k

Edit: Otoh, looks like it's seeing a bit of a drop now, but I doubt it will hit the pre-anticipation levels.

<comment><USER4> Market fundamentals seem non existant here. At least a few years ago, when there were bad news the prices would reflect that. Now, it seems to go up anytime bitcoin is mentioned at all, regardless whether the market understands the implications or not.

<comment><USER5> This is why I got out of bitcoin trading. It used to correlate to the general attitude about it. Now the coins and miners are so centralized the real driving force of bitcoins price is the thousand wallets holding 95% of all BTC. Its like trying to predict market movements for a stock where 95% of the shares in a company are owned by one person. It isn't up to anyone else _but_ that person where the price trends, because the behavior of the 5% crumbs mean nothing against the behavior of that one holder.

The price will simply go up when the whales want it to, and go down when said whales want to cash out. Fees could go up or down, China could do X or Y, the Fed could regulate it or not, and the general opinions of the ecosystem don't matter whatsoever - price is fairly solely dictated by the whims of a few dozen elites nowadays.

<comment><USER6> Reposting this as pertinent:

      In economics, the Gini coefficient is the standard measure
      of how inequitable a society is. This is tricky to
      determine for Bitcoin, as it's not quiet a "society" in
      the Gini sense, one person may have multiple addresses and
      many addresses have been used only once or a few times.
      (The commonly-cited figure of 0.88 is based on one small
      exchange in 2011.) However, a Citigroup analysis from
      early 2014 notes: "47 individuals hold about 30 percent,
      another 900 a further 20 percent, the next 10,000 about
      25% and another million about 20%"; and distribution
      "looks much like the distribution of wealth in North Korea
      and makes China's and even the US' wealth distribution
      look like that of a workers' paradise

      Dorit Ron and Adi Shamir found in a 2012 study that only
      22% of then-existing Bitcoins were in circulation at all,
      there were a total of 75 active users or businesses with
      any kind of volume, one (unidentified) user owned a
      quarter of all Bitcoins in existence, and one large owner
      was trying to hide their pile by moving it around in
      thousands of smaller transactions. (Shamir is one of the
      most renowned cryptographers in the world and the "S" in
      "RSA encryption")"

[1] via [https://news.ycombinator.com/user?id=davidgerard](https://news.ycombinator.com/user?id=davidgerard)

<comment><USER7> For context, those numbers came from 2014. [http://www.businessinsider.com/bitcoin- inequality-2014-1](http://www.businessinsider.com/bitcoin-inequality-2014-1)

I can't find any more recent study specific to the Gini coefficient, however these[1] charts show an improvement over this snapshot[2] from May 2015.

[1]: [https://bitinfocharts.com/top-100-richest-bitcoin- addresses....](https://bitinfocharts.com/top-100-richest-bitcoin- addresses.html) [2]: [https://www.cryptocoinsnews.com/1-bitcoin-community- controls...](https://www.cryptocoinsnews.com/1-bitcoin-community- controls-99-bitcoin-wealth/)

<comment><USER6> The original studies suggests early mining rewards were distributed mostly to a small group of users. It also shows attempts by large stakeholders to hide their large holdings by distributing funds across several wallet accounts.

If someone were to have monitored IP addresses in the swarm it may be possible to correlate attempts from single users hiding their funds across many wallets. Simply looking at the blockchain balances of single addresses will not necessarily indicate a single person controlling many addresses.

</comment></comment></comment></comment></comment></comment><comment><USER8> Considering the history of spoofed messages aimed at manipulating the market, they should have cryptographically signed the message

That said - if this is true, they've done the difficult but right thing.

<comment><USER9> It is my understanding that signed messages are generally frowned upon in the Bitcoin community, Satoshi never signed his messages.

This is because it is more important what is in the message than who wrote it.

<comment><USER10> > This is because it is more important what is in the message than who wrote > it.

not in this instance

<comment><USER9> > not in this instance

not really. why does it matter that this message is authentic? that 2x _really_ isn't going to happen? it can still happen, and it doesn't matter who posts what online.

<comment> TD-Linux Jeff Garzik was the only author of btc1, the primary 2x implementation. For it to survive for any length of time, someone needs to step up and take over code maintainership.

</comment></comment></comment></comment></comment><comment><USER11> Sadly, this exact scenario was predicted by multiple people and could have been avoided by making segwit and 2MB activate atomically at the same time. This is a huge embarrassment for big blockers; they have been completely politically out-maneuvered.

<comment><USER12> The likely reason Segwit was activated when it was is because there was a movement by non-2X supporters to forcibly activate it around that date, and the 2X side blinked first. It's as simple as that. Also, 2X is inherently harder to deploy than Segwit because it's a hard fork, which means that everyone everywhere would have to upgrade their software. Even the proposed timeline for 2X was quite aggressive - more so even the BIP-50 upgrade back in 2013, which unlike 2X was entirely uncontroversial and absolutely necessary because nodes running the old version would end up stuck on different forks from each other.

<comment><USER11> Yes, in retrospect this was a huge win for the UASF because they got segwit activated and no block size increase.

</comment></comment></comment><comment><USER13> "6 people called off the fork. Think about that." [0]

A censorship resistant digital cash is being built, and it only took 6 small time CEOs to completely throw everyone off and almost derail the project. When someone like CME Group, who now has skin in the game, also starts pulling their weight, who knows if the bitcoin experiment will survive?

[0] [https://twitter.com/arronschaar/status/928316853092433920](https://twitter.com/arronschaar/status/928316853092433920)

<comment><USER14> Contrast it to how many people it takes to block any on chain scaling. As everyone practically runs Core the power in practice lies with their maintainers.

Bitcoin as it is now is crippled. There is no reason to block on chain scaling except for the Core maintainers to retain their power and allow their second layer solutions to viable.

<comment><USER13> People choose to run Core and the network is worth 122 billion dollars. You haven't provided any good arguments for on chain scaling but the market is screaming "bitcoin is doing it right".

<comment><USER14> > You haven't provided any good arguments for on chain scaling

Multiple dollar fees doesn't require any more arguments. The lack of arguments against on chain scaling, backed by actual research, is what's lacking.

> but the market is screaming "bitcoin is doing it right".

Have you considered that it's driven by speculation instead of technical merit? When the blockchain becomes unusable due to high fees and congestion the bottom will fall out. It cannot be driven by pure speculation forever.

<comment><USER13> The pure speculators I know invest in smaller cap cryptocurrencies to maximize their gains. The only people I know invested in bitcoin are in because they believe in its long term value.

Anyway at this point you're trying to predict the future and I'm sharing anecdotes so we're not getting anywhere, let's tackle your main point:

> The lack of arguments against on chain scaling, backed by actual research, > is what's lacking.

The value of full nodes is widely understood by bitcoin contributors [0][1][2]. Increasing the block size directly increases the amount of resources required to run a full node. Increased bandwidth requirements is especially a problem.

It is up to the _candidate_ (s2x), not the _incumbent_ (core) to show that no, it won't be harder to run full nodes, or to show that you can have just as much security by running an SPV node. Because the candidate has failed to back up their proposal with evidence that security is not harmed, the proposal cannot be allowed to move forward. Makes sense?

[0] [https://www.reddit.com/r/BitcoinBeginners/comments/3eq3y7/fu...](https://www.reddit.com/r/BitcoinBeginners/comments/3eq3y7/full_node_question/ctk4lnd/)

[1] [https://medium.com/@morcos/no2x-full- nodes-889c20100a8d](https://medium.com/@morcos/no2x-full-nodes-889c20100a8d)

[2] [https://en.bitcoin.it/wiki/Full_node](https://en.bitcoin.it/wiki/Full_node)

<comment><USER14> So your only focus is on full nodes. So where's the research of how expensive nodes are and how many nodes would be lost if an upgrade to 2MB would happen? How big of a loss would be acceptable? Ideally how many nodes should exist in the network for it to be sufficiently decentralized? How much bandwidth is needed? How long can we expect our storage to last?

 _There is no credible research done_ , there are no numbers, yet even the smallest size increase is blocked.

It's also blocked by the same people who have previously supported even larger increases. What made them change their minds? Sure isn't any new research.

But the fundamental issue is that not everyone need to run a full node as long as you can connect to sufficiently many nodes yourself. There's simply no point in engaging in full node fetishism where everyone need to run one where the worst internet connection hamstrings the entire network. Most people run SPV wallets today anyway and the important nodes are the ones run by businesses and wallet services.

<comment><USER13> > So where's the research of how expensive nodes are and how many nodes would > be lost if an upgrade to 2MB would happen? How big of a loss would be > acceptable? Ideally how many nodes should exist in the network for it to be > sufficiently decentralized? How much bandwidth is needed? How long can we > expect our storage to last?

> There is no credible research done

That's precisely my point. Contributors have shown that full nodes are necessary to preserve the security of the network (see the links I posted), but the proposal of S2X was executed without ever engaging on a discussion to answer the very questions you are asking now.

They are good questions, and we should discuss them and we should answer them. But Jeff Garzik and the 5 other CEOs did not attempt to do this research and instead steamrolled ahead with btc1/s2x.

<comment><USER14> The damage the 1MB limit has done and is doing to Bitcoin is far more than possibly a couple of lost nodes would mean after an upgrade to 2MB.

This has been a problem for _years_. For example Gavin thought 16MB would be perfectly safe. There's research being done now examining 1GB blocks and how that would affect propagation time. A lousy 2MB is honestly laughable.

Doing nothing isn't the pragmatic or sane approach, it's the insane one.

<comment><USER13> In one post your criticism is that there is a lack of research, and I agree. But now you're making unsubstantiated claims again... the damage done to bitcoin? All meaningful metrics from BitPay's transaction volume [0] to on chain USD volume [1] to the price [2] shows that Bitcoin is doing fine and does not need saving. Public data shows that even though a fee market is developing, Bitcoin is still rising quickly in use and value.

As for the 1GB block research you're talking about, it was literally presented 5 days ago. S2X proposal started in May and the fork was planned for next week. The way we want this secure digital money thing to work is that proposals that are controversial or that may affect security are researched and the research is reviewed over many months or years.

I know you want to take the quick approach and just LOWER FEES NOW, but we know -- from experience -- that a cowboy attitude with blockchains makes it trivial to lose a lot of money [3].

[0] [https://blog.bitpay.com/bitpay- growth-2017/](https://blog.bitpay.com/bitpay-growth-2017/)

[1] [https://blockchain.info/charts/estimated-transaction- volume-...](https://blockchain.info/charts/estimated-transaction-volume- usd?daysAverageString=7&timespan=2years)

[2] [https://coinmarketcap.com/currencies/bitcoin/#charts](https://coinmarketcap.com/currencies/bitcoin/#charts)

[3] [https://www.cnbc.com/2017/11/08/accidental-bug-may-have- froz...](https://www.cnbc.com/2017/11/08/accidental-bug-may-have- frozen-280-worth-of-ether-on-parity-wallet.html)

<comment><USER14> > But now you're making unsubstantiated claims again... the damage done to > bitcoin?

How about comparing Bitcoin's percentage of total market capitalization [0] which crashed from ~80% down to ~40% when the blocks became full? The last month has regained that quite a bit but you could speculate it's because the promise of long overdue on chain capacity increase.

> I know you want to take the quick approach and just LOWER FEES NOW

It's been _years_ since the limit should have been increased. Yet here we are with no on chain scaling for Bitcoin even remotely close to reality.

> that a cowboy attitude with blockchains makes it trivial to lose a lot of > money

You're really comparing apples and oranges if you compare raising the block size with Ethereum's poorly designed smart contracts.

[0] [https://coinmarketcap.com/charts/](https://coinmarketcap.com/charts/)

</comment></comment></comment></comment></comment></comment></comment></comment></comment></comment><comment><USER15> The idea of "consensus" in the bitcoin network is interesting to me. The code expresses "consensus" mathematically, and there exists a binary truth of whether a consensus has been "reached." That's simple and straightforward. It's easy to reason about what happens once a consensus has been tautologically reached.

However, answering the question of "do we have a consensus yet?" is far less precise. Answering "what compromises can we make to achieve consensus," even less so. All deliberation and conversation must happen offline, in "meatspace" amongst humans and operating outside mathematical principles. For example with the segwit2x fork, there was the New York Agreement, discussion all over the internet, etc. But does anyone have a precise number for the "theoretical consensus" or is all discussion based entirely on estimates?

I've always thought the "51% consensus" and the "hard fork" idea were hand- wavy solutions to a problem that can fundamentally only be solved by human cooperation. I also think Satoshi never expected this kind of discontent to be such a common occurrence.

Bitcoin should include a consensus building layer of code that acts as an arbiter for building consensus. It could execute polls, enforce rules of deliberation, etc. This is basically decentralized voting, which is generally seen as a distinct topic from bitcoin. But it seems bitcoin, one of the biggest decentralized networks, could benefit from a consensus building protocol.

The problem of decentralized governance is not going away. Solving it will be a massive technological step forward.

<comment><USER13> I think the most promising work here is around fork futures. Paul Sztorc (of Bitcoin Hivemind, the original decentralized prediction market, and Drivechains) has a lot to say about how with fork futures, we can let the market tell us how valuable proposals are [0].

We saw this in practice with the numerous S2X futures that were available. They were all predicting that S2X had about 13% chance of winning. This signal can then be used as substantial evidence in meatspace to retract or push forward a proposal.

[0] [http://www.truthcoin.info/blog/fork- futures/](http://www.truthcoin.info/blog/fork-futures/)

</comment></comment><comment><USER16> I still don't really understand why people were so against a block size increase.

I get that there are centralisation risks if the block size increases too much, but it doesn't really seem as though increasing to 2mb really make such a big difference?

Am I missing something?

<comment><USER14> There are no real technical arguments against increasing to 2MB, only political.

The main actors against a block size increase are Core developers who are also part of a company called Blockstream. Blockstream's business model is about selling side chains. But why use side chains if you can use on chain transactions instead? Well if you limit on chain scaling users would be forced on to your side chains...

The movement against the Segwit2x upgrade was so fierce precisely because it threatened to offset Core as the de facto Bitcoin client, making them loose their power.

They profit heavily from censorship on the bitcoin mailing list, the "bitcoin" subreddit and bitcoin.org. Their consistent propaganda and abuse has now caused the miners and businesses to back down on the Segwit2x upgrade, which would have been a certainty with 95% hashpower and business support.

Keep these things in mind and you should get a better picture.

<comment><USER17> There is also the contention that increasing blocksize would make running full nodes harder (at least by some margin) which therefore means an increase in centralisation (by a proportional margin). It would also set a precedent that miners are in control (or alternatively it could be interpreted as no-one is in control). The question then transaction speed and low fees are more important than the marginal increase in centralisation. Core would argue that any increase in centralisation is too much. Not sure why they think middle men are acceptable though.

<comment><USER14> > There is also the contention that increasing blocksize would make running > full nodes harder (at least by some margin) which therefore means an > increase in centralisation (by a proportional margin)

Yet there is no attempt to quantify by how much. The damage done to Bitcoin by full blocks is much more than what a potential increase to 2MB would cause. This zero tolerance policy rhymes extremely poorly when the fees makes Bitcoin more expensive to use than to run a full node.

> It would also set a precedent that miners are in control (or alternatively > it could be interpreted as no-one is in control).

Miners are in control because the real power lies with them. The problem is that they aren't coordinated and so status quo is favored.

</comment></comment></comment></comment><comment><USER18> I guess this is one of the merits of proof-of-work: force miners to mine on one chain only, and if the token on the fork is worth less compared to their relative increase in hash rate on the fork, they lose money.

In my opinion, the financial motive of miners played a big role in this decision, and that's exactly what proof-of-work is supposed to achieve: consensus through selfish miners.

Has anyone done the math on the profitability of Bitcoin Cash miners versus regular Bitcoin miners?

<comment><USER19> It's graphed in real time: [https://fork.lol/](https://fork.lol/)

<comment><USER18> Awesome! Not as clear-cut as I thought, though.

The BCH income also seems a lot less stable than for BTC; shooting up to twice as profitable as BTC and then down to half as profitable. I assume there's quite a lot of variance in the time-between-blocks in the BCH network.

</comment></comment></comment><comment><USER10> Wise decision. Surprised to see Jihan Wu sign it too.

I hope this brings some peace to to the community.

</comment><comment><USER20> A few altcoins immediately went +20% up - NEO, IOTA, Omnise, Lisk, Waves, Ark. But not the ones I expected - like Ethereum.

<comment><USER21> Doesn't Ethereum have its own problems right now?

<comment><USER20> Not ethereum, but one of the contracts written on top of it had a bug that some newbie triggered by mistake and locked something like $160M worth of moneys.

<comment> wc- Ethereum's value, its reason for existing, is the deployment and operation of smart contracts.

When one of the most popular semi-complex smart contracts fails not once but twice in a matter of months (losing hundreds of millions USD in the process), it is time to look not at the newbie or the contract programmer, but the platform itself.

<comment><USER20> Ethereum works fine as a currency too (~15 sec per block, quite nice). It also works fine with simple contracts, it's the humans who aren't good enough (yet) to write bug-free code.

Bugs in software of various kinds cause billions of dollars worth of damage, deaths too. Yet I don't see people claiming it's the fault of C++.

<comment><USER16> _Yet I don 't see people claiming it's the fault of C++_

A major driving force behind the development of Rust is that exact claim.

<comment><USER20> I doubt software written in Rust has no bugs.

<comment><USER16> I don't think anyone is claiming that, it does however seem quite likely that it will have less.

</comment></comment></comment></comment></comment></comment></comment></comment><comment><USER22> What a great way to manipulate the market.

<comment><USER23> I don't understand this desire to immediately assume bad faith in these situations. It's a complicated situation, involving a lot of actors. Yeah, probably some of them are acting in bad faith. But probably most of them are just trying to develop a functional cryptocurrency. This stuff is very hard, and having it all so decentralized only makes it harder.

Personally I was hoping for the 2x fork to succeed, or, barring that, for some kind of miracle switch over to Bitcoin Cash, which has the 8x capacity without the baggage of Segwit. But realistically this is probably the best outcome for Bitcoin for the reasons outlined in the message.

<comment><USER24> What's your opposition to SegWit?

<comment><USER25> I can't speak for the user thefalcon you replied to, but most opposition as I understand it comes from the fact that segregated witness makes things more likely to rely on centralized infrastructure, departing from the original vision of bitcoin as a decentralized system that can't be controlled by entities like governments and banks.

<comment><USER10> > but most opposition as I understand it comes from the fact that segregated > witness makes things more likely to rely on centralized infrastructure

That simply isn't true. It's just a new transaction format.

</comment></comment></comment></comment></comment><comment><USER26> > Bitcoin remains the greatest form of money mankind has > ever seen, and we > remain dedicated to protecting and > fostering its growth worldwide.

How sad that people are lured into "money" and selling and buying "money" while not understanding that provision of products and services are the most valuable in the world, and that any money is just a certificate of trust exchangeable for such products or services.

Bitcoin is nothing but speculation and this kind of forks cannot make it better. Basic agreements especially relating to money shall never be changed or people loose trust in it.

</comment><comment><USER27> Mike Belshe, Wences Casares, Jihan Wu, Jeff Garzik, Peter Smith and Erik Voorhees.

Don't have anything against those guys but what was that part about decentralized crypto-currency that no one agency or government oversights?

</comment><comment><USER28> So... this should probably mean a deep dive for btc price then, right?

<comment><USER29> I checked coinbase expected exactly that, thinking "oh man, I'm glad I didn't sell my eth a month ago to buy into bc trying to capture free altcoins like others did and like I considered doing, it'll be down like 10% at least" but it... shot up about 10% instead. I don't get it.

<comment><USER30> Having too many forks makes it confusing for newcomers (and even hedge funds). So naturally avoiding a fork and keeping the community together is good for Bitcoin, which made the price go up.

<comment><USER31> The speculation prior was the the fork was driving people to buy BTC - <USER2> the expectation of a correction.

<comment><USER32> on wex it went up as high as $7900 and as low as $7000 so it is still very volatile, I would expect more of a sell off as people who bought in hoping to capitalise on a fork now exit their position but this may also mean more risk averse investors will buy in now that there is no contentious fork due. so, as usual with bitcoin, no one knows what the hell is going to happen

</comment></comment></comment></comment></comment><comment><USER33> The note states there was not enough consensus (only 30%) How much consensus would be quorum for this sort of shift? Making a hardfork is really a last resort. If we are trying to increase transaction capacity, is blocksize really the most efficient way to go about it (without screwing up the other aspects of BTC)?

<comment><USER34> The support for the earlier Segwit change was only 30%. The advertised support for this 2x change was over 80%.

</comment></comment><comment><USER35> It would be incredibly interesting to see who opened short positions shortly before this announcement.

I'd be willing to bet at least a few of the names at the bottom of that message are among them.

</comment><comment><USER27> Looking whats happening on Ethenerum, those who knew in advance already made fortune. Funny we don't have SEC actually able to look into these. Amazing times.

<comment><USER36> up a whole $10 ..not exactly 'making a fortune'

<comment><USER37> A $10 shift is a fortune in arbitrage.

If you have insider info about the direction of a market, then you have a much reduced risk. You can move in big, take your bite of the change, and then cash out.

<comment><USER38> In something as volatile as crypto, ethereum's 3.3% shift is not worth the risk.

</comment></comment></comment></comment><comment><USER39> Wow! Site is down, can someone copy the text over here?

<comment><USER23> The Segwit2x effort began in May with a simple purpose: to increase the blocksize and improve Bitcoin scalability. At the time, the Bitcoin community was in crisis after nearly 3 years of heavy debate, and consensus for Segwit seemed like a distant mirage with only 30% support among miners. Segwit2x found its first success in August, as it broke the deadlock and quickly led to Segwit's successful activation. Since that time, the team shifted its efforts to phase two of the project - a 2MB blocksize increase.

Our goal has always been a smooth upgrade for Bitcoin. Although we strongly believe in the need for a larger blocksize, there is something we believe is even more important: keeping the community together. Unfortunately, it is clear that we have not built sufficient consensus for a clean blocksize upgrade at this time. Continuing on the current path could divide the community and be a setback to Bitcoin's growth. This was never the goal of Segwit2x.

As fees rise on the blockchain, we believe it will eventually become obvious that on-chain capacity increases are necessary. When that happens, we hope the community will come together and find a solution, possibly with a blocksize increase. Until then, we are suspending our plans for the upcoming 2MB upgrade.

We want to thank everyone that contributed constructively to Segwit2x, whether you were in favor or against. Your efforts are what makes Bitcoin great. Bitcoin remains the greatest form of money mankind has ever seen, and we remain dedicated to protecting and fostering its growth worldwide.

Mike Belshe, Wences Casares, Jihan Wu, Jeff Garzik, Peter Smith and Erik Voorhees

\--

 _Mike Belshe_ _CEO, BitGo, Inc_

</comment></comment><comment><USER36> total meltdown. sell on news event ...wow. I think a lot of people were buying in anticipation of getting an alt coin, which is not going to happen. Given that alt coins are falling now, this looks like just another capitulation event, with the fork cancellation being the trigger.

</comment><comment><USER18> Interesting move on the price chart after this announcement: [https://i.imgur.com/EkxgJb2_d.jpg?maxwidth=640&fidelity=high](https://i.imgur.com/EkxgJb2_d.jpg?maxwidth=640&fidelity=high)

The activity starts 11 minutes after the email.

</comment><comment><USER40> To the moon!

</comment><comment><USER41> Bitcoin will do very well...until it doesn't.

</comment><comment><USER42> Here comes the alt flood.

</comment><comment><USER43> This is just one guy, Mike Belshe, declaring his intention not to participate in the hard fork. Meanwhile, the miner support for the fork is still over 80% [0]. So it's pretty clear he doesn't speak for the majority.

[0] [https://coin.dance/blocks](https://coin.dance/blocks)</comment>


Ask HN: How did Sublime Text get traction? - <AUTHOR> Sublime Text is a successful product in a crowded space, overwhelmed by open source alternatives.<p>How did the product get its initial traction, given the apparent lack of resources devoted to marketing/support? <comment><USER2> While it's not open source it is functional without a license, so the payment isn't really a barrier to usage, much like most people are using WinRar without ever paying for it.

Functionality and ascetics are just better than any of the other text editors that I've used in the past, plus I'm happy with it so don't really go looking at alternatives these days.

When I first went to OSX a few years back TextMate seemed to be the dominant editor, Sublime for me just naturally replaced that with improved visuals and features. When your watching tutorial videos and the person is doing magic in a text editor, you start to question why am I still using my current one that doesn't have them features.

Marketing was just word of mouth, and how much support do you really need for a text editor? If it breaks it's not like you can't find another one to use...

<comment><USER3> Aesthetics. Ascetics are people who abstain from certain life pleasures.

<comment><USER4> Lucky typo lands on an interesting word!

</comment></comment></comment><comment><USER5> For those of you who think $70 is too much for a text editor, consider how often you use Sublime Text. I personally use it every day, 5+ hours a day, 25+ hours a week. In just two weeks it's down to $1/hour. In one month it's down to $2.50/day. In 3 months, $1/day. In a year, you're paying pennies per day of use.

If you're a heavy Sublime Text editor that hasn't bought a license yet and don't care that much for Atom/Visual Studio, consider buying a license. It supports the author and you're getting your money's worth, imo.

That's my two cents (or more to the point: 3 days of Sublime Text usage).

<comment><USER6> That's exactly how I rationalised it. I use it damn near every day and it's one of the first things I open when I start up my computer at home or at work.

</comment></comment><comment><USER7> When sublime text gained it's traction, the scene was a little less crowded. Atom was not available at that time.

I think it gained traction on OS X. The dominant text editors for OS X at the time were Textmate and Coda. The development of Textmate stalled and people were looking for an alternative. Coda had a very different approach from Textmate (you were either a Textmate or a Coda gay/gal, never both), and Sublime really comes close to Textmate.

<comment><USER8> TIL Coda users are either female or homosexual. Never knew that choice of text editors was correlated with sexual preference.

<comment><USER7> Hmm, stupid typo. Can't edit the comment anymore :(

</comment></comment></comment><comment><USER9> Editors I used on OSX before sublime text:

\- textmate \- BBEdit

Before I was an OSX user, my editor of choice in Windows was Crimson Editor.

All of these have two things in common: simplicity and speed. They are extremely simple to use, but also have some powerful features (if I didn't have to resort to perl most of the time, I was happy). And they didn't hog system memory or hang when editing large files.

Textmate added something to the mix: It was pleasant on the eyes. I'm a big fan of dark themes.

When sublime text came along, it added the absolute killer feature: "do anything" typing. I'm a HUGE keyboard navigator, avoiding mouse pointing a lot in favor of keystrokes. The ability to hit Cmd+P and type a couple letters of what I want to do and sublime text prompts. I can open files, edit in several ways, find and replace, do a build, whatever I want, all from the home row.

If there's ever a better editor than sublime text, it would have to be an IDE that brings fast, efficient, memorable keyboard-only navigation. And current IDEs do a decent job of this, although they're way sluggish compared to sublime text, and not as feature rich.

</comment><comment><USER10> My experience is that Sublime looks/works great out of the box, colleagues actually asked "what's that editor?" before monokai/solarized were widely known.

Recommending it is pretty easy: Less crashes than Eclipse/Atom; less setup, tinkering and learning curve than vim/emacs. Just works, cross-platform.

Finally, in a professional setting, the cost of Sublime is completely negligible vs e.g. losing work from crashes or even messing around with vim for two hours.

</comment><comment><USER11> Not sure why ST gained traction with other but here is why I love it.

Notepad++ was text editor for me. ST was a sexy thing. I was drooling.

I am yet to buy a license for ST but I use it always.

As a guy from an IDE heavy dev background, I was impressed that I can carry around my dev tool in a USB and also keep it in a folder on the network. Plus if a version is acting weird, I have can just trash-&-switch. I had many issues with VS acting nuts and it took more than 1 day to repair it. That is what push me to leave IDE oriented development. I am happy with a customized/tweaked text editor approach.

A negative:

Now I am playing more with Atom (ST clone) as its open source and more than 1 dev is involved. So, I will not be forced to change if the dev suddenly decides to stop. That is the main attraction for me in terms of the app being open source. I know that someone will continue and if I am desperate, I can attempt to tweak the app.

Despite the huge size of Atom, one thing that attracted me to it was the aesthetics aspect. ST was missing something.

<comment><USER12> >I am yet to buy a license for ST but I use it always.

Same. I really wish they would drop the price a bit. I'd love to support the developers, but $70 for a text editor is just crazy.

<comment><USER13> Yea, it's just not affordable to me.

I'd love to use it as I'm tired of using 7+ IDEs and I'd like to migrate to a "One True IDE"

Being a college student that's unemployed 70$ is a bit steep.

</comment></comment></comment><comment><USER14> Sublime Text got it's initial traction because it was essentially TextMate's cross platform little brother. When your friend couldn't use TextMate on his Windows machine, you told him to go get Sublime. It might have even been linked to from the mate TextMate site under the question, "what about Windows Support"

</comment><comment><USER15> Because of the ongoing share of OSX among Devs/Devops and the fact that it is multiplatform. When I switched from Windows to a Mac a few years ago, I found the text editors somewhat lacking until I discovered ST. I still needed and need to RDP to Windows so the fact that was multiplatform sold me.

So in my opinion, it found a niche but growing market in OS X that had network effects in other platforms.

Regarding the business side as lost opportunity to get more revenue, it's important to know that success is a state of mind. I'm quite confident that the current state of things regarding ST business fall within the comfort zone of its creator and that he has amassed more money than he can spend.

</comment><comment><USER16> I have Sublime and I paid for a license. It's my second editor of choice and I like how it integrates with the OS better than terminal Vim (my number 1 editor of choice) on OS X (drag and drop files onto the Dock icon for example for a quick edit). My only nitpick about Sublime is that I don't like how it looks (Chrome like) instead of the native OS X GUI widgets.

I'm curious though, since TextMate 2 is open source and is regularly updated why is it not as popular for OS X users? What's the turn off that makes Sublime that much better?

</comment><comment><USER17> Sublime's out of the box theme attracted people and it's demonic speed and the Goto-Anything feature got them talking about it. Atleast that is my take.

</comment><comment><USER18> It is better than alternatives (faster, easier to use)

It is cheaper than alternatives (time, licence)

It was introduced in right time (surge in web boom)

It have easy to use API (Python vs Elisp)

It is cross-platform (*nix comeback)

</comment><comment><USER19> I remember trying it out and saw how fast it loaded. Never looked back.

I never thought it needed support, it just does what it is supposed to.

</comment><comment><USER20> How sure are we that it really has traction, and the business sense? I paid for my license, and I meet lots and lots of people using lots of editors including Sublime, and from this (smallish, and perhaps bad) sample only a tiny fraction of users have paid for it.

</comment><comment><USER21> Simple, easy. And used on huge amounts of instructional videos, leading influence of others.</comment>


Making Direct3D games faster in Wine using modern OpenGL - <AUTHOR> https://comminos.com/posts/2018-02-21-wined3d-profiling.html <comment><USER2> I'm fascinated by how someone with this domain level knowledge finds a problem like this and solves it.

Is there some correlation between WoW players and wine/graphics programmers?

Is this a game dev who happens to play WoW?

Externally, the phenomenon of a gamer (i.e. user) having domain level knowledge of complex technical understanding is intriguing.

(I'm partially motivated by the fact that as a generalist programmer I don't think id get anywhere the level of understanding needed to produce something like this)

<comment><USER3> This guy had a problem, slow fps in a game, knew the generalized view of how Wine worked, and used the tools they knew of to try to fix the problem.

I've never written a line of DX, GL, etc but I know what command buffers / driver synchronization / AZDO are like this article mentions.

I also play WoW on Linux, and am kind of embarassed I didn't think to try perf monitoring the game for easy to fix huge slowdowns like this. I kind of assumed since WoW is one of the most popular Wine games and generally pushes the DX api support to make sure it always works that the main Wine devs would optimize it more.

That being said, buffer_storage is a GL 4.4 extension and Wine has this awful habit of trying to strictly support OSX, which will never see OpenGL beyond 4.1, and I'm not sure if buffer_storage is available there. That alone might mean these patches are never merged mainline, which would be... inconvenient.

</comment></comment><comment><USER4> "Fundamentally, it's a function that maps a slice of GPU memory into the host's address space, typically for streaming geometry data or texture uploads"

Can someone clarify this for me? Are OpenGL/D3D buffers that get stuff memcpy'd into them by the CPU actually "slices of GPU memory," or are they more often reserved driver memory that eventually get DMA'd to the GPU? (I realize both probably happen at different times, but I'm curious which is more typical for modern systems)

It seems like spending CPU cycles writing every byte over the bus would perform much worse than a fast write to sysmem followed by a DMA transfer.

EDIT: I looked into it, and it seems like the typical implementation is that map returns a pointer to some pinned driver sysmem and unmap kicks off an async DMA to GPU memory.

<comment><USER5> > Can someone clarify this for me? Are OpenGL/D3D buffers that get stuff > memcpy'd into them by the CPU actually "slices of GPU memory," or are they > more often reserved driver memory that eventually get DMA'd to the GPU?

The answer is, as with all things OpenGL, it depends. You might get back a pointer to GPU memory that you can directly write to, or you'll get back some chunk of system memory the driver has.

The ARB_buffer_storage extension improves matters as you can almost guarantee that you'll get GPU memory, and you can keep it mapped for the entire lifetime of your application (the old buffer APIs wouldn't let you keep it mapped during a draw call). The downside is that you're now responsible for synchronising access to that data.

But as for "is it quicker?", maybe. DMA transfers aren't free, they take time to setup. Usually they need to operate from a limited pool of source memory. If the driver has to take a local copy of your data to copy it (which it will do for every glBufferData/SubData call), then you might as well copy it yourself, GPUs aren't hurting for PCIe bandwidth these days. In addition, you can use a separate thread/CPU core to do the copy, since unlike every other OpenGL call, mapping memory and memcpy'ing doesn't require an OpenGL context.

</comment></comment><comment><USER6> The site looks beautiful and loads insanely fast. Can we easily reuse the whole theme?

<comment><USER7> It is delightfully simple, nice and clean.

A pleasing font family, no JavaScript, some basic CSS, stick to basic HTML tags and use them properly.

[https://comminos.com/css/default.css](https://comminos.com/css/default.css)

<comment> Tech-Noir > no JavaScript

Not to knock an otherwise nice site (CTRL & \+ improves readability for me personally, though), but:

        (function(d, s, id) {
          var js, fjs = d.getElementsByTagName(s)[0];
          if (d.getElementById(id)) return;
          js = d.createElement(s); js.id = id;
          js.src = 'https://connect.facebook.net/en_US/sdk.js#blahblahblah';
          fjs.parentNode.insertBefore(js, fjs);
        }(document, 'script', 'facebook-jssdk'));

AFAIK, even for sites that want to feed the monster, that's unnecessary:

[http://chrisltd.com/blog/2015/04/social-share-like- buttons-w...](http://chrisltd.com/blog/2015/04/social-share-like-buttons- without-javascript/)

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

<comment><USER8> So I decided to test the christld ones:

Twitter seems to work (brings up form).

Facebook redirects to an error.

Linkedin seems to work (brings up form when logged in).

Pinterest seems to work (brought up create board dialog when logged in)

Google+ seems to work (brings up share form).

I do have to say that for me that these would actually work and the JS likely wouldn't in some cases, since I make _heavy_ use of Firefox's containers now to sandbox a lot of online identities, and just have new windows for certain URLs automatically load in the correct container.

<comment> Tech-Noir Thanks, that's interesting. The chrisltd blog is from 2015, so I did wonder if some of it might be out of date by now.

AFAICS (which I didn't notice at first) sharingbuttons has a slightly different FB URL, which may not give an error:

[https://facebook.com/sharer/sharer.php?u=YOUR- URL](https://facebook.com/sharer/sharer.php?u=YOUR-URL)

Compared to chrisltd's:

[https://facebook.com/sharer.php?u=YOUR- URL](https://facebook.com/sharer.php?u=YOUR-URL)

</comment></comment></comment></comment></comment><comment><USER9> This a great and concise writeup, thanks.

But I was left wondering what the actual problem was. Why is glBufferMap slow? Is it just the impedance mismatch between D3D and GL that don't have the same synchronization guarantees for that specific call? Why does Wine have it's own command handling thread when very likely, the underlying OpenGL driver has one, too?

<comment><USER10> glMapBuffer doesn't have any ability to declare that you won't overwrite data. All you can say is whether you want read/write access to the buffer. So the driver has to assume that the client might overwrite in-flight data, so synchronization is required.

As for the command stream handling, it makes decent sense to do translation up-front and your drawing commands into a command stream so a separate thread can just hammer through it as fast as possible, rather than doing GL calls in- line with the translation. Partly so the game can return to doing its thing as fast as possible, and partly to fix issues with GL's threading model being horrible ( see e.g. [https://bugs.winehq.org/show_bug.cgi?id=24684](https://bugs.winehq.org/show_bug.cgi?id=24684) )

<comment><USER11> > glMapBuffer doesn't have any ability to declare that you won't overwrite > data.

Well, yes and no. glMapBuffer _Range_ , which is basically a drop-in replacement for glMapBuffer, does have such a flag, it's GL_MAP_UNSYNCHRONIZED_BIT.

glMapBufferRange requires OpenGL 3.0 whereas glMapBuffer exists all the way back to OpenGL 2.0 but this looks more like just an oversight in Wine than anything else.

<comment><USER4> Wine uses glMapBufferRange when available, and has logic to translate D3DLOCK_NOOVERWRITE to GL_MAP_UNSYNCHRONIZED_BIT. I don't understand what the current implementation is doing that is causing wined3d_resource_map to block.

[https://github.com/wine- mirror/wine/blob/538263d0efe725124df...](https://github.com/wine- mirror/wine/blob/538263d0efe725124df88ce1cce124bc3ad7e2af/dlls/wined3d/resource.c#L422)

</comment></comment></comment></comment><comment><USER12> Another option is using gallium nine, which directly uses D3D state tracker in driver skipping GL layer. [https://wiki.ixit.cz/d3d9](https://wiki.ixit.cz/d3d9) (though on nvidia nouvenau will be probably slower than propertiary GL driver)

<comment><USER13> Weird, since Nouveau itself is based on Gallium.

<comment><USER12> I mean that D3D -> Nouveau could be still slower than D3D -> GL -> NVIDIA.

</comment></comment></comment><comment><USER14> Excellent writeup. I would be curious as to the specific considerations given to a heap allocator on the GPU. Related: I'm not too familiar with Wine patches - what is the easiest way to view the final source code of this patch?

</comment><comment><USER15> Very nice article and project! Have you talked with Wine people to see if you could eventually merge your patch in the official codebase? Seems like it would help a lot of us linux gamers :)

<comment><USER16> From the article: "I hope to mainline this once the patchset becomes more mature."

</comment></comment><comment><USER17> Wined3d probably can use Vulcan instead of OpenGL in the future. Did anyone start working on such a port?

<comment><USER18> There's VK9 for Direct3D 9, DXVK for Direct3D 11, and the official Wine- supported VKD3D for DirectX 12.

[https://github.com/disks86/VK9](https://github.com/disks86/VK9) [https://github.com/doitsujin/dxvk](https://github.com/doitsujin/dxvk) [https://source.winehq.org/git/vkd3d.git/](https://source.winehq.org/git/vkd3d.git/)

</comment></comment><comment><USER19> Really cool! Would love if the blog had RSS though!

<comment><USER16> Just for you <3 [https://huginn.lin.anticlack.com/users/1/web_requests/80/com...](https://huginn.lin.anticlack.com/users/1/web_requests/80/comminos.xml)</comment></comment>


Swift Changes Considered Harmful - <AUTHOR> http://furbo.org/2017/02/17/swift-changes-considered-harmful/ <comment><USER3> I work in Swift 7 days a week (sadly 7) but I am quite happy despite the changes, it's an open source language built entirely in the open by contributions from people who care. What the hell is there to complain about, would you rather work in 50+ year old cobol? I've used ObjC since the NeXT days and despite much of our codebase (not our part) is still in that language I am always glad to be working on our part in a nice modern language. It's only 3 years old. Go is almost 5 (announced like 8 years ago and started 10), Ruby and Java are antiques in comparison at 20+, ObjC itself is 30 years old, C is 40, C++ is around 25. Rust is about the only comparable aged language, and it isn't used in any single environment as large as iOS and OSX. Swift is 3. Yet it's fun and productive to work in (other than compile times which suck, and debugging which is painful sometimes, and Xcode is ugh). Sure often I have to look up what the current syntax is, but it's still lightyears easier than remembering C++ details (another language I spent a fair amount of time in in the past) which also change from year to year. Debugging STL still gives me nightmares.

Cyanide is considered harmful. Opinions are just opinions, but calling something harmful when you just don't like it should be considered silly.

<comment><USER4> > What the hell is there to complain about, would you rather work in 50+ year > old cobol?

I'd rather work on modern AND stable language (I actually do, its not Swift, buy that's not my point). Broken code samples is a good reason to complain. Swift is a moving target, it will be for a while, and this is real pain... but its not a secret. If it bothers someone, why would they choose to use it?

<comment><USER5> > I'd rather work on modern AND stable language (I actually do, its not Swift, > buy that's not my point)

Greetings fellow Rust user ;)

</comment></comment></comment><comment><USER6> I don't agree with this. Presumably this is going to be a long lived language. They should fix the problems as early as possible so that generations of developers don't have to keep reliving the same pain.

<comment><USER7> I think his main complaint is that Apple should stop publishing sample code (which they update sporadically at best) in Swift when the language is changing so much. At WWDC this year I believe virtually all code shown on screen was Swift, but ObjC would have been fine for almost everything.

More broadly, I think Apple should have marketed Swift as "beta" until at least v3, to really make clear (especially to managers) what it means to have a language with constant source-breaking changes.

<comment><USER8> " should stop publishing sample code (which they update sporadically at best)"

Ah? No. 'Sample code' is essential, often more valuable than the docs.

They are a $700 Billion dollar company.

You know what they can afford to do?

Have _more_ sample code, _better_ documentation - and update all of the goddam samples, moreover, to make it clear in each sample, which version applies.

<comment><USER7> You cut the quote off too early, I think they should have sample code in ObjC rather than Swift

</comment></comment></comment></comment><comment><USER9> This is already being done.

Swift 4 (unreleased) has source compatibility with Swift 3 [0], so all Swift code working today should work in the next version, no migrator necessary.

Additionally, _the_ goal of Swift 4 is to finalize the ABI. Once that is done, you can mix and match different Swift versions in the same project.

The real "problem" here is that Swift wants to be a "big" language, in the vein of C++ or Rust, as opposed to a "small" language like C or JS where you can read one book. (Swift does have a book, it's 1200 pages.) There's a lot of "stuff": a complex typesystem, many basetypes, generics, extensions, both static and dynamic dispatch, programmer-assisted memory management, closures, visibility, ephemerals, optionals, a mutability-based memory model, etc. etc.

Inevitably some of that stuff won't be quite right and so you have churn. But ideally you only need 10% of those (it's just that everybody needs a different 10%) and so the amount of churn you personally have to deal with should be low, and can be lower with the appropriate tooling.

[0] [https://swift.org/blog/swift-4-0-release- process/](https://swift.org/blog/swift-4-0-release-process/)

[1] [https://github.com/apple/swift-evolution](https://github.com/apple/swift- evolution)

<comment><USER8> "Swift wants to be a "big" language"

My guess is that it is not ideological. Swift feels like it wants to be 'everything'.

Because of this, it's almost too much.

I want to like Swift, but I run into a lot of trouble with it.

The decision to be compatible with ObjC was one of the big issues: obviously, pragmatically, they felt that they just had to do it. In hindsight, I wonder if it would have been better to just have a clean break.

<comment><USER4> > In hindsight, I wonder if it would have been better to just have a clean > break.

Language-wise - sure, it adds a lot of complexity. Platform-wise, they would risk people staying on what they had and ignoring Swift entirely, and that would mean Apple would need to support objective-c a lot longer than they want to.

<comment><USER8> Yes, that is the rationale.

But I wonder. They are a $700B company. What if they just 'did it right' \- i.e. made sure all of the APIs and documentation were available in 'new Swift' which had no relation to ObjC.

Because the 'fallback on ObjC' has more problems than integration.

A lot of people want to make apps for iPhone and ObjC is not in their vocab. Me, for example.

Swift could have been an easy-to-approach language.

But because of 1) lack of docs and 2) dependency on a lot of ObjC residue ... guess what? To make app in 'Swift' \- you still had better know a lot of ObjC!

So - to really make use of 'the new' \- you still have to know 'the old' \- which totally defeats the purpose!

I wish they had made a clean break - great docs, examples that are _clear_ and _well marked_ in terms of versions, all new APIs for Swift, left in beta for longer, and made mostly backwards compatible changes. And left a few things out.

<comment><USER4> > They are a $700B company.

But many of their customers aren't. Lot of them have no budget (or will) for complete rewrite. And if you force them (or just make them believe you may do it) they will complain and it means bad press, in a very competitive market. It may not be something Apple can afford.

> What if they just 'did it right'

You can't "did it right" without support of large amount of users, regardless of the money. The definition of "right" in programming languages is "works for users". And to get users onboard, you have make sacrifices.

> A lot of people want to make apps for iPhone and ObjC is not in their vocab.

And even more has existing apps to maintain. Tradeoffs have to be made.

> great docs, examples that are clear and well marked in terms of versions, > all new APIs for Swift, left in beta for longer, and made mostly backwards > compatible changes

All those things will come. If you want them, wait for them. Being early adopter has its cons.

<comment><USER8> "Lot of them have no budget (or will) for complete rewrite. "

I don't mean they should force people onto Swift. I mean that Swift, should be totally independent of ObjC, so that customers, if they choose to use it are not dependent on it.

Also - Apple could feasibly provide a 'lib/bridge' \- just as Android can use C++ code as well, if you want to use it.

I think Apple could surely commit to keeping ObjC around for quite some time - maybe 4 years official support, and then maybe 8 years on the devices, but with no more documentation/support.

"All those things will come. If you want them, wait for them."

I don't agree - this is 'doing it wrong'. It's been out for _years_. This is way past 'early adoption'.

'Doing it right' means that it is _easy_ for new and old developers. Right now - it's hard.

Doing Swift 'right':

1) Make Swift a clean break, get rid of some of the more obscure things that make it difficult. Get rid of relationship to ObjC.

2) Detailed docs, tons of examples. Examples for every single class, every single attribute. 100% of functionality should be 'explainable by example'.

3) Beta for 1 year, then production.

4) No backwards-incompatible changes after out of beta. (Easier said than done).

5) Docs, examples etc that clearly demarcate versioning.

6) Tons of support on Stack Exchange: dedicated staff to simply monitoring, answering, clarifying issues just on Stack Exchange.

7) 'Free Support and Training' for anyone who wants it and who can make it to a major city, i.e. NYC Jan 1-5 or 'weekend course' for anyone who registers. Free. Once every few months. At least 100 Engineers just doing training, and going into dev/studios companies to help them with stuff.

8) Free online courses, for newbs, and those coming from other languages, and Objc.

They made Swift a little too complicated, and left devs hanging in the dark on so many issues.

<comment><USER4> > I don't mean they should force people onto Swift. I mean that Swift, should > be totally independent of ObjC

If you will not provide seamless integration, you will seriously limit amount of people who migrate. There are other problems here too: what should library authors do? Write two versions?

> It's been out for years. This is way past 'early adoption'.

Looking at all programming languages I've ever used, getting out of this childhood period always took years. Sure, Apple could do better job perhaps in many aspects, but it really takes a very long time to get a language and stdlib to usable shape.

>Make Swift a clean break, get rid of some of the more obscure things that make it difficult.

If you make a clean break, you limit amount of your users. Without users, you can't tell what obscure things are difficult for those who didn't opt in.

I agree with all those beta periods, stability guarantees, docs and training. I am now appreciating more how well those things work in Rust.

<comment><USER8> "If you will not provide seamless integration, you will seriously limit amount of people who migrate. "

I don't agree at all.

Tons of people are 'starting out' on Swift - moreover - if Swift were done a little better - it would actually be used on other platforms, etc. - <USER2> opposed to an 'iPhone only' type thing.

New projects start all the time.

Major re-factors and re-writes happen all the time.

Second - I do not believe that the premise of: "well I can switch _some_ of my code to Swift, but keep most of my libs on ObjC" \- is reasonable. This is a minority case.

And of course - as I said - they could have provided access to ObjC libraries through an interface exactly as Android does.

You want to use 'legacy C++ code' on Android? You can do it. It's just not so clean, but you can do it. The same should have been provided for Swift-ObjC

So - companies who don't want to migrate - can stick to ObjC for a few more years.

The rest can switch over.

"If you make a clean break, you limit amount of your users."

Again I don't agree at all. Node.js has more developers than Swift. With Apple backing it (i.e. 'making it good' \- but also making it 'the basis for iPhone) - they could have had an incredible number of users.

There's no reason that Swift couldn't have been used in internal-alpha for a while, then external beta for a while - then then have a 'solid v1'.

AS you say - many languages were 'around for a long time' \- but they have also been _stable_ for a long time!

Java for example, did not do anything at the .lang level that was not backwards compatible. The only non-backwards compatible bit was java AWT, which they replaced with Swing. But even AWT is still supported!

So, there's no excuse for rapid rollout of versions that are incompatible with one another, no excuses for huge gaps in documentation etc..

</comment></comment></comment></comment></comment></comment></comment></comment><comment><USER10> Swift changes _are_ harmful if you are building a product with a budget.

I don't have any problem with the fact Swift is churning. I think its healthy for the language to be improved. I think it's great that there is so much open source activity and enthusiasm around it.

But I also think Apple have been premature about pushing it for sample code and WWDC talks. And some companies have adopted it too early given their resources, constraints and objectives.

Yes it's a lot of fun from an engineering perspective to be on that bleeding edge. It's not so much fun when your boss/client/own business has a tight deadline to ship something, but then you have the extra work to migrate your code to the latest Swift changes.

edits: fixed a couple of typos.

</comment><comment><USER11> "Considered Harmful" Essays Considered Harmful: [http://meyerweb.com/eric/comment/chech.html](http://meyerweb.com/eric/comment/chech.html)

<comment><USER12> Every time I see a "considered harmful" title, I groan and think of this. It's a meme at this point, and really detracts from the value of the article for me.

<comment><USER13> Is There An Alternative to "Considered Harmful" Essays?

Absolutely. The most basic alternative is not to write them at all, but to instead engage in reasoned debate without resorting to dogmatic assertions or distractive tactics (e.g., ad hominem attacks and straw man arguments). In those cases where some sort of document is needed outside of the debate, there are a number of superior alternatives.

* A description of the strong and weak aspects of one's own point of view; we might call it a "benefits and weaknesses of" essay. This is a positive contribution to the debate, and allows the debating parties to take the best parts of each view and more readily find a compromise solution. Knowing both the benefits and weaknesses of all views makes it easier to cover the weaknesses in one view with the strengths in another.

* A description of the strong and weak aspects of another point of view; we might call it a "perceived benefits and weaknesses of" essay. This allows the author to evaluate what he believes to be good and bad about another point of view. Authors must be careful to avoid slanting the piece too far toward the weaknesses, lest they end up writing a "considered harmful" essay by another name.

* An essay that compares different viewpoints in the same piece; in other words, a "compare and contrast" essay. These essays attempt to objectively evaluate multiple views and point out how they are both alike and dissimilar, thus highlighting both common ground and areas that need work. The benefits of such essays are fairly self-evident.

<comment><USER14> The purpose of the "Considered Harmful" headline was, and always has been, to draw attention. And it's frequently been successful, both in the original attempt and here as well.

<comment><USER15> My grief with this sort of "considered harmful" essay or blog post is that it is being applied to such concrete subjects as Swift code migration, not the almost philosophical objects as the original GOTO. "Considered harmful" essays should be timeless to do service to the concept.

</comment></comment></comment></comment></comment><comment><USER14> If Apple can't keep its own sample, example code up-to-date on its website, maybe they are breaking things a little too quickly.

At a minimum, they should make sure their migration tool works on their own examples, that seems like a basic regression test.

<comment><USER16> Apple has always been very bad about keeping its sample code up to do. They seem to only update it when they specifically get a radar about something being broken.

</comment></comment><comment><USER17> > Take a look at the Stack Overflow page again. There's some good information > there, but it's completely hidden by Swift code that's no longer relevant.

I recently experienced this first-hand with Python, chasing an issue with SSL certificates - my problem (SSL doesn't work on Python 3.6 on OSX unless you follow a post-install step to install certificates) was completely masked by problems some people experienced in a recent previous version of Python, where they had switched on certificate validation by default [0]. There were a number of similar-but-different SO questions, that all linked to each other. I wasted hours before I discovered that none of the results on Google for my exception were relevant.

It's hard with SO sometimes - information ends up being stale, and the accepted answer might no longer be the best. Sometimes you find a helpful comment or a new answer that has the right info, but other times it's just out of date or completely irrelevant. Worst, it leads you to mis-diagnose the problem, which is especially easy when it's something you're not familiar with: I know very little about SSL, I just want my API requests to work.

[0] Yes, I was astonished to discover that all this time certificates weren't being checked

</comment><comment><USER18> I had a bad time going from 2 to 3. The renamification was pretty smooth but took a few hours of work for a big project. However there were more subtle differences.

Example code:

        var rowID: Int! // Set elsewhere, keeping it short. Also would never declare anything in this way but legacy

        func someFunc() {
            let updateUrl = "things/\(rowID).json"
            print("updateUrl")
        }

The result in Swift 2:

        things/123.json

The result in Swift 3:

        things/Optional(123).json

A ton of subtle bugs not detected by the compiler. Apparently Swift 4 will throw a warning for parsing an optional in a string but this was pretty bad. However I trust the change between 3 and 4 will be less breaking and will bring true or almost ABI stability. Between the 1.x versions and the migration to 2 was already more difficult than the 2 to 3 migration if it wasn't for the renamification and I still consider that a great thing.

I would still happily start a project in Objective-C(++) if I would need to integrate a lot of libraries that rely on O-C, C or C++. But Swift is the default for me.

</comment><comment><USER19> After 3 years in Swift, the only clear drawback outside compile times, is exactly this.

It's a real shock coming from Objective-C. Ad hoc name-spacing by prefixing classes, and a language/core framework that's been stable for 30 years, made it extremely easy to Google and get an accurate answer immediately.

Moving to a language that adds major features twice a year, and invalidated large swaths of code by mass-renaming Cocoa in Swift 3, has made it much harder to find correct material

<comment><USER20> _core framework that 's been stable for 30 years_

That's perhaps a little overstated.

</comment></comment><comment><USER21> Are we at a point yet where people have realized that mutability is basically an optimization fraught with danger, and that immutability and functional data structures (coupled with some decent GC scheme) are the way to go for the most secure, bug-free code out of the gate?

Wake me up when we are, because "UnsafeMutableRawPointer" in _sample code_ makes me nauseous. Meantime, I'm gonna hang out here over in Elixir-land.

</comment><comment><USER22> Its always a tough decision, either you make no changes but then have to live with a less than ideal situation, or make changes but forces everyone to update their code.

Personally I think its ok to make incompatible changes once and then, as long as its not too many changes in one go (like python3), its preferable than later on ending up with inconsistent or overly complex languages.

</comment><comment><USER23> This seems like an issue with out of date examples.

This same criticism could be leveled against any language that evolves and invalidates past syntax.

PHP7 invalidates tons of old examples on the web. Does that mean those changes were bad or harmful? No. Just because we happen to be at a transition window with Swift such that recent examples are now invalid doesn't change that.

</comment><comment><USER24> I love Swift and I don't care if they break it everyday. I'll patch everything that needs to be patched while having fun building apps for all devices in the world, desktop, mobile, server, watch, tv, IoT, embedded, etc. Naysayers will naysay, just stay away and let us code.

Swift is a beautiful language and it gets better by the day.

</comment><comment><USER25> It's always a tradeoff. The io.js mess showed what happens when you try to be too stable.

</comment><comment><USER26> I don't understand... if those are the problems, write code in objc - it will be good for many years to come. Have some respect. You're looking at open source project, you can get involved yourself if you wish, you can follow design process - you have been given free access to "look into the future" in this area, the future that's being crystallised in front of your eyes - complaining from that position doesn't make sense.

</comment><comment><USER27> Hey, it's "continuous integration". It's moving fast and breaking things. Keep up or be roadkill.</comment>


Recovering root password under Linux with single user mode - <AUTHOR> http://galigio.org/2011/04/18/recovering-root-password-under-linux-with-single-user-mode/

<comment><USER2> More accurate title is "resetting root password ....". It does not explain how to recover the existing password (that would be quite a feat - it would mean inverting md5 ..)</comment>


Is Google removing copyrighted files from GMail? - <AUTHOR> http://lists.pirateweb.net/pipermail/pp.international.general/2012-February/010917.html <comment><USER2> I have at least three mp3's that were ripped like 8 years ago that I've sent to myself over the past couple years (2009 is most recent). They are all there and still good, and artists that I'd assume would be taken down if this was true.

You can check if you have any by searching, adding ".mp3" to required words and clicking check attachments (I also added from me to me)

</comment><comment><USER3> I call BS. There are just too many legit reasons of having copyrighted mp3's in your mail.

</comment><comment><USER4> No chance they did this, aside from the obvious implications and backlash they would suffer.... why would they remove files that aren't publicly indexed or shared and can't be found to be DMCA'd.

</comment><comment><USER5> I am pretty sure that Google Music allows you to upload any mp3 you like which makes me think that they would start there and not your email.

</comment><comment><USER6> Seems implausible. For one obvious example, any web store that sends you MP3s you've purchased via e-mail (I've used a few) would now no longer function because GMail would delete the MP3s before you could even download them to listen to them.

Difficult to confirm or disprove without a few examples (artist name, track name) that people can test with their own legit (copyrighted) MP3s.

</comment><comment><USER7> my mp3s i purchased from amazon, that i emailed myself are still there.</comment>


Ask HN: Why isn't highspeed rail a thing in America? - <AUTHOR> Was just considering how much of a difference it would make in the lives of people who ride the train regularly (especially in the northeast).  While being expensive and difficult, the benefits seem to fair outweight the cost. <comment><USER2> The Northeast is pretty crowded so if you're going to lay down tracks that are straight enough for high speeds you are going to displace somebody. Politically that is not easy to do.

</comment><comment><USER3> I've always assumed the economics didn't work out because the US is just so big. But I've never seen a detailed analysis.

<comment><USER4> Yeah, we've got a long list of reasons why we don't have high-speed rail. I think they're all wrong. China is just as big as the US, for example.

The next response will be something about population density. The response to that will be Spain, France, etc.

At this point (decades after we should have) I imagine it's extremely expensive to get the land for direct routes.

Our next plan is to build a hyperloop so we can taken the long way to go between major cities.

China will have close to 25,000 miles of rail in another decade. They're also increasing the speed. Should be a cost effective way to transport 1.4 billion people

</comment></comment><comment><USER5> Railroads aren't as good at lobbying as car companies and airlines who don't want the competition.</comment>


Why there was no PS4 design reveal - <AUTHOR> http://pixxel.co/feed/ps4-design

<comment><USER2> This has nothing do with cynical George Lucas-style profit maximization. It's a simple fact of technological progress. Since consoles are typically designed for a 5-10 year lifespan, the technology involved inevitably shrinks over that period and enables a smaller and more efficient package.

As a comparison, I don't think Sony originally sold us giant boomboxes just so they could "get us again" when they came out with the Walkman.

</comment><comment><USER3> Not sure I agree with the article. Would a company the size of Sony play a strategy like this? I suspect the real reason is that the design of the casing just hasn't been finalised yet. Nintendo did something similar with the Wii as I remember, but the other way round, announcing the the hardware look/feel first and the Wii remote and launch games at a later date.

<comment><AUTHOR> How many billions is the slimming down of PS worth to Sony.

I am a cynical bastard.

</comment></comment><comment><USER4> Sony's initial releases are larger than later slim versions for the same reason that computers used to take up entire rooms and now fit comfortably in your pocket. Given that it's not releasing till around the end of this year the design probably isn't finalised and they don't want to show it till it is.

</comment><comment><USER5> The original PS3 was a huge box, but it wasn't full of air. It was filled with cutting edge tech hitting thermal limits. It's hardly surprising that over a 7 year lifespan the system can be miniaturized.

</comment><comment><USER6> With the PS3 they removed PS2 hardware and a there was a die shrink, but naturally this wouldn't reduce physical size?</comment>


Is Tesla's new solar roof cool? Swedish Soltech has already been making it - <AUTHOR> http://www.soltechenergy.com/en/product/soltech-sigma <comment><USER2> This is roof top solar hot water, which has existed for at least 30 years, possibly a lot longer.</comment>


Ask HN: How to crash / hack Demo Day? - <AUTHOR>

SSE Labs Demo Day is tomorrow 6/2/11, tickets are $250, my co founder and myself are bootstrapping our start up and have no cash.  We really want to go and check it out.<p>Any ideas on how to crash / get in for free?  So far my plan is to borrow a friends SLR with a big flash and pretend to be the press.  Show up early and nose around?  Sneak in the back door?  Regardless I am going to give it my best shot to get in somehow, anyone have some ideas? <comment><USER2> Don't try to sneak in - if you really don't have the money, find the organizer and privately explain the situation, explain why you want to be there, and ask if there is anything you can volunteer for to help.

If you try to scam them you'll lose your reputation along with getting kicked out - if you approach it eagerly and ready to work to gain that experience you'll leave with a new contact and the experience.</comment>


UBSan ␇ Runtime - <AUTHOR> https://reviews.llvm.org/D77219 <comment><USER2> Off-topic: I get the same weird font display on this site as on microsoft's login page.

It seems like the font is specified as:

            font: 13px 'Segoe UI','Segoe UI Emoji','Segoe UI Symbol','Lato','Helvetica Neue',Helvetica,Arial,sans-serif;

and the first font I have avaiable seems to be Segoe UI Emoji and Segoe UI Symbol, which looks horrible: [https://i.imgur.com/KS19dRA.png](https://i.imgur.com/KS19dRA.png) Removing them both from the list gives the following result: [https://i.imgur.com/ReI0W4Z.png](https://i.imgur.com/ReI0W4Z.png)

I guess I have the emoji and symbol font installed for Segoe UI and not the main font.

<comment><USER2> Hmm, I fixed it by uncommenting the lines for matching Segoe UI Emoji and Segoe UI Symbol. /etc/fonts/conf.avail/75-joypixels.conf

</comment></comment><comment><USER3> Question to people with more knowledge in the matter:

 _This runtime will emit sound, most traditionally the terminal 's bell sound, when undefined behavior occurs._

I'm surprised this is possible. My understanding was that compilers don't consciously check for UB and then decide to make the dev's life hell if they find some. It's more that compilers pretend that certain assumptions are true even though this cannot actually be verified. If they happen to not be true (but the compiler still behaves as if they were), undefined behaviour occurs.

So if you _can_ explicitly check for code that causes UB, why permit it at all? Why not abort compilation or at least emit a warning?

<comment><USER4> >I'm surprised this is possible.

Yeah, I'm surprised that the terminal bell still exists in 2020.

>My understanding was that compilers don't consciously check for UB and then decide to make the dev's life hell if they find some.

That was the case during the 20th century. In the 20 years compilers have gotten far more aggressive. They do actively check for UB.

>It's more that compilers pretend that certain assumptions are true even though this cannot actually be verified.

What often happens is that UB gets detected and information that is clearly available in the source code gets erased in the compiler to follow the letter of the standard. There is a lot of UB code that can run without problems if the compiler didn't interfere.

>So if you can explicitly check for code that causes UB, why permit it at all? Why not abort compilation or at least emit a warning?

A lot of UB can only be detected at runtime. The most sensible interpretation of UB would be to simply skip these checks in production builds but keep them in debug builds so that developers can avoid UB in their code.

Example: Bitshifting can result in UB but if both operands are variables the UB can be detected at runtime.

<comment><USER5> > What often happens is that UB gets detected and information that is clearly > available in the source code gets erased in the compiler to follow the > letter of the standard.

I'm not sure how much I agree with this. I agree that compilers have gotten a lot better about deriving information from UB analysis in the past decade or two, but I think a lot of the time it _gains_ information from the additional analysis rather than ignoring existing information.

The main example I can think of for a compiler ignoring information from the source code is strict aliasing, where the compiler can ignore the fact that two addresses can be statically proven to point to the same memory location [0] (although to be fair that's from 2009; I'm not sure whether GCC still does this).

For stuff like null pointer dereferences, signed overflow, or OOB dereferences, though, the compiler can (sometimes?) derive stricter bounds, which means the compiler is gleaning more information from the source code than it has previously.

[0]: [https://www.mail-archive.com/linux- firstname.lastname@example.com/msg...](https://www.mail-archive.com/linux- email@example.com/msg01647.html)

</comment></comment></comment><comment><USER6> On the mac it opens a youtube video if you hit over 9000 undefined behaviors...</comment>


Show HN: I hate scheduling over email, so I made this: Timestamp - <AUTHOR> https://gettimestamp.com/

<comment><USER2> Looks very promising, but perhaps not complete? The links don't seem to generate for me. And I can't switch "reserve time" to "available time".

Is there nothing like this out there already? I could definitely see myself using something like this.

Nice work!

<comment><AUTHOR> What browser/OS are you using? I just checked on Chrome and FF on my Mac, and didn't run into any issues.

<comment><USER2> Win8 chrome Version 38.0.2125.44 beta-m

</comment></comment></comment><comment><USER3> Reminds me a bit of this hack, [http://rbtying.github.io/whencantimeet/](http://rbtying.github.io/whencantimeet/)

</comment><comment><USER4> Does it work with multiple accounts? I have a work vs. personal account, each with blocks of time on them when I'll be busy.

</comment><comment><USER5> also look at: [http://www.timebridge.com](http://www.timebridge.com)</comment>


GIMP 2.10.2 Released with HEIF Image Format Support - <AUTHOR> https://www.phoronix.com/scan.php?page=news_item&px=GIMP-2.10.2-Released <comment><USER2> > High Efficiency Image File Format being the standard designed to allow > storing twice as much information as JPEG at the same file size while better > image quality.

Sounds neat.

> HEIF is backed by the MPEG organization and, yes, involves patent licensing.

Right. So as a Internet-format, it's pretty much dead in the water then.

<comment><USER3> > High Efficiency Image File Format being the standard designed to allow > storing twice as much information as JPEG at the same file size while better > image quality.

I think that might be a controversial claim. For example, in this comparison:: [http://nokiatech.github.io/heif/comparison.html](http://nokiatech.github.io/heif/comparison.html) HEIF and JPEG seem almost equal. HEIF wins on blurry parts of the image because it introduces fewer artifacts. But JPEG wins in noisy parts of the image because the artifacts look like the original signal. The last image shows this well - the white floor texture is blurred to nothing sooner in the HEIF image.

<comment><USER4> In the last image, do the JPEG artifacts in the sky also look like the original signal?

[https://i.imgur.com/3jqTtVw.png](https://i.imgur.com/3jqTtVw.png)

<comment><USER3> No, because that's a blurry part of the image where HEIF is better.

</comment></comment></comment></comment><comment><USER5> [https://www.gimp.org/news/2018/05/20/gimp-2-10-2-released/](https://www.gimp.org/news/2018/05/20/gimp-2-10-2-released/) official announcement

[https://git.gnome.org/browse/gimp/plain/NEWS](https://git.gnome.org/browse/gimp/plain/NEWS) changelog

</comment><comment><USER6> Here's the original announcement so you can avoid phoronix:

[https://www.gimp.org/news/2018/05/20/gimp-2-10-2-released/](https://www.gimp.org/news/2018/05/20/gimp-2-10-2-released/)

<comment><USER7> Maybe I'm out of the loop: what's wrong with Phoronix?

<comment><USER8> Not much really. He churns out a lot of articles, some of them can be a bit clickbaity, and lacking in much information. He does sometimes post articles that are purely based on rumours. But I think he fills a good niche for technical but easy to read Linux/open source news.

In this case he hasn't really done much more than summarise the official release notes, so OP may as well have linked to those.

<comment><USER6> > In this case

In pretty much every case. It's rare that Michael actually contributes meaningfully to an article he posts. It's almost always just some copy/paste of the original source.

</comment></comment></comment></comment><comment><USER9> iOS introduced support for HEIF and gotta it's a pretty and i prefer it to the standard jpeg. Mind you, it's always a fear about interop and patenting but patents have never stopped the open source projects from supporting it some way or another (just ignore the patents seems to be an effective strategy for some)

</comment><comment><USER10> Any idea why a macoS version isn't available? Where would I get it?

</comment><comment><USER11> Last time I tried to use GIMP I wanted to do a simple affine transform on an image. I selected the transform tool and GIMP crashed. Apparently this is a known bug since 2016. Just checked, still broken. When people say GIMP sucks they really mean it.</comment>


Redux-dag-history – implements history as a directed-acyclic-graph - <AUTHOR> https://github.com/Microsoft/redux-dag-history <comment><AUTHOR> Featured on www.gitlogs.com today. Thought I'd share it.</comment>