HN user

longrod

615 karma
Posts33
Comments92
View on HN
notesnook.com 3y ago

Notesnook – The Evernote Alternative

longrod
3pts0
news.ycombinator.com 3y ago

Ask HN: Why does dart –help take 500ms?

longrod
1pts2
www.spotvirtual.com 3y ago

We are breaking up with CSS-in-JS

longrod
4pts0
news.ycombinator.com 3y ago

Ask HN: Any good plug'n'play static site generators for docs?

longrod
6pts4
news.ycombinator.com 3y ago

HolyJit: A New Hope for JavaScript (2017)

longrod
1pts0
twitter.com 3y ago

When was the last time you sent an SMS?

longrod
1pts1
news.ycombinator.com 3y ago

Ask HN: How's Postal in production? What's the deliverability rate look like?

longrod
1pts1
www.worldhistory.org 3y ago

1453: The Fall of Constantinople

longrod
1pts0
blog.notesnook.com 3y ago

It's Time to Leave Bitwarden

longrod
2pts0
monograph.notesnook.com 3y ago

Why do user-level systemd services die off arbitrarily?

longrod
2pts0
twitter.com 3y ago

Rust is not a “safe language”

longrod
21pts18
medium.engineering 3y ago

Why contenteditable is terrible (2014)

longrod
1pts0
blog.notesnook.com 3y ago

Why Notesnook requires an email address

longrod
2pts0
drewdevault.com 3y ago

Don't Sign a CLA (2018)

longrod
2pts0
danb.me 3y ago

Why the term "open source" is important

longrod
54pts98
github.com 3y ago

Lexbor: Fast HTML Renderer library in C

longrod
3pts1
github.com 3y ago

Notesnook (encrypted notes app) is going open source

longrod
4pts1
monograph.notesnook.com 3y ago

Generating og:image dynamically using wkhtmltoimage

longrod
2pts0
fluentreports.com 4y ago

Goodbye NativeScript

longrod
2pts0
blog.ssanj.net 4y ago

Property Based Testing Patterns

longrod
1pts0
bellard.org 4y ago

Libnc: C Library for Tensor Manipulation

longrod
2pts0
source.opennews.org 4y ago

Our search for the best OCR tool (2019)

longrod
91pts31
lemire.me 4y ago

Filtering Numbers Quickly with SVE

longrod
1pts0
github.com 4y ago

Sophia – Modern transactional key-value storage in C

longrod
2pts0
prepack.io 4y ago

Prepack – A tool for making JavaScript code run faster

longrod
2pts0
news.ycombinator.com 4y ago

Ask HN: Things to consider when open sourcing a SaaS product

longrod
1pts0
www.avg.com 4y ago

A Brief History of Computer Viruses (2020)

longrod
3pts0
blog.notesnook.com 4y ago

Rendering Invalid HTML

longrod
1pts0
ryanseddon.com 4y ago

Stealing the users back button with the History API (2013)

longrod
31pts19
github.com 4y ago

Graffiti – HTML/CSS Engine for Node.js and Deno Written in Rust

longrod
1pts0

Most features that appear to only be available in native apps can quite trivially be added using any cross-platform framework like Electron. Multiple windows is not something the is platform-restricted i.e. even web apps can do it if they try.

Have you given Notesnook a try? While it doesn't have multi window support they have it on their roadmap: https://notesnook.com/roadmap

I think this is nothing except shitposting. The whole blog reads like an angry rant of someone who didn't get what he wanted. This is not new. Layoffs are not a new thing. New management, new rules, it's always been like this.

Do I feel sorry for the people who got layed off? Of course I do! I wouldn't want to be them right now. I feel for them. But the consequences mentioned in this post is completely unreasonable. These are the kinds of points you hear from a depressed person who thinks the world is going to end because all the toilet rolls are suddenly out of stock.

The amount of doomsaying I see everywhere regarding the Musk takeover is baffling. I am no Musk fanboy but this is completely irrational. The fact of the matter is, people don't like change. That's all there is to it. Change automatically makes people cry out.

Here's a scenario for you:

What if the new Twitter is better? What if it isn't the toxic place you expect it to become? What if you are completely wrong? Have you considered that? Here's how I see this situation:

