JanisErdmanis

Cool, can’t wait to try that out in a stable release.

What is this magic, how does it differ from PkgImages Julia already has?

I like the idea behind Flatpak and the ability to sandbox applications. What I don't understand is why they chose to lock the build process so tightly to Linux.

I'm currently on macOS, and while I can cross-compile applications, I can't actually bundle them as Flatpaks. For that, I need `flatpak-builder`, which is so deeply coupled to Linux itself that I don't think it can realistically run on other platforms.

Snaps have a similar issue with `snapcraft`. However, you can still build a snap manually with `mksquashfs`, whereas I haven't found an equivalent low-level option for Flatpak. I may be missing something, though, and I'm still looking.

Sometimes I wonder why we don't just treat an installation script like curl https://alx.sh | sh as a universal option for distributing applications. The provenance is there via the HTTPS certificate, and if you're already about to trust an application that can compromise your system, why not trust the installation script as well?

The remaining oil companies will profit tremendously from the high oil prices. I am sure they will have no problem allocating some of those extra profits to sabotage attempts to consider any alternative energy sources.

Depends widely on the target audience. In my case, targeting Julia developers who want to package their applications into installers to reach 100 stars took 2 years - https://peacefounder.org/AppBundler.jl. If I were to target Python developers, I would have many more stars.

This is really funny ;D Gives Tetris vibes and is executed beautifully.

To put it simply if you have a function f(ctx) = ctx.a + ctx.b it is hard to see what are the arguments producing the output. Which are the elements in the datastructure you need to vary in order to have exhaustive tests. Whereas if one refactors it as f(ctx) = g(ctx.a, ctx.b) you only need to test function g with respect to (a, b) whereas forwarding of methods can be simply covered in integration tests without any care whether function g is implemented correctly.

To make such testing strategy to work data structures need to be small. It is better to have multiple small data structures rather than one big universal one where methods are defined at the ctx level making exhaustive tests difficult.

Perhaps, I haven’t been clear. I agree with Pike’s advice strongly. What I am trying to say here is that the Perl’s rule 9 is diametrically opposite of what Pike says.

It’s about coupling and being able to maintain that in the long term. A narrow focus helps to test each individual unit in isolation from each other. It is true that a database appears to be a single datastructure with hundreds of methods from the users perspective and that is fine, because someone else engineered and tested it for you. However if you were to look into how a database is implemented you would get to see the composition of data structures, like btrees that are tested in isolation.

I still firmly believe that one ctx object and hundred functions/methods is as bad as programming with plain variables defined in the global scope. If the ctx is composed from smaller data structures with whom the functions are defined, then all is good. This is the opposite of the rule.

Separation of concerns is still a valid paradigm with a single global datastructure like GUI, Microservice, Database and etc. In such situation one can still seperate concerns via composing the global datastructure from a smaller units and define methods with respect to thoose smaller units. In that way one does not need to wonder whether there are some unattended side effects when calling a function that mutates the state.

One can always look as global variables equivalent to a context object that’s is passed in every function. It’s just a syntactic difference whether one constructs such data structure or uses it implicitly via globals.

What I am getting at is that when one has such gigantic data structure there is no separation of concerns.

With 100 functions and one datastructure it is almost as programming with a global variables where new instance is equivalent to a new process. Doesn’t seem like a good rule to follow.

Yes, energy dissipates. Although one still needs to look out for the distance from the neighbours as your ground can be different from your neighbours ground potential.

Yes, that puts it down perfectly. That’s why some don’t ever see the benefit of installing their surge protector whereas others install one way too small for their situation and find them useless anyway.

If your close neighbours have surge protectors then you benefit little from installing your own.

> Another reason ignoring the literature can be helpful is that sometimes a bunch of work tries to solve some problem, and so everyone assumes it must be hard---just because no one has solved it yet, even though no one has really tried a fundamentally different approach

How does one approach collaborators in this situation? Like, hey, I have this idea that solves the problem you have been trying to solve in a fundamentally different way that invalidates all the legacy approaches you have invested in, BTW. My emails that follow this spirit tend to get ghosted.

This is unlikelly because Iranian regime is going to execute false flag operations against their people to steer public opinion in their favour.

As long as someone else does the porting and maintains the compatability between both subecosystems of thoose who prefer using Jax and thoose who prefer depending on the NumPy. Also not having zero overhead structs that one can in an array handicaps types of performance codes one can write.

A significant obstacle to adoption is that cryptographic research aims for a perfect system that overshadows simpler, less private approaches. For instance, it does not seem that one should really need unlinkability across sessions. If that's the case, a simple range proof for a commitment encoding the birth year is sufficient to prove eligibility for age, where the commitment is static and signed by a trusted third party to actually encode the correct year.

> It took me days to get that build to work; doing this compilation once in CI so you don't have to do it on every machine is trickier than it sounds in Julia

You may be interested in looking into AppBundler. Apart from the full application packaging it also offers ability to make Julia image bundles. While offering sysimage compilation option it also enables to bundle an application via compiled pkgimages which requires less RAM and is much faster to compile.

Such tedious derivations used to be a work of poor PhD students who were instrumentalized for such tasks. I envy those who do PhDs in theoretical physics in the age of AI, people can learn so much about their field quicker via chat than reading obstructing papers.

In essence liquid democracy makes votes a transferable currency bringing it fairly close to what money already is. It would be really hard to prevent existence of an exchange rate between money and vote transfer making that a capitalist dream (until markets themselves gets monopolized).

This is the best way to look on this. Furthermore these surveys are susceptible to bias introduced by the varying degrees of participant engagement. One application I could see for such tools is distill some of participant generated proposals that could be rectified in a further surveys or referenda.

Tangentially, does anyone use a stamping device to put dates in their notebook? I am looking for something that sets the date and, preferably, the time automatically so that I have less friction keeping my notebook timestamped.

Isn’t it still possible for the voter to not cast this ballot paper and bring it to the coercer who waits outside? Then the coercer fill this ballot and ask the next voter to cast it and bring back a blank ballot paper?

The definition is fine. It covers paper ballot security requirement where one shall not get any receipt at all.

It seems you mean something simailar to Selene voting system where a tally board is published containing tracker vote pairs. Each voter can decrypt their tracker once the voting phase closes to check the vote and also means to fake the decryption for claiming another other tracker from the tally board as yours.

> This can easily solved be done via letting people forge receipts. Then anyone can forge a vote to give to someone offering to buy them.

This is the literal definition of receipt freeness. It’s hard to ensure that the receipt you receive to verify your vote had not already been forged by the malware.

> It’s difficult to make an E2E-VIV checking app that’s both trustworthy and receipt-free. The best solutions known allow checking only of votes that will be discarded, and casting of votes that haven’t been checked; this is highly counterintuitive for most voters!

Actually, Benaloh's challenge also does not offer receipt freeness. The adversarial strategy in such a model is to outsource the challenger itself in a hash function which decides whether to accept or discard the vote. It may look impractical at first, but one can build an app that could do that efficiently.

It can be said that all existing end-to-end verifiable remote e-voting systems compromise individual verifiability when reconciling it with receipt-freeness by introducing an assumption about the hardware-based protection of voters' secrets. If they leak or are predetermined by a corrupt vendor implementation, the malware on the voter's client can manipulate the vote at submission, and the adversary later fakes verification for the voter by exploiting that knowledge.

Still, I believe it's a solvable problem which needs more attention. Bingo evoting system is almost there, for instance, with verifiably random generated trackers, but needs a voting booth with a Bingo machine taken at home.