This page is not created by, affiliated with, or supported by Slack Technologies, Inc.
- # announcements (1)
- # beginners (179)
- # boot (8)
- # calva (3)
- # cider (4)
- # clara (3)
- # cljdoc (31)
- # clojure (9)
- # clojure-austin (1)
- # clojure-chicago (5)
- # clojure-dev (19)
- # clojure-nl (2)
- # clojure-uk (1)
- # clojurescript (13)
- # core-matrix (1)
- # cursive (86)
- # datascript (2)
- # datomic (13)
- # emacs (3)
- # figwheel-main (1)
- # fulcro (66)
- # off-topic (250)
- # pathom (7)
- # re-frame (19)
- # reitit (5)
- # sql (37)
- # uncomplicate (5)
Hello, I have a small improvement idea and would like to discuss it to see if it is interesting for the Clojure language: the “Unquote Conditional”
~? which adds the value of the following expression if it is not nil, and adds nothing otherwise.
~?expr, users have to do something like
[email protected](when-let [e expr] [e]).
… maybe it would need to use another character, as
? is valid as the first character of a symbol.
I’ll almost promise that this is the last time I’ll bring up the clojure.set thing, but I’d like to flog the dead horse one last time. The argument goes that Clojure is correct for correct programs, and by this, passing non-sets to the set functions is deemed as an incorrect program, as is (as discussed above) using - as a comparator. If these programs threw an exception (as does using str as a comparator), I wouldn’t have a problem with this line of reasoning, but I do find it very scary that such incorrect programs are allowed to run and produce seemingly correct outputs.
The other consideration is performance: adding a runtime type check on set functions adds a cost that all programs have to pay, even correct ones (which already pass sets).
I'm wondering - With the Spectre attack being the product of speculative execution, are Clojure's speculative/optimistic concurrency features also vulnerable to such timing attacks? If supposing someone tried to use STM in a multi-tenant environment? Or any other concurrency primitives that retry? I'd assume you probably can't get a high enough timer resolution on retries to do the same thing in Clojure.
Spectre is much more insidious and pervasive than STM / atoms. It does not need retry / concurrency features
And I understand that the "speculative execution" being talked about in Spectre is a fairly different thing than what is in Clojure. Just wondering if there's in any spiritual similarity there.
I guess part of the Spectre exploit depends on cache misses, which aren't really part of the picture wrt Clojure's retries.
Spectre is also scary because untrusted code can read memory out of unrelated processes. If you’re executing potentially hostile code inside the JVM, you have no security guarantees
I don't know the details of the existing software changes made to help protect against Spectre, unfortunately, to give a summary of what they do, but if you really want to protect against Spectre, do not run your process on the same physical CPU core as other code you do not trust.