Musk is not an idiot. He must know exactly what he needs to do. This isn't his first rodeo and comments like "running a service of this scale and size is incredibly complex with downtime and uptime and blah blah" is incredibly naive. Musk runs at least 2 companies that require a huge network & availability guarantees. He knows what's needed there.

Twitter is going no where and if you think it'll go down in the coming years, you have a surprise coming your way. I am optimistic because of Musk isn't known to give up. This can fail for sure but I don't think that'll be the end of it.

The next step in my opinion is cutting down on the Twitter codebase. Trimming features. Shutting down unnecessary stuff. They laid off 25% of the workforce so at least 25% of Twitter will be affected. Let's see which parts though. There's a lot of unnecessary junk in there (communities, spaces etc.) that I'll be happy to say goodbye to.

Sucrase is proof that JS is not the problem when it comes to slow performance. JS is not slow. NodeJS is not slow. It's the code that is slow. All these people wanting to write it in Rust or Go or XYZ programming language need to acknowledge this.

Yes, multithreading is awesome and really helpful but it's the cherry on top, not the whole thing. If the same amount of effort was put into optimizing the TSC codebase as it is being spent to rewrite it in Rust, I have no doubt that it can become faster. Perhaps it'll require some big changes but it won't create compatibility concerns and it won't be a cat-and-mouse race between the Rust version and the TS version.

I don't think "Write it in Rust" is always the solution to fast programs. Rust itself can be pretty damn slow if you don't keep performance in mind. That is why you have to optimize and profile and optimize over and over again. Can't the same be done for TSC?

I think the biggest reason devs don't do this is because no one likes profiling and optimizing since it is a slow and boring task. Rewriting is so exciting! It's the thing you do when you are tired of maintaining the old codebase. So just ditch it and rewrite it in Rust.

I have nothing against Rust, mind you. I love what it has done but I don't think rewriting everything is either feasible or even the solution. And waiting for that to happen for every slow tool out there is utter foolishness.

The audience is hackers as it should be. You can't cater to daily users at this stage. You want people who can potentially fix the bugs they come across or add the features they miss. A usable OS is no joke and it certainly isn't a one man project. If enough people get on this, it might actually become daily-usable.

I think people are looking at this the wrong way. It's not so much about the code as it is about establishing an authority. Musk takeover is often regarded as banditry and I wouldn't be surprised if the employees didn't take him seriously in the beginning. This is his way of saying, "I don't trust you, I don't know what you have been up to but things are going to be different so better get used to it."

Using Tesla engineers is just to get everyone talking. I don't think they can get a clear picture by looking at last 30 days of code but they can use this as reason to lay a lot of people off. Not that Musk needs reasons, obviously.

In my mind I think Twitter is going to go on a very, very different direction than we all expect. You have to understand that Musk isn't after the big dollar here but rather he is experimenting which has a lot of chances to fail. Twitter could become extraordinary or it could become utter trash, we'll have to wait and see. Personally, I am quite excited to see where this goes.

Thank you for sharing Andreas! It's absolutely phenomenal how far along SerenityOS has come and it's also a peek at how FOSS is supposed to be - a way to learn, hack on something fun, share it with others but without any huge expectations.

Building the next unicorn is awesome and all but in my opinion, this has it's own place. I am glad some people out there get to work on their dream projects and actually can make a living out it. Kudos to all the supporters, obviously.

I also love how focused SerenityOS is and what kind of audience it caters to. Some people might say, "make it for everyone" but that doesn't work most of the time. Having a focused audience allows a lot of freedom in the way of UX/DX, docs, communication etc. So I am glad Andreas set that down upfront.

HTML is not for writing but for creating UIs. That was why it was created anyway. Markdown was specifically created for writing. It has no other purpose.

Saying that Markdown is bad is really naive. There are not many ways to specify formatting without it getting in the way of your writing. Markdown is popular because it strikes the right balance where reading a markdown document requires a lot less visual strain compared to the same HTML document. It requires the least amount of letters to specify formatting - italics is 2 chars, bold is 4 chars, underline is 2 chars etc. Lists are mostly inferred and require no additional formatting. Compare that to HTML which requires 5+n chars (where n is the number of chars in the tag name) regardless of which format you want to use.

