S&P ending '08 around 900, thus... Summer of '97 Thread - <AUTHOR>

With the S&P set to close at mid-June 1997 levels, I thought it might be appropriate to reminisce about the summer that was, the summer of '97.
I was between 8th and 9th grade, at CTY (Carlisle first session, Lancaster second). CTY memories include: Don McLean's "American Pie"... Scum: the Masquerade (a card game)... Bleem, the integer between 3 and 4... trying to hook up with a 15-point-7 year-old "no more" (no success; I was only 14.1). Great times.
I was super-bummed about missing out on ARML, having not heard of the contest till national Mathcounts in May, and therefore having learned about the contest too late to register.
Outside of CTY sessions, I spent the summer hacking QBasic text adventures that no one but me wanted to play. :(
I won't post too many songs of the era, because I figure other posters will pick up the slack. Only three stick out as memorable:
Savage Garden - To the Moon and Back.
http://www.youtube.com/watch?v=9I9hVzqTbn0
This one I remember only because it was absolutely eerie at 4:00 on a summer morning. (I had to listen to the radio at night, else I couldn't fall asleep.)
Our Lady Peace - Superman's Dead http://www.youtube.com/watch?v=uOZLSHuDBxY
Great song from around that time from one of the most underrated '90s bands.
White Town - Your Woman http://www.youtube.com/watch?v=lVL-zZnD3VU
Quirky, odd song from an unusually talented, but unpopularizable, one-hit wonder. Vintage '97.
What are your Summer of '97 memories, songs, and (of course) hacking projects? <comment><USER2> 3rd Eye Blind's _Semi-Charmed Life_ was the song of the summer; and while this doesn't classify as a tech project, it was making Asprin (acetylsalicylic acid) with a friend for my 12th grade chem project.

</comment><comment><USER3> In mid-1997 I was about to enter grade 12, and getting my first experience with C -- writing code to compute the 5 trillionth bit of Pi (yes, I believe in jumping in at the deep end).

<comment><AUTHOR> Do you remember what it was?

If I recall correctly, computing hex digits of pi is fairly trivial, but decimal digits are not. Is that right?

<comment><USER3> The 5 trillionth bit of Pi is zero.

 _computing hex digits of pi is fairly trivial, but decimal digits are not_

For some definition of "fairly trivial", yes.

The Nth hexadecimal (or binary) digit of Pi can be computed in O(log N) space and O(N (log N)^2 log log N) time, while the best known algorithm for computing the Nth decimal digit requires O(N) space and O(N (log N)^2) time. This is due to Pi being expressible as a polylogarithm ladder in base 1/2 but not in base 1/10 (as far as we know).

</comment></comment></comment><comment><USER4> Hmm... in 1997 I was writing software for a living and cursing having to deal with Internet Explorer issues.</comment>


My experience of selling the same apps on iOS and on Android (with numbers) - <AUTHOR> http://speedanatomy.blogspot.com/2010/10/iphone-vs-android-app-sales-numbers.html

<comment><USER2> It's the "Sophie's Choice" for mobile developers: Give up your sense of freedom and openness for smaller exposure but 2x the revenue, or work on your own terms in front of a large and receptive base of customers who loves the sizzle but is "meh" when it comes time to pay for the steak.

Perhaps there will be a critical mass that forms when the geek legion legitimizes the cool factor of Android devices and the consumer comes in and starts snapping up apps in the same way it does on iOS, but, if you _have_ to make a choice between the two right now, which would it be?

Unfortunately, I have to go where the money is.

<comment><USER3> Given that his Android revenues are 50% of iOS, seems like supporting both is where the money is.

I'm surprised it's that high actually - not long ago people were throwing out figures like 10%.

<comment><USER4> Looking at it another way, most companies would sell one of their vice presidents to figure out a way to get 50% more business. This could be an easy route to increasing revenue.

<comment><USER5> That depends entirely on the cost of maintaining two very different codebases, keeping track of two different APIs....

<comment><USER4> It's probably less than the 50% bump in revenue, and likely cheaper than building it the first time since you can reuse tons of assets...(of course provided that it's 50% of something sufficient).

Let's be realistic about what we're talking about here, most phone apps are not multi-million dollar, multi-year AAA development efforts. They're typically made by a couple guys over a few months. That's why the typical app per-unit price is so low compared to the typical app-per unit price for desktop software. In the case of a "AAA" title, we're likely talking about something that's multi-platform anyway...code is generally cheap, art assets and design is expensive. A great example, Plants vs. Zombies for desktops is $20, for the iPhone it's what...$4? Yet it was completely worth it for PopCap to rebuild the entire game for the i-platforms (twice!)

In other words, if it's not worth doing it for a 50% revenue bump, it probably wasn't worth doing it the first time either.

</comment></comment></comment></comment></comment><comment><USER6> Summary: Android marketplace has more free downloads, fewer paying downloads, and requires more support.

Also, yuck:

"Another hypothesis is that I might still be disadvantaged by being Canadian. For example yesterday I received a support e-mail for someone who is usually able to purchase apps with his credit card but wasn't able to pay for my apps. The Google Checkout support site states: "The types of cards accepted through Google Checkout are based on the seller's location."

"I get a few e-mails per day about failed credit card transactions. It's possible that this happens with Apple also and that they simply hide it from us but it's worrisome nonetheless. All of this also amounts to an annoying level of e-mails and considerable amount of time spent answering support mail for stuck installations."

</comment><comment><USER7> Have any other Canadians had trouble selling apps on Android?

</comment><comment><USER8> I'm curious how Apple handles the HST for Canadian developers selling to multiple countries.

<comment><USER9> Pretty simply; the buyer's location is known, and Canadian sales tax rules are much simpler than US ones: the buyer's province is all that matters. They add the tax rate for that province (if any) and the Federal GST, or a blended HST if that exists for the province, or no tax if the buyer isn't in Canada.

It beats having to set a bunch of money aside and work it out yourself at year end.

<comment><USER8> Do they collect and remit the HST, or do they pass it on to you for remitting to the CRA?

Sorry, I'm not an iPhone developer, and I was always wondering how the accounting would be handled.

<comment><USER10> I'm fairly certain that since they are the 'retailer' they collect and remit the hst. What the store pays you isn't subject to hst.

<comment><USER8> What about the 30% commission?

I'm assuming they charge you HST on that which you can recover in your HST filings?

</comment></comment></comment></comment></comment><comment><USER11> I think this (Double your price! (and no, I'm not kidding) - <http://tinyurl.com/3xcounq>) is a must read for you, particularly concerning the MD versions of your app.

<comment><USER12> Direct link:[http://jacquesmattheij.com/Double+your+price+(and+no,+Im+not...](http://jacquesmattheij.com/Double+your+price+\(and+no,+Im+not+kidding\))

<comment><USER13> I get a 404 with your link, but the tinyurl above works.

<comment><USER14> I got a 404 as well. Somehow elcron missed an apostrophe in "I'm" in the address he posted. Interesting that the URL shortened version actually preserved the link integrity in this case.

Ironically, you can read an argument against shorteners on this same blog here-- <http://jacquesmattheij.com/Down+with+URL+shorteners>

Note: I avoid shortened links like the plague, just an interesting observation.</comment></comment></comment></comment>


Editor.js – Block Styled Editor - <AUTHOR> https://editorjs.io/ <comment><USER2> Here's my take on this from playing with it a bit:

\- Works on mobile (like Quill, Prosemirror)

\- Does not support collaborative editing (unlike Quill, Prosemirror)

\- Has somewhat unique block-based editing UI - think Notion (the data models of most editors support this, but the default UI of editorjs is much more explicit about this)

\- Not built on React (like Quill, Prosemirror, but unlike Slate and Draft)

The mobile support looks quite mature, and I think this could be a good competitor to Quill and Prosemirror for single-user editing.

Per my previous comments (1), I think for new projects, going with Prosemirror or Quill are still great choices. I've tried Draft and Slate and both of them have lacked good mobile support and collaborative editing.

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

<comment><USER3> The performance on mobile doesn't look great for me (significant delay between key stroke and rendering, on iPhone X), also this particular page could be more responsive and mobile friendly.

Otherwise I love the idea of block-based editor and clean output.

<comment><USER2> You're right. I expect that they're reconciling with their model in JS on every keystroke. I know Quill does an interesting thing where the DOM is the canonical model, and the JSON model is actually derived from the DOM by a strict transformation. Because of that, it works a bit more naturally with many native mobile editor interfaces.

</comment></comment></comment><comment><USER4> Nice, added to the list of editors: [https://gist.github.com/manigandham/65543a0bc2bf7006a487](https://gist.github.com/manigandham/65543a0bc2bf7006a487)

Perhaps they should've used the MobileDoc standard instead creating another one.

<comment><USER5> Nice! Could you please augment that list with links to the HN threads about the release of each? A list like that is the starting point but often the pros and cons are found in HN discussions.

<comment><USER4> You can search HN for any relevant discussions: [https://hn.algolia.com/](https://hn.algolia.com/)

</comment></comment></comment><comment><USER6> From a data management and flexibility standpoint, I see why block editors are becoming popular with some people. But as a user, it feels like a downgraded experience.

When writing multi-paragraph prose, the first draft isn't always the final draft. Quite often there's some shuffling around of parts of the content. With blocks, the user can't highlight part of one paragraph and into part of the next one because of the artificial container boundary.

Perhaps with some well planned keyboard shortcuts and other UI improvements, the friction can be reduced. Maybe also it will require a change in the way some of us think about content (although I still object to the user needing to think of content in terms of its subtypes and storage structures).

<comment><USER7> I agree for most of it.

I'm the current maintainer of [https://github.com/madebymany/sir-trevor- js](https://github.com/madebymany/sir-trevor-js) which we started in 2012. At the time we had a fully block based approach and migrated to more of a document based approach when medium.com gained traction.

Since then we've debated what's the best approach for cross block selection as now the expected behaviour is very much that of a text editor such as word rather than a block based editing tool which it started out as. A couple of years ago we embarked on a rewrite that saw us look for a solution to the problem that would solve this. Not just a block based selection, but a cursor based selection between blocks, but this never got to a level we were happy with.

I think with the evolution of online editing over the years and editors such as notion.so the approach they've taken with the multiple contenteditable elements is a good first step. Over time we'll see how far they are able to take it. Adding features such as cross browser support, undo / redo and keyboard navigation.

</comment></comment><comment><USER8> Hey! I maintain the Mailspring email client and I've thoroughly battle-tested SlateJS and DraftJS. I'd absolutely love if we could move to something with broader contenteditable support in the future (it's more or less impossible to allow people to paste AND EDIT arbitrary HTML in the former two.) A few questions if the author of the post is around!

\- Does EditorJS support nested blocks? Eg: can I make a list node that contains a list? Can I make a list that contains a blockquote? (DraftJS is a /linear/ set of block elements, making it very difficult to model complex documents - Slate's document model is a tree which is why pretty much why I chose it over DraftJS.)

\- Does EditorJS have test coverage? What's the overall testing story look like? I'm not a big TDD person, but we've had a few stability issues with Slate (granted a slightly out of date version) that cause the document state to become invalid after certain edits and then subsequent interactions throw errors. (It's absolutely terrifying to have your text editor crash!)

<comment><USER9> Hello! I'm a maintainer of Editor.js.

Regarding to your questions:

\- Editor.js doesn't support nested blocks. We keep structure flat and want Tools API to be as simple as possible for new developers. The target audience of the Editor.js is media and blogs, usually you don't need complex structure there. However, you can implement some complex plugins for your needs, nested lists as example.

\- We consider development of the editor very serious and understand importance of the test coverage. At the moment we don't have unit neither e2e tests but this is the one of our next steps on the way.

Thanks for your feedback!

</comment></comment><comment><USER10> Why JSON-that-resembles-HTML rather than whitelisted-subset-of-HTML? Seems to throw away a huge amount of tooling and force an extra step on anything that wants to render the content?

Although I guess I could render the JSON to HTML server-side and get the best of both worlds. Everything usually boils down to a question of caching something somewhere.

<comment><USER11> Every browser uses different markup to represent contents of contenteditable. One browser uses div for text and splits it into two when enter is pressed, other browser inserts <br/>, next one has paragraph, etc. ect.

JSON is not here for resemblance, but for normalization. You force single presentation of things from start, and when user presses enter (or other text composition event happens) you prevent default action, update document model (JSON) and then update the HTML.

This approach is much more sane and predictable than trying to trust browser's HTML.

<comment><USER12> Still, that does not mean it cannot output HTML. CKEditor 5 implements a custom data model, works in the way you described (cancel native actions or extracts stuff from it, apply those changes to its data model and re-renders the DOM if needed), but it still outputs HTML. Thanks to that you don't need a processor to use that content on your page. Plus, there are cases where converting a custom data model to HTML is actually a tricky job (e.g. inline formatting) and even Editor.js chose HTML for those.

<comment><USER13> JSON is quite nice compared to HTML, in my view. It's less verbose. Also, I like the flatness of Editor.js's data model.

Being JSON makes it easier to render into other formats, too.

</comment></comment></comment></comment><comment><USER14> Every time I see a new contenteditable-based editor I'm reminded of this

[https://medium.com/content-uneditable/contenteditable-the- go...](https://medium.com/content-uneditable/contenteditable-the-good-the-bad- and-the-ugly-261a38555e9c)

<comment><USER12> Hi! The author of this article here :) I hoped you liked it (cause your message can read both ways :D)

You reminded me that I was planning to refresh it a bit since it's over 3 years old now. I'd like to cover the rise of modern rich-text editors like CKEditor 5, ProseMirror, Draft.js and perhaps dive a bit into what we've learned when developing CKEditor 5 (because after 4 years of work it's actually out by now [1]). If you have any questions or you're curious about some particular aspects, please let me know :)

[1] [https://ckeditor.com/ckeditor-5/](https://ckeditor.com/ckeditor-5/)

<comment><USER14> I loved the article! I used to have to maintain some custom ckeditor plugins related to custom elements, spell checking and autocompletion at a job and that article resonated deeply with me on a personal level. I would love to read another article about the new editors :)

</comment></comment></comment><comment><USER15> Two long established predecessors to this: Sir Trevor JS[0] and Colonel Kurtz [1].

I've used Kurtz extensively and it's been brilliant. The only downside of all these block-based editors is that you can't easily create layouts where images float to the left or right of text. Well, you can create them but you don't get a WYSIWYG idea of what it looks like right in the editor. I can live with that!

I've explored all sorts of editors and Colonel Kurtz is the one that's worked best: Trix, Draft, TinyMCE, CKEditor, ContentEditable, ProseMirror - just off the top of my head.

[0] [https://madebymany.github.io/sir-trevor- js/](https://madebymany.github.io/sir-trevor-js/)

[1] [https://github.com/vigetlabs/colonel- kurtz](https://github.com/vigetlabs/colonel-kurtz)

<comment><USER16> Maintainer of Colonel Kurtz here! It's super awesome to see positive feedback. Thank you!

CK is our workhorse for tons of sites, and we've struggled to come up with a good general pattern for editing horizontal layouts. We'd happily take suggestions, however. I'll admit it's one of the more awkward things with the editor.

<comment><USER17> I'm not familiar with your editor or block-based editors in general, but it looks like a basic version of a visual editor I used in WordPress a while back. Is there some reason you can't do it similarly to how that did it, by allowing a row to be split into columns, each of which can have a content element within it and can have it's width adjusted manually or set to fit to its content?

If you used flex instead of floats it seems like you could have most of the functionality without the edge cases of floated elements.

</comment></comment></comment><comment><USER18> We were draftjs, but it got very slow on larger texts. We're replacing with slate but it lacks some very needed textnode manipulation. Glancing at the editor and api, wow. Can't wait to have something simple (content editable) but with strong api backbone. Congrats!!!

<comment><USER12> Did you try CKEditor 5? It's a modern rich-text editing framework with a rich API. However, it also comes with a lot of polished and ready-to-use features. You can read more on: [https://ckeditor.com/ckeditor-5/](https://ckeditor.com/ckeditor-5/).

<comment><USER19> Since you mentioned CKEditor 5, I'll be bold enough to go a bit into off- topic.

CKEditor 5 is an incredibly impressive endeavour, and I've been following it with great interest. However, one of the things that separates it from the competition is the GPL license, which makes it impossible to use the editor in a permissively-licensed (Apache2/MIT) open source project. Your founder has indicated a readiness[1] to grant a custom license to such projects.

So, I'm wondering whether that is still the policy, and how that's been working out in practice. Have any projects taken you up on the offer? Have there been any unforeseen problems? What are the legal limitations imposed (on distributors/forks of the project, for example)?

[1][https://github.com/ckeditor/ckeditor5/issues/991#issuecommen...](https://github.com/ckeditor/ckeditor5/issues/991#issuecomment-384995497)

<comment><USER12> Thanks for such positive feedback :)

Yes, the "Free for Open Source" initiative is up and running. For now, we didn't promote it a lot because we wanted to learn how it works, but from what I know, the custom license that we proposed is already used by a couple of projects.

Based on the feedback that we got so far, we're right now working on a simplified version of this license. Its initial version still had some restrictions which didn't work for Apache2/MIT projects with a commercial branch. Plus, it was simply too long for normal people :). We're removing these limitations. Once it will be polished, we will talk about it more officially on ckeditor.com.

<comment><USER19> That's great to hear. Keep up the good work!

</comment></comment></comment></comment></comment><comment><USER20> Couple of questions,

\- Are there any plugins to transform the saved output into HTML or other content (markdown)? Or does the user have to implement these?

\- Whats the difference between this and the CodeX editor referenced in many places?

Edit: PS: The docs link to [https://editorjs.io/usage](https://editorjs.io/usage) but that url seems to be broken.

<comment><USER21> Hi from CodeX.

Currently we does not have ready to use implementation for converting JSON into HTML after saving. It is a trivial and specific task, that depends on plugins you use.

CodeX Editor is the previous "working" name of early version of Editor.js. We have decide to change name on beta-testing stage.

</comment></comment><comment><USER22> I've been following this space for some time [1], and for me the constant struggle has been finding something that is both batteries-included, so I don't have to build a usable editor from primitives on projects where the core differentiator is not related to how content gets authored, and mobile- friendly, so that I don't have weird capslock bugs on iOS [2], completely broken Android support [3], and just general mobile weirdness [4].

To the best of my knowledge, Prosemirror has been most willing to prioritize mobile support, and currently has the best mobile browser coverage of the three most commonly mentioned modern contentEditable options (prosemirror, draft-js, quill). Unfortunately, building an editor with Prosemirror is a very hands-on process that requires you to make all the UI decisions and most of the UX decisions yourself, which isn't a great fit for most projects that don't need to innovate in the actual _content creation_ side of things.

I would LOVE it if a batteries-included editor like this, which clearly had a lot of thought put into the UX and UI aspects, was built on the very-robust technical foundation of Prosemirror (or similar). There are a few efforts at this on GitHub, but nothing so far with more than one or two contributors that I've found. The backend of editor.js looks solid, but without any discussion of mobile IME support, and without the backing of big players like NYT [5], realistically I can only guess that mobile support for editor.js will end up similar to the well-intentioned but partially complete mobile support found in other smaller projects like quill, slate, etc.

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

[2] [https://github.com/codemirror/CodeMirror/issues/3403](https://github.com/codemirror/CodeMirror/issues/3403)

[3] [http://engineering.mindlinksoft.com/why-draftjs-doesnt- work-...](http://engineering.mindlinksoft.com/why-draftjs-doesnt-work-on- android/)

[4] [https://github.com/ianstormtaylor/slate/issues/2062](https://github.com/ianstormtaylor/slate/issues/2062)

[5] [https://open.nytimes.com/building-a-text-editor-for-a- digita...](https://open.nytimes.com/building-a-text-editor-for-a-digital- first-newsroom-f1cb8367fc21)

<comment><USER12> We've been doing quite a lot of research around mobile support in the early phase of working on CKEditor 5. We knew from our past experience that on mobile devices (especially smaller ones) you need a dedicated UI, rather than a responsive version of the same UI that you use on the desktop. When the software keyboard is visible (+ when you have autocompletion bar above the keyboard) there's really not much space for your UI and the text that you want to edit. It means that you need really good control over what's happening on the screen in order to be able to implement a reliable UI.

Anyway, we had big plans for mobile support in CKEditor 5. Then we started doing more research [1] and it turned out there are critical issues with how WebKit works. You can guess, you can try, but with a tone of hacks you still won't be able to guarantee a smooth UI and great UX.

Right now, we're in a state where:

* after spending several months on it, text editing is well supported on iOS and Android (including spellcheck and stuff) – we don't get any bug reports recently about that part,

* the default UI is not working great on smaller devices.

The sad part is – we don't have any bigger plans to address the latter. We have some smaller ideas for making the current UI more responsive, but there will still be fundamental issues that you will face when using it:

* The conflict between the native UI (the balloons/panels with paste/copy/cut/bold/italic) and the custom editor UI. I've been bringing that to the W3C's attention since 2015 and nothing happened since then (most recent topics: [2], [3]). Right now, I don't have the funds anymore to lobby for this (neither have anyone else, apparently), so those topics seem to be completely stale.

* Inability to display your UI and implement functions like scrolling to the caret in a reliable way on WebKit due to its broken viewport mechanics [4]. I even talked about this with one of the Apple devs responsible for the current behavior and he agreed that there may be a problem (a good first step :D), but I got literally zero feedback after the last year's TPAC in Lyon when I presented this issue. * And more...

IMO, it's due to those issues that we haven't seen a single editor (implementing more than some really basic functions) with a good and stable UX on both iOS and Android. Every solution I saw was flawed in one way or another. I'm not saying that it's completely impossible to build such a solution, but rather that, taken all the obstacles and moderate demand (desktop is still the main platform for rich-text editing), the ROI seems too low for anyone to invest enough in it.

Anyway, feel free to contact me (e.g. via [https://twitter.com/reinmarpl](https://twitter.com/reinmarpl)) if you'd like to discuss this more.

[1] [https://github.com/ckeditor/ckeditor5-design/issues/149](https://github.com/ckeditor/ckeditor5-design/issues/149)

[2] [https://github.com/w3c/editing/issues/176](https://github.com/w3c/editing/issues/176)

[3] [https://github.com/w3c/editing/issues/182](https://github.com/w3c/editing/issues/182) (my presentation from last year's TPAC)

[4] [https://gist.github.com/Reinmar/91c70d2882523f47da7c49805042...](https://gist.github.com/Reinmar/91c70d2882523f47da7c498050421204)

<comment><USER22> This is really nice context to have. I would generally agree with you that, in the current mobile IME landscape, it's hard-to-maybe-impossible to get close to the text editing UX of a native app with the web platform.

I guess my point of frustration is to watch project after project toss itself at the task of implementing a nice Medium-ish desktop UI, announce a new "standard" for JSON-based rich document serialization, get mobile support about 80% of the way there, and then just... leave it like that.

I don't have enough data to make a firm statement, but I would bet with confidence that that if you include native mobile apps in the calculation (iOS Notes app, Google Keep, Wordpress Mobile), mobile rich text editing is either more prevalent than desktop, or on a strong upward trend that will overtake desktop text editing in the next two years. The popularity of hybrid devices like the iPad pro, where you have a desktop-class processor and screen size but an iOS IME is only going to boost those numbers.

</comment></comment></comment><comment><USER23> Wagtail, a CMS system for Django uses a very similar abstraction to this for their StreamField[1] type and I've found it incredibly useful. It allows frontend services and backend services to easily implement custom types, and treats streams of content as a list of 'blocks'.

[1]: [https://docs.wagtail.io/en/v2.4/topics/streamfield.html](https://docs.wagtail.io/en/v2.4/topics/streamfield.html)

</comment><comment> martin-adams I seem to be deep in this type of problem on a project. I see they opted to use multiple content editable sections. This means that using the up arrow keys, when going between the sections the cursor jumps to the start of the block, then the last line of the preceding block. It's an interesting trade of than to use one large contenteditable section.

</comment><comment><USER24> Curious how this stacks up against draft js?

<comment><USER25> Or slatejs. As I understand both have (or used to have) some serious problems with Android mobile. I don't see an explicit claim of Android/mobile support here either, which to me would be the killer feature.

<comment><USER26> They're hard at work on Android support on SlateJS.

[https://github.com/ianstormtaylor/slate/issues/2062](https://github.com/ianstormtaylor/slate/issues/2062)

<comment><USER27> We just upgraded our Slate version, and the relatively new Android support is _sort of_ working, but still with a lot of bizarre and janky behavior.

<comment><USER28> I implemented Android support on Slate. It is currently the first release and I will be committing time to fixing the remaining bugs starting within this month most likely.

<comment><USER27> Thanks for what must have been a ridiculous amount of effort! It is already good enough that we re-enabled edit mode on Android.

</comment></comment></comment></comment></comment></comment><comment><USER29> People interested in block styled editors and new takes on editors should look at hax-the-web, a big effort using web components primarily designed for educational materials at PSU, but usable for so much more. It's quite amazing the flexibility that is possible - here's one recent video, there are many many more on his channel [https://t.co/eXM6yBQA7h](https://t.co/eXM6yBQA7h)

</comment><comment><USER30> This is really nice. Now HTML is not a concern anymore. Really fit the mental model of React.

Will try this in my current project. Thanks you very much.

<comment><USER31> Make sure you try it in any browsers you want to support, especially mobile. That's where the dragons are.

It also sucks to be in a position to say "lol sorry" to a user for being unable to do something in a major mobile browser when you could've gone with something more solid like ckeditor.

<comment><USER30> As i see, this editor only returns the blocks for you. How to render is upon you instead ? Or i miss something important here ?

<comment><USER31> Implementing render(blocks) -> html is trivial.

The hard part I'm referring to is making the WYSIWYG editor. Contenteditable takes things a step further by having you (editor + plugin implementors) intercept every native event and then reimplement that logic yourself, especially between click, hover, and touch (mobile) and browser differences between the events.

Since you said you were going to try it in your current project, I just wanted to warn you. I learned this the hard way when using Facebook's Draft.js on a simple chat box input. We moved to either ckeditor or tinymce iirc because support was more polished all around.

</comment></comment></comment></comment><comment><USER32> That pop-up when I click the 3 dots is way too slow, it's really annoying. Those buttons should probably be visible on hover.

Or better still, just show them on the side maybe. It takes too many clicks to get work done. (IMHO)

<comment><USER21> Heard you, thanks. Will work on this.

</comment></comment><comment><USER33> I've been struggling with ProseMirror for the last 2-3 months. This looks amazing and I'm looking forward to replacing Prosemirror with it.

<comment><USER34> Out of curiosity, what were the most irritating problems you faced there, that in the end you decided to start looking for a replacement?

</comment></comment><comment><USER35> this is very well done!

too bad browser selection api will cause LOT of bugs of this kind [https://streamable.com/0gc8j](https://streamable.com/0gc8j)

<comment><USER21> Capture this. PRs is already on review.

Thanks.

</comment></comment><comment><USER36> Sadly, when I see libraries in other languages I think "oh, nice! Well done!", but when I see JavaScript stuff I cringe, "oh no, are they reinventing the wheel again?" as my first reaction.

</comment><comment><USER37> Has the backend crashed? The screen just keeps loading

</comment><comment><USER38> Great! Now put this in a CMS that allows for custom React elements so we can get rid of Wordpress/Gutenberg.

</comment><comment><USER39> What about bold, italic, etc?

<comment><USER40> Either press the word combinations, ctrl+b etc, or select the text you want bold and there will be a popup.

You`re limited on the selection though, thats kinda a bummer. In my opinion making a selection and allowing a few operations, like bold, delete, is worth it.

</comment></comment><comment><USER41> Great effort, thanks!</comment>


Applying programming language research ideas to transform spreadsheets - <AUTHOR> https://www.microsoft.com/en-us/research/blog/influencing-mainstream-software-applying-programming-language-research-ideas-to-transform-spreadsheets/?OCID=msr_blog_PLspreadsheets_popl_tw <comment><USER2> And they are using emacs ;)</comment>


Ask HN: Best Throwaway Laptop for Travelling? - <AUTHOR> Thinking of going travelling for 5+ months later this year. Backpacking around the world — but still want the ability to work on (mainly web-dev) projects.
Anyone have experience with a good machine to do this with?
Requirements:
* OS and specs capable of running Atom Editor & Chrome for React.js development
* Good battery life
* Portability, portability, portability (thin, lightweight)
* HiDPI screen
* Cheap enough to order a replacement without feeling sorry for myself (< $500)
* BONUS — SIM/Networking? <comment><USER2> Seconded on the Chromebook. Another option is a secondhand netbook, like an Acer Aspire One - very small and easy to throw into a bag, very cheap since they never really caught on and vry good battery life. You might have to relax your HiDPI requirement for a cheap machine though - you're not going to get a fantastic screen AND a low price.

</comment><comment><USER3> I'd look at Chromebooks. No suggestions for specific models, sorry.</comment>


Hosting a Hugo Site in a Google Bucket - <AUTHOR> http://stephenmann.io/post/hosting-a-hugo-site-in-a-google-bucket/ <comment><AUTHOR> This is my fourth post in a 30 day blog post marathon. It describes how to deploy a simple Hugo static site into Google cloud. Let me know what you think!</comment>


Mochizuki Workshop at Oxford - <AUTHOR> http://www.math.columbia.edu/~woit/wordpress/?p=8160 <comment><USER2> Also, the blog post buries the lede somewhat. I found that this was the most important bit:

        Update: Turns out the "unexpectedly positive" was a reaction to day 3,
        which covered pre-IUT material. Today, when things turned to the IUT stuff,
        it did not go well at all. See the link in the comments from lieven le bruyn
        to a report from Felipe Voloch. Unfortunately it now looks quite possible
        that the end result of this workshop will be a consensus that the IUT part
        of this story is just hopelessly impenetrable.

So while there was an early sense of optimism that the gathered mathematicians would be able to find some way through the papers at the beginning of the week, it seems that optimism has soured as the week progressed.

</comment><comment><USER3> Science is about publishing results that others can reproduce and check. Failing to make a theory accessible to the world experts (!) in the field is about as useful as not having the theory at all. Despite what some introvert mathematicians may think, science necessarily involves other humans.

If I were one of the experts I would give it that one week and if nothing interesting comes up stop wasting my time on it.

<comment><USER4> The situation is more complex though. Most people seem to not have gotten anything out of this workshop:

[https://plus.google.com/106680226131440966362/posts](https://plus.google.com/106680226131440966362/posts)

But Mochizuki was answering questions. And its not like there is absolutely no progress. Quoting from the day 5 summary:

> I felt that Dupuy was the one that made the most progress learning the > stuff. He told me afterwards that he indeed made progress but is nowhere > done yet. He also told me he would take Mochizuki up on his offer and > continue to work on understanding the work.

</comment></comment><comment><USER5> The link to the paper mentioned in the post is broken. Here's the actual link: [http://people.maths.ox.ac.uk/kimm/papers/pre- iutt.pdf](http://people.maths.ox.ac.uk/kimm/papers/pre-iutt.pdf)

<comment><USER6> The link is correct. See [http://mathoverflow.net/questions/195841/what-is- an-%C3%A9ta...](http://mathoverflow.net/questions/195841/what-is- an-%C3%A9tale-theta-function?lq=1) The actual content of Minhyong Kim's report, which is offline for now, is also available here: [https://twitter.com/math_jin/status/675827194489278464](https://twitter.com/math_jin/status/675827194489278464)</comment></comment>


Ask HN: Looking for a Static wiki generator - <AUTHOR> I am looking for a simple static wiki (not blog) generator.  All I really need is the static generation of markdown files to be presented in a parent child fashion.  Does anything like this exist?<p>The reason being the host system is not powerful enough to run a wiki engine like dokuwiki <comment><USER2> It seems that the terminology is causing some confusion. The definition of a wiki is "a website which allows its users to add, modify, or delete its content via a web browser" [1], which is pretty much the opposite of "static." I assume that what you want is a static site generator that has organisational features that are common in wiki software...

My favourite wiki software is Gitit [2]. It uses Pandoc [3] to convert from an input format (such as Markdown) to HTML. Perhaps you could write a simple script that iterates through all source files and renders the HTML to a destination directory using Pandoc, creating any subdirectories as required. That minimal solution should be very easy to implement; adding organisational markup within the HTML would require some programming.

[1] <http://en.wikipedia.org/wiki/Wiki>

[2] <http://gitit.net/>

[3] <http://johnmacfarlane.net/pandoc/>

</comment><comment><USER3> I'm sure people will chime in with more information here, but you might be interested in previous discussions of this and similar questions:

<http://news.ycombinator.com/item?id=4860457>

<http://news.ycombinator.com/item?id=4858436>

<http://news.ycombinator.com/item?id=4857473>

<comment><AUTHOR> I have searched before and didn't really come up with much that is a wiki. Everything is a blog

<comment><USER3> I produced my own statically generated wiki that uses forms, email, and a cron job to receive changes, regenerate the site, then upload the changed pages. It's crude, old, non-standard, and definitely not what you want. When I made it some 13 years ago there were no alternatives. Still runs, mind you.

So it's possible, and I'm sure someone has done it, but I have no suggestions. Sorry.

 _Added in edit ..._

Have you had a look at this: <http://code.google.com/p/statwiki/> ??

Or this: <http://ikiwiki.info/> ??

Or this: <https://github.com/arthurk/pyll#readme> ??

This also has a lot of information:

[http://iwantmyname.com/blog/2011/02/list-static-website- gene...](http://iwantmyname.com/blog/2011/02/list-static-website- generators.html)

</comment></comment></comment><comment><USER3> So if it's a wiki, how do you intend to make a change, given that it's static? I'd be interested to see how your solution to that design issue compares with the solution I came up with over a decade ago.

<comment><AUTHOR> Through the markdown (or whatever else) files on the system via the shell.

<comment><USER3> I don't understand. It's a wiki. You have a collection of plain text files with markdown or something. There's a web server. The webserver expects html.

How does the text get converted to html? What provokes the process? Do you just initiate it by hand having changed the plain text files? If so, what's the difference between a wiki and a static web site?

I don't understand what you're trying to achieve, and why you're calling it a wiki.

<comment><USER4> I don't quite get it either.

Could you use something like Org mode in Emacs? Org mode has a sort of personal wiki feel. Everything is stored as text and you can export your files as HTML.

<comment><AUTHOR> No can't use that.</comment></comment></comment></comment></comment>


Should I accept a CTO position with expert-level programming experience? - <AUTHOR> I'm a expert developer with a lot of experience in the industry working with great companies. Recently a startup-like (young, I'm young too, I'm about twenty-one) company offered me a CTO position. What should I do? <comment><USER2> An expert at twenty-one, eh?

Hard to say without more detail. Is there any reason you shouldn't? Would a failure there hurt your career?

If you do decide to take it, make sure to read the classics on the people aspect of software from MMM, to Peopleware, to Dale Carnegie, or whatever the modern equivalents are.

<comment><AUTHOR> Thanks for your advice. what did you mean by MMM?

</comment></comment><comment><USER3> Beginner: zero to two years of experience Intermediate: two to five years of experience Expert: at least 5 years of experience, but more likely 8 to 12.

Domain expertise: 10 years of experience.

How do you get to call yourself an expert if you're 21?

<comment><AUTHOR> I've worked since fourteen. I know it's odd and rare but it's possible :) they offer me such positions often because of top companies in my country that I worked with.</comment></comment>


Photo-Sketching: Inferring Contour Drawings from Images - <AUTHOR> https://arxiv.org/abs/1901.00542 <comment><USER2> Check out the pdf, pretty impressive results:

[https://www.ri.cmu.edu/wp-content/uploads/2019/01/Li- Mengtia...](https://www.ri.cmu.edu/wp-content/uploads/2019/01/Li-Mengtian- WACV-2019-Photo-Sketching.pdf)

BTW, if the authors find these comments, they should definitely advertise the new game they create to collect more data (once it's released) to art-centered communities, particularly comics. Many people who do line art practice tracing frequently to improve their technique.

</comment><comment><USER3> Hmmm. The examples are underwhelming compared to commercial examples of these types of filters.

iOS 12 added filters which are only available in Messages or the Clips app (not the camera app) that produce amazing results in realtime. Try the "ink" version. [https://www.cultofmac.com/583400/how-to-use-ios-12-comic- boo...](https://www.cultofmac.com/583400/how-to-use-ios-12-comic-book-photo- filter/)

For even more extreme versions, there are tons of filters, plugins etc for Photoshop and other paint programs. Here's one from 2013: [http://www.tipsquirrel.com/the-graphic-novel-filter- photosho...](http://www.tipsquirrel.com/the-graphic-novel-filter-photoshop- elements-diamond-in-the-rough/)

Maybe I'm missing something, but why is it that academics manage to publish stuff like this that is so far from the state of the art in the commercial world?

<comment><USER2> > Maybe I'm missing something

This may be the case. The filters you cited are not countour filters. Having the option of pixel matching entire regions by color makes any image look better, regardless of how many or how few contours you match.

</comment></comment><comment><USER4> It's 2019. Can we please stop using the Lenna Playboy centerfold picture in every other graphics paper?

Perhaps in the 70s there was actually a shortage of useful reference images and it had some value -- I wouldn't know -- but at this point it's just creepy.

<comment><USER5> Agreed, it's 2019 I too would rather have the computer vision community use a different image instead Lenna, perhaps the proposed Fabio Lanzoni[1] or the Kodak image suite[2].

[1] [https://www.cmc.edu/news/every-picture-tells-a- story](https://www.cmc.edu/news/every-picture-tells-a-story)

[2] [http://r0k.us/graphics/kodak/](http://r0k.us/graphics/kodak/)

<comment><USER6> I like the idea of changing it, but neither of those options seem good. Fabio is just a response to Lenna - it seems like we can do better. And those Kodak images are really surprisingly bad. Consistently drab colors, blown highlights, and really badly composed pictures of dated subjects. Is there something I'm missing that makes those images important?

<comment><USER7> Fabio is fine, and he is proof that there's nothing wrong with Lenna either. Papers with algorithms relevant to photographs of humans should probably include both images, as well as a few more to include some racial diversity.

Images of humans are important to humans. If dogs were scientists, they'd probably devote lots of study to the scents of other dogs.

<comment><USER4> The image may be fine if we strip it of the context, but the world doesn't work like that. The image is famously known to be cut out from a larger nude photo, which was chosen for its sexual appeal, and published in a magazine of sexual content. That is not an appropriate choice for most academic publications.

If you want to use it to demo your nudity detection algorithm, feel free.

<comment><USER7> A noted judicial maxim, "I know it when I see it", has been criticized as trivial. Here you prove that not to be the case. You have a serious disagreement with the maxim, in that the purely visual properties of this image are not what make it objectionable to you. Instead you dislike the history of the image. But its nearly five decades of use in this field are the historical reason it is used today. You're advocating for your historical judgment over the different historical judgment of scholars in the field.

That _could_ be reasonable. For instance, the fact that statues commemorating the Confederacy have _some_ historical relevance doesn't make up for the fact that they mostly celebrate the awful institution of slavery and a society that was built upon that. We therefore disregard the "historians" who advocate for their continued intrusion into our public spaces.

However, those statues are quite explicit in their celebration of that odious time. This image is simply a beautiful image of a beautiful human. And its history is far from odious. Even the larger image is hardly prurient: secondary sexual characteristics are viewed obliquely. Most women have no problem with that. (Instead they object to the continued vilification of breasts in the form of breastfeeding bans etc., which vilification you continue here.) Lenna herself certainly has no problem with the image: she has publicly stated she values her appearance in the best-selling Playboy of all time, and its subsequent second life in academia. There is nothing wrong with an image of an unclothed human body, and this image is tamer than many such images.

Few women appreciate your advocacy here. Unlike you they don't assume that everyone is either a Puritan or a junior high schoolboy. I can think of few things less interesting or important than a "nudity detection algorithm".

</comment></comment></comment></comment></comment></comment><comment><USER8> Quality doesn't seem much better than the comparison algorithms in the paper.

<comment><USER2> Which images are you looking at? The ones I've seen appear dramatically different and better to me(but I'm also a hobbyist artist and sketcher).

<comment><USER8> E.g. on page 7 of the paper where the head is cut off in the "ours" picture and less so in the "HED" picture, or the helicopter is similar or worse in quality to the "gPb" picture.

<comment><USER2> Sure, it's not 100%. They included those images to illustrate some challenges that they ran into (negative space and low value boundaries, not surprising given their relatively small data set).

But the ones that they open with are dramatically better than HED.

<comment><USER8> Hmm, I'm getting downvoted, but even the opening ones look arguable to me, e.g. in the hotel room on the first page the lamp shade and cushion near the sofa don't look great. Some of the HED artifacts could be improved with some post processing I imagine (as they do later). The dogs are significantly better on page 6. Looks to me like there are some things they are doing better, but still a way to go. Difficult to tell with the small number of sample images.

<comment><USER2> I didn't downvote, but I still see a significant difference between HED and the author's algorithm.

But you're correct, it is difficult to make a confident judgment given the small number of sample images.</comment></comment></comment></comment></comment></comment>


Apple, Google, and Microsoft Working on Covid Exposure Notification System - <AUTHOR> https://www.aphlblog.org/bringing-covid-19-exposure-notification-to-the-public-health-community/ <comment><USER2> Well, that's promising. The US has had such a disappointing response in nearly all respects.</comment>


Is it bad to compete with small businesses? - <AUTHOR>

<comment><USER2> Don't be ridiculous. Provide value to people. That's your job as an entrepreneur (hell, as a human being...it's what sets us apart from all other animals). If that value is better than existing businesses, great, you just made the world a richer place for everyone! However, I suspect you won't find that you can just walk into an existing market and eat the existing companies lunch.

You'll be shocked at how big some "small businesses" are, and how effectively they can compete with your new-fangled web-based concept (or whatever). Most won't even notice you exist while you bang your head into the market for three years or so--if you're still in business at that point and have actually acquired a large customer base before hitting the end of your runway, then they'll notice you exist. They'll have plenty of time to respond, either getting smart, or getting out.

Ideas are funny that way...you hit the market with a great, revolutionary idea, and one of the bigger established players spots it two years later and eats your lunch with it. (First isn't a guarantee of winning, or even a good indicator of it.)

</comment><comment><USER3> Look at it from the customer's point of view instead. Is it bad for businesses not to offer competing products and services to you?

Remember you can't put another business out of action, only customers can do that. If you provide a better product or service customers will switch to you. It's democracy in the market place.

</comment><comment><USER4> It is good to provide customer value. If you can provide a service better and cheaper than the competition, go for it.

</comment><comment><AUTHOR> What if your idea will consolidate a fragmented industry and provide stiff competition to 'mom-n-pops'? Is it better if the small businesses tend to not serve the customer well?

</comment><comment><USER5> As someone who runs a small business as my "day job", I'd say it most certainly isn't bad to compete with small businesses. :)</comment>


List of the best trending websites in January 2018 - <AUTHOR> http://www.rockingpage.com <comment><USER2> Sockpuppet accounts and/or promotional comments will get you banned here, so please don't.

HN users usually see through it, making it against your interests anyhow.

</comment><comment><USER3> Awesome tool guys. I think there's a need for a short term trending sites tool..

</comment><comment><USER4> Nice work guys. Selecting by country would be great.

</comment><comment><USER5> Cool stuff</comment>


Tapetail, Bignose and Whalefish turn out to be the same fish - <AUTHOR> http://www.aquaticcommunity.com/news/lib/195 <comment><USER2> Working link to paper, [http://rsbl.royalsocietypublishing.org/content/5/2/235](http://rsbl.royalsocietypublishing.org/content/5/2/235)

</comment><comment><USER3> Maybe this is a dumb question...but didn't they ever do gene/dna testing on these fish before? No one realized they were the same species?

<comment><USER4> DNA sequencing technology became a lot more widespread and inexpensive in the past decade (around the time that this article was published).

[https://en.wikipedia.org/wiki/DNA_sequencing#Development_ini...](https://en.wikipedia.org/wiki/DNA_sequencing#Development_initiatives)

</comment></comment><comment><USER5> Should have [2009] in the title.

<comment><AUTHOR> This hasn't been discussed on HN before. [0] If you have any more recent updates on this topic we'd love to see them.

[0] [https://hn.algolia.com/?query=tapetail&prefix=false&sort=byP...](https://hn.algolia.com/?query=tapetail&prefix=false&sort=byPopularity&page=0&dateRange=all&type=story)

<comment><USER5> The convention is to add the year of publication to a title if the content is not current. It has nothing to do with whether it's been discussed before or not.

</comment></comment></comment><comment><USER6> I'm fascinated by the ways in which the same DNA can cause widely different physical expressions, in response to sex, developmental stage, or even environmental conditions (e.g. [https://en.m.wikipedia.org/wiki/Locust](https://en.m.wikipedia.org/wiki/Locust)).

<comment><USER7> If you think that's interesting, you should look into sessile animals [https://en.wikipedia.org/wiki/Sessility_(motility)](https://en.wikipedia.org/wiki/Sessility_\(motility\))

</comment></comment><comment><USER8> Why hasn't anybody captured pregnant Whalefish and raised the offspring?

Then, it would've become apparent - long before DNA methods were known. :D

<comment><USER8> Anyway, thanks for the news. :)</comment></comment>


RocksDB – A persistent key-value store for fast storage environments - <AUTHOR> http://rocksdb.org/ <comment><USER3> Very nice work, and the wiki is also quite nice -- I wish more projects had a page like [https://github.com/facebook/rocksdb/wiki/Rocksdb- Architectur...](https://github.com/facebook/rocksdb/wiki/Rocksdb-Architecture- Guide). It's really nice to see a clear, terse summary of what makes this project interesting relative to its predecessors.

At my company (scalyr.com), we've built a more-or-less clone of LevelDB in Java, with a similar goal of extracting more performance on high-powered servers (and better integration with our Java codebase). I'll be digging through rocksdb to see what ideas we might borrow. A few things we've implemented that might be interesting for rocksdb:

* The application can force segments to be split at specified keys. This is very helpful if you write a block of data all at once and then don't touch it for a long time. The initial memtable compaction places this data in its own segment and then we can push that segment down to the deepest level without ever compacting it again. It can also eliminate the need for bloom filters for many use cases, as you often wind up with only one segment overlapping a particular key range.

* The application can specify different compression schemes for different parts of the keyspace. This is useful if you are storing different kinds of data in the same database.

* We don't use timestamps anywhere other than the memtable. This puts some constraints on snapshot management, but streamlines get/scan operations and reduces file size for small values.

Do you have benchmarks for scan performance? This is an important area for us. I don't have exact figures handy, but we get something like 2GB/second (using 8 threads) on an EC2 h1.4xlarge, uncached (reading from SSD) and decompressing on the fly. This is an area we've focused on.

I'd enjoy getting together to compare notes -- send me an e-mail if you're interested. steve @ (the domain mentioned above).

<comment><USER4> SkyDB using LMDB gets 3GB/sec on a standalone PC. [https://groups.google.com/forum/#!msg/skydb/CMKQSLf2WAw/zBO1...](https://groups.google.com/forum/#!msg/skydb/CMKQSLf2WAw/zBO1X35alxcJ)

<comment><USER5> Wow, Awesome link, LMDB always seems to fly under the radar, SkyDB+LMDB. Genius. (and written in go! I'm sold... well will at least give it a bash)

</comment></comment></comment><comment><USER6> Hi guys, I am Dhruba and I work in the Database Engineering team at Facebook. We just released RocksDB as an open source project. If anybody has any technical questions about RocksDB, please feel free to ask. Thanks.

<comment><USER7> Hi Dhruba, thanks for volunteering to ask questions.

What are the big algorithmic ideas behind RocksDB?

My understanding is that LevelDB is based on log structured merge trees. These can be deamortized using methods from Overmars's "The Design of Dynamic Data Structures" or Bender et al.'s "Cache-Oblivious Streaming B-trees". How did you reduce latency?

What else was slowing down databases larger than RAM? How did you fix that?

<comment><USER6> RocksDB has an LSM architecture, similar in nature to HBase, leveldb, etc. But the implementation is based on a Theorem that we will be publishing shortly. I am working on the Theorem with a colleague of mine.

Cache Oblivious B-trees is an interesting paper. Similarly fractal trees. Most of them optimize the case when index nodes are not in memory. However, in our use-cases, we typically configure the system in such a way that most index nodes are in memory.

For an LSM database, the key component is "compaction". You can ingest data only as fast as you can compact, otherwise u get a unstable system. .1 RocksDB replaced the Level-style compaction of leveldb with UniversalStyleCompaction that has reduced write amplification. This boosts performance. 2\. RocksDB implemented multi-threaded write, which means that parallel compactions on different parts of the database can occur simultaneously. This boosts performance. 3\. Bloom filter for range-scans: this boost read performance 4\. MergeType records that allows higher level objects (counters, lists) use only- write instead of a read-modify-write. Improves performance. 5\. And many more...

<comment><USER7> Can you share with us the statement of that theorem?

What is "UniversalStyleCompaction", and why is it capitalized and missing spaces?

How does a Bloom filter for range scans work? Standard Bloom filters (as you know) are for existence only.

<comment><USER8> I'm guessing this may have been an early draft of some of the statements of the theorem:

[http://webcache.googleusercontent.com/search?q=cache:fTxlRmb...](http://webcache.googleusercontent.com/search?q=cache:fTxlRmb9uMUJ:rocksdb.blogspot.com/+&cd=11&hl=en&ct=clnk&gl=us&client=firefox-a)

</comment></comment></comment></comment></comment><comment><USER9> I'm surprised that the C++ code is not using the RAII idiom in some obvious places.

For example: [https://github.com/facebook/rocksdb/blob/master/db/db_impl.c](https://github.com/facebook/rocksdb/blob/master/db/db_impl.c)

There are many places with bracketed calls to mutex_.Lock and mutex_.Unlock().

An example:

          mutex_.Unlock();
          LogFlush(options_.info_log);
          env_->SleepForMicroseconds(1000000);
          mutex_.Lock()

Why didn't the authors use the RAII idiom here? Even if there are no exceptions expected, the code would still be simpler and less error prone by using a guard object.

<comment><USER10> fixed your link: [https://github.com/facebook/rocksdb/blob/master/db/db_impl.c...](https://github.com/facebook/rocksdb/blob/master/db/db_impl.cc#L1665)

Take another look! There's a guard object used at the function scope to ensure the lock is released, and this block is bracketed to _release_ and _reacquire_ the lock, not acquire and release. There may be a case for a guard object that does the release/reacquire, but its definitely not a slam dunk like acquire/release

<comment><USER11> Still, that's not exception-safe, correct? If LogFlush or SleepForMicroseconds throws an exception the mutex will be unlocked twice, which pthreads disallows for normal mutexes...

<comment><USER12> You know, for a second I thought you were wrong, but I changed my mind. This _does_ look like a bug, and a simple on to avoid at that.

It's tough, because Rocks is still highly based on LevelDB, which conforms to Google's coding style guideline, which makes RAII more than a bit tricky to do right.

</comment></comment></comment></comment><comment><USER13> Well LevelDB is already good. And if this improves on it, that's great.

I was looking at embedded key value stores and also found -- HyperLevelDB (from creators of Hyperdex database). They also improved on LevelDB in respect to compaction and locking:

[http://hyperdex.org/performance/leveldb/](http://hyperdex.org/performance/leveldb/)

So now I am curios how it would compare.

Another interesting case optimized for reads is LMDB. That is a small but very fast embedded database at sits at the core of OpenLDAP. That one has impressive benchmarks.

[http://symas.com/mdb/microbench/](http://symas.com/mdb/microbench/)

(Note: LMDB used to be called MDB, you might know it by that name).

<comment><USER14> The LMDB statistics are very strange - why is synchronous SSD performance _worse_ on most figures than HDD performance? Something seems very wrong with these benchmarks:

        Section 5 (SSD) F (Synchronous Writes)

        Random Writes

        LevelDB              342 ops/sec
        Kyoto TreeDB          67 ops/sec
        SQLite3              114 ops/sec
        MDB                  148 ops/sec
        MDB, no MetaSync     322 ops/sec
        BerkeleyDB           291 ops/sec

        Section 8 (HDD) F (Synchronous Writes)

        Random Writes

        LevelDB             1291 ops/sec
        Kyoto TreeDB          28 ops/sec
        SQLite3              112 ops/sec
        MDB                  297 ops/sec
        BerkeleyDB           704 ops/sec

Really? LevelDB is four times faster on an HDD than an SSD with synchronous writes? BerkeleyDB is over twice as fast?

This smells.

<comment><USER4> Keep in mind, the HDD was using ext2 and the SSD was using reiserfs. Synchronous writes on ext2 are faster than all journaling filesystems.

<comment><USER15> Not three orders of magnitude faster, which is the difference between hdd and ssd random writes.

<comment><USER16> Three orders of magnitude faster would mean 1000x faster. You probably meant 3 times faster.

<comment><USER15> SSDs really are 1000x faster at random writes (~200,000 iops vs ~200 iops)

</comment></comment></comment></comment></comment></comment><comment><USER17> this is cool, though I'd wonder how it compares to Kyoto Cabinet. another big issue I've run into personally is the fact that both LevelDB and KC don't explicitly support multiple processes reading the db at once. (KC's API allows this but advises against it, LevelDB afaik doesn't even allow it.) I wonder if RocksDB gets past this.

<comment><USER4> Kyoto Cabinet will self-corrupt if you use it that way. LMDB supports multi- process explicitly.

<comment><USER17> can you explain how this happens? if it's just a read-only process, how can it corrupt anything?

</comment></comment></comment><comment><USER18> A very minor point:

The illustrative code snippet on the home page has a spurious semicolon on the first line:

        #include <assert>;

<comment><USER19> fixed! - <USER2>

</comment></comment><comment><USER20> The benchmark at [https://github.com/facebook/rocksdb/wiki/Performance- Benchma...](https://github.com/facebook/rocksdb/wiki/Performance- Benchmarks#2-bulk-load-of-keys-in-random-order) states that for LevelDB, "in 24 hours it inserted only 2 million key-values", and that "each key is of size 10 bytes, each value is of size 800 bytes".

I might be missing something, but that took just a few minutes on my ~2 year old desktop machine. Sample code: [https://gist.github.com/wbolster/7487225](https://gist.github.com/wbolster/7487225)

<comment><USER6> There was a typo, the 2 million should have been 200 million keys. I fixed the wiki page. Thanks again for pointing it out.

</comment></comment><comment><USER21> Node.js bindings (compatible with levelup) have already been released by rvagg: [https://npmjs.org/package/rocksdb](https://npmjs.org/package/rocksdb)

</comment><comment><USER22> Tnx for all the comments! Feel free to continue the discussion at [https://www.facebook.com/groups/rocksdb.dev/](https://www.facebook.com/groups/rocksdb.dev/)

</comment><comment><USER23> Looking forward to see this in Riak</comment>


Address Verification and Full PGP Support - <AUTHOR> https://protonmail.com/blog/address-verification-pgp-support/ <comment><USER2> I spoke on Mastodon recently about Protonmail - it's a scam and I cannot recommend it to anyone. They own your email, they don't support open protocols including SMTP and IMAP and the only way to export your emails is through a proprietary end-user application. They excuse this nonsense by saying that it's necessary for encryption, which is blatantly false. Their security is also based on trusting ProtonMail, since they could easily siphon off plaintext at the SMTP level or secretly modify their JavaScript to exfiltrate your private keys from the web browser. Genuinely secure systems do not require you to trust their operators.

>PGP, because it is built on top of email, is therefore also a federated encryption system. Unlike other encrypted communications systems, such as Signal or Telegram, PGP doesn't belong to anybody, there is no single central server, and you aren't forced to use one service over another. We believe encrypted communications should be open and not a walled garden. ProtonMail is now interoperable with practically ANY other past, present, or future email system that supports the OpenPGP standard, and our implementation of this standard is also itself open source.

This is rich. Why don't you start with the far more fundamental and important standards of SMTP and IMAP, Protonmail? Why don't you open source your desktop & mobile applications or your bridge? What a joke.

<comment><USER3> > They excuse this nonsense by saying that it's necessary for encryption, > which is blatantly false.

I don't see how this is false. Protonmail encrypts all user emails on the server, which can only be unlocked by the user's password. SMTP and IMAP would require transmitting the password to the server for decryption, which makes it prey to interception a la HushMail [0]. This is why they have the bridge, which runs its own IMAP server on the client and performs all authentication and decryption locally. Of course, the bridge isn't open source yet, so we can't be sure it isn't sniffing your password anyway, but that is orthogonal to the issue of supporting SMTP.

[0] [https://www.wired.com/2007/11/encrypted-e- mai/](https://www.wired.com/2007/11/encrypted-e-mai/)

<comment><USER4> No, they could just transmit PGP encrypted emails down IMAP and the user could decrypt them with any number of popular PGP implementations. Your IMAP/SMTP password doesn't necessarily have to be the same as your PGP key password, nor should you even need to give Protonmail your PGP private key (password protected or not), nor does IMAP/SMTP even have to be authenticated with a password (GMail notably pioneered an OAuth-based extension to both).

<comment><USER5> This is completely ignoring key management as a barrier to using encryption, not to mention manually syncing local keystore with the server, not being able to provision keys across devices, etc. In other words, why PGP and email encryption in general has largely been a failure over multiple decades. It's too complex and too difficult.

<comment><USER4> None of these difficulties prevent you from making the access available. It has no bearing on users who already choose not to use IMAP. This is a pretty bad excuse.

<comment><USER5> Only if you completely discount the related costs of building and maintaining such an additional API as well as the customer service impact of basically allowing users to screw up their own key management.

<comment><USER4> Even if I concede this to you (and I don't), you've already written an IMAP/SMTP bridge that solves these problems. Open source it and make it available to free users and the problem disappears (well, is reduced. Most non-technical users don't know how to run a daemon after all, and making them put it on their own infrastructure is lame as hell).

<comment><USER5> Because running PGP software and handling key management locally is way easier than double-clicking on an installer? I don't concede that for a second. Remember that the alternative you want is ciphertext directly via IMAP, which is not at all user-friendly, which is exactly why we didn't do it.

As for the bridge, that is exactly what we'd like to do, as I've said before.

And customer support time and developer time devoted to this would cost money and represents an opportunity cost as well and that's a fact, not a point to be conceded.

<comment><USER4> I said even if _I_ concede, I didn't expect you to.

And like I've said before, what you'd like to do and what you are doing are different. Nothing stops you from open sourcing it today. Put in comments that the APIs you use are not officially supported if you must. Open source it! It should have been open source a year ago! Open source it!

<comment><USER6> And you give me all your money. Give me All Your Money!

Some people are just like that :)

Great product, Proton team, thanks.

</comment></comment></comment></comment></comment></comment></comment></comment></comment></comment><comment><USER7> This is very good news!

It's also great to have [https://protonirockerxow.onion/](https://protonirockerxow.onion/) :)

But I have a suggestion. If I hit [https://protonmail.com/](https://protonmail.com/) via Tor, there's no warning to use the .onion address. Except for an "Onion Site" link at the bottom. And after I recently created a free account via Tor at [https://protonmail.com/](https://protonmail.com/), I got that either SMS verification or a credit/debit card number was required for activation. Gak!

But using [https://protonirockerxow.onion/](https://protonirockerxow.onion/), there's no authentication requirement for activation. So perhaps there could be an alert when connecting to [https://protonmail.com/](https://protonmail.com/) via Tor. As I recall, Bitmixer or Helix Light used to do that. Or maybe just put the .onion address near the top of the front page.

<comment><USER8> There is a draft IETF standard to handle this!

It uses a new "alt-svc" header that lets you specify alternative URLS to access a domain.

Cloudflare is using it for their 126.96.36.199 service. If you look at the headers at [https://tor.cloudflare-dns.com/](https://tor.cloudflare-dns.com/), you get

alt-svc: h2="dns4torpnlfs2ifuz2s2yf3fc7rdmsbhm6rw75euj35pac6ap25zgqad.onion:443"; ma=315360000; persist=1

I don't know if the Tor Browser Bundle handles this yet but its a great idea!

[https://developers.cloudflare.com/126.96.36.199/fun-stuff/dns- over...](https://developers.cloudflare.com/220.127.116.11/fun-stuff/dns-over-tor/) [https://tools.ietf.org/html/draft-ietf-httpbis-alt- svc-10](https://tools.ietf.org/html/draft-ietf-httpbis-alt-svc-10)

<comment><USER7> It looks like HTTP/2 (and specifically alt-svc) is explicitly disabled in Tor browser.[0]

> Design Goal: SPDY and HTTP/2 connections MUST be isolated to the URL bar > domain. Furthermore, all associated means that could be used for cross- > domain user tracking (alt-svc headers come to mind) MUST adhere to this > design principle as well.

> Implementation status: SPDY and HTTP/2 are currently disabled by setting the > Firefox preferences network.http.spdy.enabled, network.http.spdy.enabled.v2, > network.http.spdy.enabled.v3, network.http.spdy.enabled.v3-1, > network.http.spdy.enabled.http2, network.http.spdy.enabled.http2draft, > network.http.altsvc.enabled, and network.http.altsvc.oe to false.

Rather than redirection, I was thinking just a fork in rendering, if the user's IP is a Tor exit.

0) [https://www.torproject.org/projects/torbrowser/design/](https://www.torproject.org/projects/torbrowser/design/)

</comment></comment></comment><comment><USER9> It's nice to see their own keyserver.

I wonder though if it wouldn't be more practical to support the Web Key Directory protocol [0]. WKD is both more secure than HKP (as it's always over HTTPS and authenticates user's domain), it's enabled by default in a growing number of email clients (Enigmail, GPG for Outlook, KMail) and providers (kernel.org [1], posteo.de), it's used by GPG when locating a key and the setup is incredibly easy (just put binary key in one location).

(to check it out try `gpg --locate-key firstname.lastname@example.com` in modern GnuPG)

From my perspective it looks like a perfect match for ProtonMail for both use cases: exposing @protonmail.ch users' keys and fetching keys of contacts on other servers.

[0]: [https://wiki.gnupg.org/WKD](https://wiki.gnupg.org/WKD)

[1]: [https://www.kernel.org/category/signatures.html](https://www.kernel.org/category/signatures.html)

<comment><USER5> We'll probably do this soon, HKP is older and more broadly supported at the moment so it got built first.

<comment> dane-pgp That makes sense, thanks. I'd love to see support for RFC-7929 at some point too.

[https://tools.ietf.org/html/rfc7929](https://tools.ietf.org/html/rfc7929)

It has the advantage of not relying on the Certificate Authority system, and not requiring a full web stack (which some email clients and servers wouldn't want to open themselves up to). DNSSEC also allows Authenticated Denial of Existence, so that unavailability of a server isn't treated as meaning the user doesn't have a key in the directory.

For reference, this technology is also already supported by GnuPG and Posteo.de:

[https://posteo.de/en/blog/new-posteo-public-key- directory](https://posteo.de/en/blog/new-posteo-public-key-directory)

<comment><USER10> > It has the advantage of not relying on the Certificate Authority system

I wouldn't say it's an advantage, while CA system has many flaws at least it's monitored somehow (for example via Certificate Transparency) while putting keys in DNS would require the app to validate records (does GnuPG do that?), not to mention the queries are not encrypted (so are visible to any hop) and could be transparently replaced by your government or TLD operator. Many DNS providers do not allow adding "exotic" records.

For further info see e.g.: [https://sockpuppet.org/blog/2016/10/27/14-dns- nerds-dont-con...](https://sockpuppet.org/blog/2016/10/27/14-dns-nerds-dont- control-the-internet/)

> and not requiring a full web stack (which some email clients and servers > wouldn't want to open themselves up to).

Email clients and servers that do PGP usually have "full web stack" already to connect to keyservers.

Additionally while DANE or PKA lookups can be enabled in GnuPG only WKD is enabled by default ("auto-key-locate" is "local,wkd").

Nice nick by the way :)

</comment></comment></comment></comment><comment><USER11> Yet they still don't support read receipt privacy when you enable loading images by default for unencrypted email.

Webmail providers can implement read receipt privacy by requesting images from every email automatically on-delivery instead of on-read. Doing this for non- existent mailboxes also prevents mailbox enumeration.

<comment><USER12> Potential there for a DOS attack isn't there?

"hey look this server blindly downloads images".. Sends a million emails with a bunch of tiffs.

<comment><USER13> I don't really see this as a major problem. Just grab a reasonable number of bytes and disconnect. If a user does end up wanting to view the full TIFF, just say "this server is probably stealing your private information and you will also go over your storage quota by loading this image". If the user is OK with that, then download the image again.

99% of the time, the image is just a company logo in someone's email signature and takes essentially zero storage space or bandwidth to retrieve at receive time. For the special cases, just warn the user about the implications of downloading the image, and go do it if they ask.

<comment><USER5> This is basically the plan. There are some other concerns, notably bandwidth/space and, given it's untrusted input, thinking through all the other ways it could be abused. There will certainly be a byte limit.

</comment></comment></comment></comment><comment><USER14> Maybe the title should read "Email address verification and full PGP support".

This should not be confused with real physical address verification.

</comment><comment><USER15> For the other perspective, fastmail has a good write-up on why they don't offer PGP: [https://fastmail.blog/2016/12/10/why-we-dont-offer- pgp/](https://fastmail.blog/2016/12/10/why-we-dont-offer-pgp/)

</comment><comment><USER16> relevant: [https://blog.cryptographyengineering.com/2018/05/17/was- the-...](https://blog.cryptographyengineering.com/2018/05/17/was-the-efail- disclosure-horribly-screwed-up/)</comment>


Two types of command-line interfaces (2016) - <AUTHOR> http://ballingt.com/rich-terminal-applications/ <comment><USER2> Editing multiline commands directly on the commandline in Fish and IPython5 is a nice feature, I do feel that Jupyter notebooks or Org-mode with langservers is another type of CLI that should be mentioned. With that said I feel that Excel is counterpoint, it has something similar to CLIs as well; it can instantaneously display and filter lots of data. This is where Org-mode and Notebooks fails they have a laggy UI when you give them too much data.

<comment><USER3> are you kidding?

It is easy to perform calculations involving millions of numbers in org-mode (e.g., using numpy) that I wouldn't even try in Excel (is there a limit of 16k columns?)

<comment><USER2> Thanks for bringing that up, I'm not talking about calculation, it's text output that is formated to be visible on screen (i.e. terminal), and Emacs shell has historically had a really crappy latency when displaying lots of data. Excel oftens out preforms custom Notebooks for data that fits its scope. Which is why Excel is used so much, it feels very when working with somethings meaning it gets used in areas where it should not be.

This musing to me is not about which tool is the best but what UI feels good to use, even though it CLI based.</comment></comment></comment>


Ask HN: How did you get rid of social networks for good? - <AUTHOR> Markets are flooded everywhere and social media management is becoming a personal burden more than an opportunity to me as a casual user. I am therefore in the process of deleting my profile from most of the non-work-related websites. How did you do this in your past and how did it go for you some time down the line? Is it really advisable to detox and stay out for good? Thanks! <comment><USER2> I'm a fairly recent quitter. Stopped using Twitter in January, and almost completely stopped using Facebook in February. Deleted my LinkedIn in March.

I sat down and really thought about what I was getting out of each of the services and then decided if that was important. For Twitter it was pushed updates on things going on around me. I realized it was almost 100% noise. That was easy to quit.

Facebook had a bit more value, but was still 90% noise. I first eliminated all the noise I could through unfollowing and unfriending many, many people. Then all that was left was a few family members and FB Messenger.

LinkedIn was nothing to me. I've had this job for ten years now and I have no plans to find anything new anytime soon. That was an easy delete.

</comment><comment><USER3> Shut down my Facebook years and years ago, maybe missed one or two parties? Started up a Twitter, almost never check it.

Like, it's not really a big deal to shut this stuff off, and it'll help you get back in touch with reality.

I never got on LinkedIn, and it has in no way hurt my career.

</comment><comment><USER4> It seems like a big deal at first, but just go ahead and delete your account(s).

In my case I noticed the benefits within a few days. Surprisingly I never felt like I was missing out on anything, though it takes a little more effort to stay in touch with friends (a plus IMHO).</comment>


Sixteen APL Amuse-Bouches (2016) - <AUTHOR> https://vector.org.uk/sixteen-apl-amuse-bouches/ <comment><USER2> The FinnAPL Idiom list is absolutely invaluable as an exposition of how APL can be used to implement new abstractions. A little blue book published by the Finnish APL Association, it contains about 600 hand polished APL idioms. [http://www.finnapl.fi/idilib.htm](http://www.finnapl.fi/idilib.htm)

APL is heady stuff for the right kind of mind. I remember Larry Breed demonstrating how the APL language notation often automatically extends two dimensional processing to three or more dimensions.</comment>