Darn I got excited for no reason. I first read "ALL PLATFORMS" and thought that version 2 would also work on Linux. But alas!

It looks like there are only two big bugs keeping it from running in Wine, etc., a flickering issue and the fact that they're using a deprecated Windows API call to save to disk. However, they also seem to show no interest in making it work. They'll still have to update that call eventually, though.

They really should fix it. The fact that they're selling software and not subscriptions (unlike the competition) means that if they get one version running well on Wine, they could take as long as they wanted to get any later version running. Linux users will just be a year or two behind everyone else, but they'd be grateful.

Supposedly they're a relatively small team. According to another comment (I don't use it personally), they're missing a lot of features Adobe has had for decades, so they would probably understandably prioritize porting to Linux under even that.

I sympathize with them completely. The effort needed to port it to Linux most likely won't be worth the small user base (and the even smaller percentage of Linux users that'll use proprietary software)

Same here. I'll gladly pay for Affinity on Linux.

This reminds me a lot of Clojurescript's Reagent https://reagent-project.github.io/ (link also has a counter example)

I've tried using bare React in the past (after using Clojurescript), because I wanted my project to be more approachable for outsiders. But I couldn't really handle the (to me, and the author) unnecessary complexity that's added.

I would even say the Reagent version is even simpler than the Solid.js version, because you're using Clojure's Atom API rather than creating read / write functions. For the adventurous hearted I'd definitely recommend giving it a try!

Edit: Someone posted a Reagent counter example on codepen a few days ago: https://codepen.io/Prestance/pen/PoOdZQw

Imagine if we could have runtime characteristics of solid, dsl of hiccup and simple semantics of clojure atoms and refs!

It should be possible to build an idiomatic cljs layer over solid. Solid’s compilation step can be implemented with clojure macros.

I am already far too nerd sniped by other things to try building it myself but that does absolutely sound like fun.

I was looking for this

How is this different from taking Senolytics? Is it that the vaccine helps your body fight senescent cells rather than having Senolytics remove them?

I think the end result is the same.

But not all senolytics are created equal. They differ in what cells they work on, how powerful they are, and how specific they are (the ratio of senescent to healthy cells they kill).

Here's a quote from the article

> Many of the existing drugs to remove senescent cells are used as anti-cancer agents and may cause negative side effects. Side effects from the new vaccine were fewer, while its efficacy lasted longer, the team said

I've honestly come to the point where I have my handful of most used Magit key combinations to handle certain tasks. But I wouldn't for the life of me know how to apply those with raw git.

You could look at the magit-process buffer (hit $ in a magit buffer) to see what commands (and output) were run. That's how I look up when I have to replicate sth I did in magit in a non-magit context.

It's a little concern of mine too. But there are worse things in life

If it becomes mandatory for email providers to screen emails, will services such as Protonmail become illegal in the EU? Since they don't have access to their users' email content because of encryption.

> Since they don't have access to their users' email content because of encryption.