Markdown does have it's quirks but they don't come up 99% of the time unless finding them is specifically your intention. Knowing whether *__hello__* is bold italic or italic bold is not important unless you are writing a parser.

The downsides of Markdown are much, much less than the downsides of HTML. Writing is not the same as designing a website or a UI. It's not meant to be pretty and typesetting + styling should not be the concern of writers.

Looks cool but...why not just send the .ics file directly via your IM of choice? Am I missing something here? I don't see the benefit if you still have to click, open file in your calendar, add it to the calendar.

Can you tell me why the above wouldn't work and why this is better?

If you are going for human readability then making your code expressive is the only way. Abstract away the code parts under a layer of very simply named functions/classes and boom! even a child will be able to understand what's going on.

Obviously, that isn't always possible. I find this approach especially useful in writing e2e browser tests. You write an abstraction over the testing framework's (playwright, puppeteer etc) interaction and then use that in your tests.

So instead of writing:

    await page.click(".play-button");
You do:
    await app.play();
This also has the benefit of extreme reusability. Doesn't work for everything though.

Love what you have done with AppSmith. I started with Budibase but their query language didn't allow for cross collection/db queries. Then I learned about AppSmith and it was absolutely phenomenal. I wasn't particularly impressed by the UI (Uify looks much more modern) but I wasn't building anything public. Here's my use-case:

- Managing users (user data is spread across multiple services/db so JS works very well here)

- SaaS analytics (total users, monthly users, subscriptions etc. For this AppSmith's charts "just worked" along with full support for MongoDB query language).

- Managing small internal tools (sending emails to users via GUI etc.)

I haven't tried some of the new stuff you guys have shipped yet (the new table, some light customization etc.). The whole reason behind choosing something like AppSmith was that I will only have to be concerned about data. No fuss about UI. No manual styling. No tinkering. For this AppSmith is perfect.

Along this line, I think what would be absolutely amazing is something like themes. They should be separate (think like editor themes). Theme designers can design how the widgets will look. Builders will focus on what they want to build. Instead of adding multitudes of controls and customizability in the widget view, this would be a better approach imo since I'd never be able to customize everything consistently which would result in a really broken UI.

Aside from that, AppSmith is great. Oh another thing that really frustrated me was the small inline editor for events/callbacks. It'd be super helpful to allow maximizing it somehow. Another thing in the same line is allowing importing modules. So for example, I can use AppSmith's minimal SDK to code my logic in TS using VSCode and then import that into AppSmith and it just works. It'd also allow using JS-only libraries from npm etc. This is definitely not as simple as it sounds but you get the idea.

Not even close to AppSmith:

- Open source

- Self hosted

- VCS integration via git

- Lots of widgets

- Support for custom JS anywhere

- UI is okayish (for internal apps)

If this was open source & self host able then maybe but as it stands, there's no point. AppSmith has been the only low-code tool that allowed me to build exactly what I wanted thanks to their JS support. Budibase etc all lack that and fail miserably outside of a few standard cases.

OP here. To add a little context.

I have been using SendGrid for the past year and their deliverability rate has gotten down 13%. I am getting 5-10 emails every day from users claiming that they don't receive the email. I have 99% reputation BTW. So the problem does seem to be SendGrid since I barely send > 40K emails per month.

So I have been thinking of either self hosting via Postal or using Amazon SES. However, I haven't used any of those before so don't know the downsides. I am particularly concerned about deliverability.

Hope someone can shed some light on this.

Been using (and following) Notesnook [0] for over a year now. Truly phenomenal what the devs have done in such a short time.

But I don't think any one note taking style or software would apply to 2 people. Everyone's thought process is so different. I tried doing the Zettlekasten but it didn't work out (for me). The worst problem with taking notes is finding them (and God knows all these tools don't make it easier). It's tragic to see that search is often last on the list.

What I wish for is search like Google (when it was better than it is now) for my own notes - intelligent, fast, and predictable.

[0] https://notesnook.com

Does DCO prevent this kind of thing from happening? I think moves like this demotivated and discourages a lot of potential contributors and spreads fear. That's not a good thing.

