For context, Michael Osterholm runs the Center for Infectious Disease Reasearch and Policy at the University of Minnesota and was a member of Biden’s COVID advisory board during the presidential transition.
> M4 syntax looks that way because it has to work for arbitrary text files.
That seems like an odd assertion given the existence of other templating systems which have friendlier syntax while being capable of generating arbitrary output. Is there a reason why you think on the M4 approach is valid?
Most templating systems work in combination with an external program written in a high-level language, e.g. Ruby for Liquid or Python for jinja2. m4 does not.
And m4 works in combination with a bunch of C code. Virtually any system with m4 can come with an interpreter for a higher level language without running out of space (I can't imagine many uses for m4 at runtime on systems where, say, a perl interpreter wouldn't fit). Why is relying on such a runtime a problem?
What does “autonomous” mean? There are a ton of template engines that don’t depend on a parent framework, there is no reason you can’t implement all features in C.
Jinja2 is an API and it needs a Python program to determine the values for the substitution variable and invoke the template engine. In contrast the M4 executable is the engine.
Younger, poorer me would not hesitate to pirate a game if that meant it’d be free. I do not blame a company for trying to protect their investment. I’d do that, too, if I was dropping 10s of millions of USD into developing a game.
> I do not blame a company for trying to protect their investment.
I don't really blame them for wanting to prevent piracy, but I absolutely blame them for implementing it in a way that degrades the game only for paying customers.
The absurd point here (and in many other cases) is that paying customers get a worse experience than those who pirate.
For some games I've paid for a game but then still pirated it because the pirated copy removed things like unwanted software (uplay, etc.) or allowed me to play offline in a single player game.
I just want to pay for a game but still get a reasonable experience so for me paying and pirating can make sense.
1. Paying customers get worse experience than pirates.
2. Your software lifespan is reduced. (Worst if you use 3rd party DRM).
3. The company pay for something that 99% of the time doesn't work.
> literally all broken DRM like this does is punish paying customers
That's clearly not true here. The game in TFA went ~two months without being cracked - that's what the DRM was there for.
> if you don’t want me to pirate your game - don’t use DRM
This is such a weird sentiment to see on a place like HN. Do you ignore the terms of software licenses that you don't like? If not, what's the difference?
I vote with my wallet. I don't support DRM: I don't ever buy anything with DRM. I go out of my way to buy DRM-free stuff. (sometimes I buy a couple of copies)
By the same logic a broken lock on a store's door does literally nothing except prevent customers from entering the store to buy stuff. Sure, but this is just a risk of having security. The solution is to fix the problem, not discard locks and security.
Also one might argue there are second-order benefits to the paying customers, like lower prices and more products being offered since the seller can make more money.
When someone mentions correlation, they imply a linear relation between the correlated variables and a range of values for which that relation is valid.
Only when that model is further validated correlation suggests causation.
> When someone mentions correlation, they imply a linear relation between the correlated variables and a range of values for which that relation is valid.
Yeah that's what correlation means?
> Only when that model is further validated correlation suggests causation.
No! It suggests causation already. There may not be causation but it definitely suggests it.
For example if I find that eating fast food correlates with BMI then there's a pretty clear suggestion that eating fast food causes increased BMI. It might not be the case! But it's clearly very suggestive.
It's close. I also want something that is going to be syntactically familiar to humble programmers (my target users, myself, etc); Dhall's syntax is clearly Haskell-adjacent which is an obstacle for many of us. I'll probably just roll my own using a Rust-like syntax.
If you don't mind, what is it about the syntax of Dhall that you find hard?
In my experience, Haskell's syntax is much simpler than the syntax of any of the popular languages. The "hard" parts of Haskell come with all the abstractions people make (esp. how it encodes side effects), the laziness, and the language extensions. Dhall has none of those.
It seems to be a very polarizing topic. People who like Haskell's syntax find it very readable, others don't. In my estimation, there are a lot more in the "others" category than in the Haskell category. Whether my target audience has trouble with Haskell syntax because of some inherent property of the syntax or merely because their background isn't in Haskell doesn't ultimately matter--the requirement is that my users can quickly be productive (minimal learning curve, etc).
To be very explicit, I'm dodging the question because it's ultimately subjective and people come out of the woodwork with the same predictable talking points ("syntax doesn't matter", "but it's VERY readable! look how few characters!") and I don't have the energy this morning.
I think you misread, but maybe I should've worded it more clearly: the silly people are those hypothetical people who say that "syntax doesn't matter" and "fewer characters means better syntax".
I frankly think that alternative syntaxes for the same languages ought to be a thing. Case in point: OCaml and Reason.
I can imagine a curly-braced syntax for Dhall (BTW Haskell does have curly-braced syntax when you need it), curly-braced syntax for Python, etc. Indent-based syntax for HTML was implemented (but I forgot the name).
Also, RTL syntax and Arabic / Hebrew keywords for languages have also been implemented; this must be a huge help to those whose native writhing systems are RTL. Try writing your code right-indented and with all expressions backwards.
The syntax seems generally fine (Python's type annotation syntax is shoe-horned to minimize changes to the parser--if you're allowing yourself to rewrite the parser, why not improve the type annotations? Indeed, why not stick to a more Rust-like syntax in general?). I would want the ability to restrict the standard library and builtins (no I/O) a la Lua. Also, if the type system involves a borrow checker, I'll pass (borrow checking is cool but it doesn't make sense in what is ultimately intended to be a configuration language).
I'm open to having another syntax, another parser that produces the same AST. Let the market decide. No borrow checker concepts in the source, but transpiled rust code of course uses the borrow checker.
The python standard library is where I think the strength of this approach lies. Was reading some history on why reddit was rewritten in python (after initially implemented in LISP).
Transpiling python stdlib is a significant task in itself and could use more love.
Having a stdlib is fine, but it’s incompatible with an embedded scripting language where we want to provide and control the APIs that are available to the user. It sounds like you’re building a general purpose application programming language which is fine, but the tradeoffs differ.
Yup, you can setup Haskell with Nix. I'm not too familiar with Haskell, but it looks like Nix even has a collection of Haskell packages (including lens). This looks like it is a good resource for getting started with Nix + Haskell https://notes.srid.ca/haskell-nix, you should be able to follow along in a Nix repl. I recommend forking on of the example repls from the blog post.
I agree with the sentiment. For a project of this magnitude maybe it comes to develop some kind of static analysis along with refactoring the code to make the former possible.
As per the attack surface described in the paper (section IV). Because (III, the acceptance process) is a manpower issue.
It's possible that they are developing a static analysis tool that is designed to find places where vulnerabilities can be inserted without looking suspicious. That's kind of scary.
Have they submitted patches to any projects other than the kernel?
I know a community that held the event after being rejected to ensure that the "processes" where still in place for the future. They are now on the list again (haskell).
I think GNU should do something similar.
Ask HN: what are some OS projects that have a process to recruit help? Should OS projects have a "survival strategy"?
I hope they can survive this.