Regular emails (i.e. without home-brewn encryption that Protonmail provided - and I'm yet to receive such email from any of my contacts who use Protonmail), or any inbound email received from third-party servers are of course not encrypted and Protonmail has pretty easy access to their contents.

Protonmail uses PGP and not "home-brewn encryption" and encryption is on by default between Protonmail users.

False.

Even when it does use PGP, it is meaningless, explanation:

I just created a spare protonmail account. It asked me to pick a username and password, and my account is created.

Next, I send there a message from my other account. Yes, on the receiving end it does write "End-to-end encrypted and signed message", but encrypted and signed by what exactly? I have never created a PGP keys and loaded the public key to Protonmail on either account (and never used my private key to decrypt anything. This can mean only one thing: even if there is some kind of encryption happening, Protonmail themselves generate keys, and uses it for encryption-decryption, never asking you for anything but your password. And if they can uses these keys to decrypt the messages for you, they can decrypt it for anybody.

Protonmail also gives a user an option to export his private keys. Yeah, right. Your private keys.

That experiment shows that whatever is stored on ProtonMail's servers plus your password is sufficient to decrypt your emails. This could be explained by the private key being derived from or encrypted with your password. ProtonMail's documentation says it's the latter (https://protonmail.com/support/knowledge-base/how-is-the-pri...):

> Your ProtonMail private key is generated in your browser. Before sending the private key to the server for storage, we encrypt it with your password (or mailbox password if you use two-password mode). This ensures that you and only you can use your private key.

So the only remaining question is whether ProtonMail has access to your password. If they do, they can decrypt your private key and then decrypt your emails. Often, passwords are sent in plaintext to a server for authentication. But ProtonMail uses the Secure Remote Password (SRP) protocol so they never see your password: https://en.wikipedia.org/wiki/Secure_Remote_Password_protoco.... (source: https://protonmail.com/blog/encrypted_email_authentication/)

Of course, there are other threats to worry about, such as ProtonMail changing their client-side JavaScript to exfiltrate your password. But the system as they've documented it does not appear to have any way to decrypt your email server-side short of guessing your password.

The most likely attacker against proton mail are various law enforcement or intelligence agencies.

Such agency can force PM to modify login process to derive password from submitted form, or to just switch private keys for non-encrypred ones, because the user won't even notice it.

Truly secure entity just wouldn't have private keys on a server at all. Users would have to go through an an uncomfortable process of generating and uploading keys to clients, but they would be truly safe.

To sum it up, you can't really have security and convenience at once. besides skipping a proper key management process, PM also mail skips such important steps as verification of email partner identify and key verification, so you have to trust PM that you are really talking to a person you think you are talking.

> Truly secure entity just wouldn't have private keys on a server at all.

They don't. They have your encrypted private key, but there's no need to keep that secret. (The decryption key is derived from your password, so the password needs to be strong and secret.)

> Such agency can force PM to modify login process to derive password from submitted form, or to just switch private keys for non-encrypred ones, because the user won't even notice it.

Yes, definitely. It's hard to trust self-updating software (like JavaScript in the browser), particularly if you're concerned about targeted attacks. But creating your own private keys and then entering them in the browser wouldn't help you at all against that sort of attack. You would instead need a different type of client that could be trusted somehow not to leak your private key.

It's not uncommon for services like this to offer a downloadable version of the web client so you can pin a version and audit the code as needed. I think maybe https://github.com/ProtonMail/WebClient is that for ProtonMail? If so, you should be able to verify that code and then use that. The fact that an encrypted copy of your private key will live on ProtonMail's servers shouldn't bother you.

You make a poor argument overall. Just because convenience will tend to win out doesn’t mean people shouldn’t choose more secure over less secure.

Your argument boils down to “govt can force them to change how they do that”, as opposed to a flaw in their approach.

YOU make a poor argument. All email correspondence with external servers (I believe it to be 90+ percent of all correspondence) is not encrypted at all, and the rest is bypassable if Protonmail wants or forced to decrypt it. This is just a security theater.

True security is when the provider can't decrypt anything under all circumstances, even under coercion.

Someone once explained to me that any webmail service is inherently able to read your mail: otherwise it could not display your mail to you. True end-to-end encryption means keeping your private keys client-side and the client on a computer over which you have full physical control.

You are absolutely correct, with some caveats. Browser client can generate keys on clientside and allow to offload them as a file to be used on other devices. Our own web XMPP client does that. But Protonmail does not work like this.

Verification is very simple: if you log in on a new device and see all your content while using only login and password to authenticate yourself, then the content stored on a server is NOT encrypted and is readable by server owner.

> if you log in on a new device and see all your content while using only login and password to authenticate yourself

What about if the encryption key is derived from your password? This is common enough for "encrypt file with a password" services, I've personally implemented it in-browser as part of a small project.

Now, having your account password be the same as the email decryption password is also probably a bad idea, but we're far from the server owner being able to read your emails.

AFIAK, Protonmail private keys are kept client-side. They are decrypted by the password inside the browser UI.

No. I just logged in to that very same account using different browser on a different computer. The email was displayed just fine.

Protonmail keeps generated public and private keys on their servers.

It keeps copies that your browser locally encrypted with a symmetric key derived from your password. When you log on your browser downloads them, and decrypts them with your password.

Protonmail do not see your password and without it cannot decrypt the pub/private key pair.

afaik isn't it encrypted using your password or something when before it goes out of the browser

They could conceivably add screening to the javascript client downloaded to the user that does the end to end encryption. Don't know how practical that might be.

I think the more interesting question involves something like Mailvelope. It is a stand alone OpenPGP based encryption system based on the ProtonMail code that provides encryption for webmail. It can be hosted somewhere physically and politically far away from the EU and is an open source project. How will the EU approach the ancient PGP dilemma this time around?

> If it becomes mandatory for email providers to screen emails, will services such as Protonmail become illegal in the EU?

Protonmail should already be illegal in the EU because they operate under swiss mass-surveilance laws and cooperate with US-American law enforcement. Both of which violates the GDPR if they do business in an EU state.

> Since they don't have access to their users' email content because of encryption.

They still have access to all the unencrypted mail their users send and receive and to all the metadata of the enrypted communications.

> Protonmail should already be illegal in the EU because they operate under swiss mass-surveilance laws and cooperate with US-American law enforcement.

:O Seriously? Wow, off to research this I go... That's really disappointing as a paying user. I can't believe I wasn't across this.

You can choose which narration you would believe. It is neverending story.

I'm wondering the same. I suppose they will have to implement some way to scan the emails, or else they will be forced out of business.

That said, I wouldn't bet on it.

Does the EU have some kind of firewall with ISPs to block domains and IP addresses?

No. There are some per-country implementations, but nothing EU-wide.

That is the probable reason why this is being pushed through.

Keyboard macros are great! Although after discovering multiple cursors I found less use for them. 90% of (my) use cases were easier to solve using MC rather than keyboard macros.

I agree. To me tools.build is not a replacement for Lein at all. Lein is more intuitive to most beginners. It's much easier to tell someone to run `lein new some-app` and `lein run` / `lein uberjar`, than to tell them to configure their deps.edn file so they can run some alias with the `-X:...` / `-M` arg to create and run a new project (and who knows which dependency to use / configure to build an uberjar).

For experienced Clojure developers this might seem trivial, but new people (in my experience) are very impatient and want to get started ASAP. Honestly, who can blame them? Why does it have to be so difficult in this day and age?

Another thing I hear Clojure developers say is that beginners can start with Lein, but once you get more experienced with Clojure you can switch to tools.build. Why does a build tool need to be so unusable that you can only use it when you become more familiar with the language? You don't see that with Ruby's Bundler, or Elixir's Mix. They just work, just like Lein does.

> RICH HICKEY: I think that, collectively, we are infatuated with these two notions of easy. We are just so self-involved in these two aspects; it's hurting us tremendously. Right? All we care about is, can I get this instantly and start running it in five seconds? It could be this giant hairball that you got, but all you care is, can you get it.

Simple Made Easy is what attracted me to Clojure, and tools.build, tools.deps, tools.cli are aligned with this mission. Cognitect is doing exactly what they said they would do and have been doing all along.

Re-read the talk here: https://github.com/matthiasn/talk-transcripts/blob/master/Hi...

(PS, a note to Cognitect comms – maybe start here with your next blog post and see if people react differently!)

You forget that on the ground-floor, where programming languages compete for mind-share, easy matters. In fact easy, in terms of getting something working, trumps difficult simplicity any day of the week. Easy is part of what makes an employer want to use your technology.

> In fact easy, in terms of getting something working, trumps difficult simplicity any day of the week. Easy is part of what makes an employer want to use your technology.

The whole point of the talk is that choosing "easy" (as in easy to get started) solutions while ignoring the complexity will be harder to maintain in the long run over choosing the "simple" solution that takes a bit more time to set up. Personally, this tracks pretty closely with my experience.

(Relevant slide from the talk: https://res.infoq.com/presentations/Simple-Made-Easy/en/slid...)

To get started with clj, you need 0 files. From a project directory, you can just type `clj` and get a REPL that includes Clojure and source files in src/. You can add new source files and immediately invoke them with `clj -X`. You can push that project to github and others can immediately use it from another project using a github url/sha. This is far "easier" than leiningen for getting started. The comparative experience there requires creating a project.clj with a bunch of keys, building a jar, getting an account and keys on clojars to deploy it, etc.

There's lots of other things you can do with clj - these are all additive. At some point, you might (possibly) need a build script. When you do, it's written in Clojure using a pretty straightforward set of functions and you can copy/paste in a starting point. You can grow that build file forever.

Bit bold to assume that the people making these decisions "forgot" anything. Design's about trade-offs.

The claim here is that the thing that makes your language easier to pick up initially nonetheless hobbles it for long-term use - refactoring, adding features. There is a business case for making the latter easy at the expense of the former.

Code can be easy or hard to write and/or change at various levels of complexity, and it's hard to solve for everything when designing a language.

that is completely true and maybe even clojure’s achilles’ heel, but you can’t come here and say they didn’t tell you

Rich can try to redefine the English language all he wants, but he'll find it a lot more difficult than redefining Clojure.

The fact is, the solutions the core team have been putting out for the last several years have been neither simple or easy, and in fact tend towards a weird and arcane complexity in service of problems no one seemed to have.

I remain baffled by Spec, by the clj tool, by deps, and now this. At every step it seems as if the team lives in their own world, and not in ours, and each new tool is as cryptic and convoluted as the last.

They frequently don't even seem to encourage code that is consistently idiomatic to how the rest of us even write Clojure. Who else was even using namespaced keywords for anything until Spec decided to not only use them, but link the entire mechanism to a mutable namespace registry? How is that "functional" in any way?

> and tools.build, tools.deps, tools.cli are aligned with this mission.

No, they are neither simple nor easy. They make new project setup un-necessarily hard, they make builds un-necessarily hard and complicate stuff for both newbies and intermediate programmers. Only experts with tools.* may be comfortable with this and I have seen these experts actually copy sample template `deps.edn` for new projects and use long complicated aliases.

For both simplicity and ease-of-use this should be done by a tool and not a human.

When I recommended some friends to Clojure, they stopped after getting stuck in deps.edn. Clojure setup feels more complicated than C++/Java/Kotlin/Python project setup nowadays.

I wish Clojure would use Rust's Cargo for inspiration.

`cargo new --bin projName` and open the folder in your editor/IDE of your choice.

We migrated from Leiningen to Boot and then to the CLI/deps.edn. Leiningen was too rigid and too much ceremony to write new tasks for. Boot was great from the "writing new tasks" point of view but the fileset abstraction and the pod pooling were both pain points for us. We've been very happy with the CLI and deps.edn and we're already using tools.build at work to streamline our (Clojure) build script.

We have a fairly large codebase (113K lines) in a monorepo with over a dozen artifacts built from about fifty subprojects. Leiningen really wasn't a good fit for us so we're very glad of alternatives.

Thank you for the perspective (and also for clj-new — it feels like it should be built into Clojure’s own tooling).

Now that tools.build is here, I think clj-new can be substantially simplified (copy-dir with text replacement is most of what clj-new does for built-in templates) and when add-libs gets to the main branch of t.d.a or Clojure itself, that takes care of a lot of the rest of what clj-new does.

Maybe related to the removal of dissenter, at least that's one thing https://discourse.mozilla.org/t/the-removal-of-the-dissenter...

Yes, you can turn it off. I keep it on on my home machine as I frequently come across interesting articles. (I’ve never seen any sports articles)