Imagine a contributor who's first contribution to Open Source was this project. I am not sure he'd be very happy about a move such as this (or maybe he won't care).

The article is right in that setting up a server for any kind of hosting is not a simple task. There are no "good defaults" or "templates" easily embeddable/extendible for your specific use-case.

I think this is becoming increasingly common for Cloudflar e which sets a bad precedent. They can scream however much they want that they don't want to make these decisions nor do they like to be put on the spot but it doesn't save them from the backlash of being a "curator of the internet".

Moderators get the worst backlash everywhere in the world. The only difference is that Cloudflare continues to refuse the fact that they have quite a lot of power over whose traffic they let through. When you, basically, govern 20% of internet traffic you must take the responsibility for it as well.

This article is a nonsensical shout in the air. Cloudflare, like Google, is not looking over every single request that goes through them. They take these actions after enough noise is raised to highlight the issue. The problem is that Cloudflare will become prone to bullying.

What I mean is that if I have a good number of fanatic followers, I can raise noise against a rival platform and get Cloudflare to, at least, scrutinize it and, at worst, deplatform it. Cloudflare will need to set in place some policies to protect themselves from this.

If Cloudflare does this kind of thing enough times, they will unintentionally become a policing force. That's really not a good place to be in for a business.

In cyber security there's no such thing as 100% secure. There's insecure, secure, less secure, more secure etc. Always relative because security is not a concrete thing. You can't at any point say this app is 100% secure. That doesn't mean that the app is not 100% secure or that the app shouldn't use encryption since it can't be proven.

This is why I like what the folks over at Notesnook are doing with Vericrypt [0], which essentially allows users to verify the encryption themselves in a very easy to use way.

[0] https://vericrypt.notesnook.com/

You can't completely remove the trust factor no matter what you do. Can you completely 100% trust your computing device? Maybe. Can you 100% trust your network? Maybe.

But things like encryption help build trust. They ensure that there are safeguards in place in case something gets compromised. They reduce number of bad actors from unlimited to just one (the vendor).

In my opinion, all these are very good reasons to always opt for E2EE even if it isn't perfect.

There are downsides to everything. This whole blog sounds like an excuse: "we don't want to apply E2EE because it can be a little inconvenient so we will just go ahead and store everything in plaintext because who cares!"

You forgot to mention the biggest downside to not encrypting the notes: your company can read/edit them on a whim. Sure, E2EE isn't perfect but it sure is a PITA for vendors to steal data behind their users' back.

The solution to "E2EE is hard" is definitely NOT to ditch it altogether. Nothing is perfect. As a software vendor it should be mandatory to have E2EE in place. It doesn't matter if it's notes or emails or messages. I, the user, should decide what is private and important - not you.

I think this is a good idea ONLY as a fallback. Email deliverability is a very real problem even if it happens to only 1% out of 99% of your users. What happens when a customer emails saying they can't verify their account because they didn't receive any email? It'd be quite seamless to offer this as a secondary option.

It took Linux desktop some 20 years to reach the point where you could just use it i.e., no tinkering needed, everything works by default, you install the software you need and that's it. It's not perfect even now but it's much better. I rarely have to pop into the terminal to tinker with a system config file now.

We don't have 20 years to wait when it comes to free software phones. The problem is that phones are not meant to be hacked upon. They are meant to be used. Sure, it may feel nice to tinker and stuff but everything should just work before you can even consider it a daily driver.

I haven't personally used Librem or Pinephone so I don't know how far along they are in terms of user experience (not developer experience).

Supabase Series B 4 years ago

All of those are supported in Parse as well. ORMs are a feature, not a bug. Writing SQL is all well and good but if you have GraphQL, it's not an issue. I think the whole point behind tools such as Supabase & Parse is a well defined & safe set of defaults which can easily be customized if the need arises. Parse is very well suited for this as you can custom endpoints, custom pgsql functions, custom edge functions in multiple languages (Go, Node etc) etc. Supabase is not that customizable.

Sure, Supabase has a huge funding etc and it might get there someday but if you are into self-hosting (from which POV I am speaking), Parse comes out way ahead.