In short:
1) secure bootup by locking up BIOS and encrypting your drive
2) set User Access Controls to the highest level
3) install up to date browser with appropriate addons (ublock)
I heard a talk from a large cybersecurity company that was using Julia for research and is apparently in the process of dropping Julia due to:
- difficulty in hiring, apparently it was too expensive/difficult to hire Julia programmers,
- poorly performing garbage collector. If I recall correctly, they had issues when trying to process huge amounts of data.
Seems like small teams will not run into these issues at least initially.
I really like Julia and I hope it becomes huge, but stories like this make me wonder whether the whole Julia ecosystem will ever mature to a level of Python for example. And in turn, making it viable for large organizations that might be using e.g. Python + C++ combo that might be easier to hire for/more versatile/with better known drawbacks.
Essentially, I am not sure whether the potential of Julia is that much greater than the realized potential of the incumbents to warrant the "Julia is the language of the future".
My (more or less extensive) experience with Julia has been rather good.
Step 1. Prototyping. Small data, don't care about performance. Julia is as easy as python, but faster. GC doesn't matter.
Step 2. Production. Very large datasets. Performance is very important so I make sure that hot loops don't allocate, and so GC doesn't matter.
Really, I struggle to see how someone can not like this.
Regarding hiring. My experience has been that you can roughly divide people into two categories. Those who like using tools, and those who like solving problems. For the former, a different language might be an issue because they might not know and might not be in the mood for learning it. For the latter, they're happy to learn any tool that can help solve their problem. We want the latter, and for the latter learning Julia hasn't been an issue.
I am not exactly sure what they were working on, but I am not convinced that any code can be made non-allocating easily.
For example, when you are building large trees with complex structures in the nodes and you need to both add/remove the nodes, the effort to make it non-allocating might be too much compared to just using C++ and writing things more naturally?
Please put them in touch with me if possible. RelationalAI has similar GC issues which they are the core Julia developers are working hard to resolve.
I have also seen zero postings for Julia roles in cyber security companies so it is likely that they aren't tapping into the community which is why they can't find people.
I remember a class I had where we were shown a methods for exact PC arithmetic with integers, rationals (e.g., 1/2) and algebraic numbers (e.g., sqrt(2)). Only thing it couldn't deal with were transcendental numbers (e.g., pi)
I think it worked by representing the numbers by integer matrices, all operations were then matrix operations. Unfortunately, the matrices were gaining dimension when new algebraic numbers got involved, so it probably wasn't useful for anything :-).
Anyway, it it blew me away anyway at the time, one of the few things that sticked with me from school.
Yeah there are a few number systems that can do this kind of thing, ranging from rational implementations where the numerator and denominator are stored, all the way to the computable reals (https://en.wikipedia.org/wiki/Computable_number), which can handle even trancendentals exactly! Fun fact, the built-in calculator on android actually uses the computable reals (https://dl.acm.org/doi/abs/10.1145/3385412.3386037), so you can do any calculation on it, and then ask for any number of digits (keep scrolling the result), and it will always be correct. The only downside is that they're a little too slow to use in a lot of performance-sensitive numerical applications.
I really wanted to love syncthing a lot, I loved the idea, the interface, everything. But I would always get a number of errors on some files for whatever reason that I would have to then manually fix and sometimes I couldn't even do that. But it has been a few years, so maybe it's time to try again...
To be clear, in my browser, no article appeared, I only saw a single blinking eye in the middle of the screen. Together with the title in the link, I was appropriately confused/amused.
Regarding uranium extraction in Czechoslovakia, the Soviets later mined uranium in other sites by pumping sulfuric acid into the ground. This has caused a lasting ecological damage which has to be managed to this day.
The acid was meant to dissolve the ore and was then sucked back out. The only issue was that they ended up pumping a more sulfuric acid into the ground than sucking out. This created an underground lake of sulfuric acid in an with other underground water "lakes". This sulfuric lake is threatening to spill into these water sources.
I heard about this from my teachers at the university who were involved in the modelling of the underground spill. Using a limited number of wells, they were supposed to predict how the spill is spreading and what actions to take to stop it.
Kate Crawford is a famous researcher who focuses on social implications and ethics of AI, so kudos to her for being able to get her work into Nature so reliably!
As an aside, that would be a real feat to ONLY publish papers in Nature, I wonder if anyone ever was able to do that.
The linked discussion makes me wonder, how much of our existence on the internet is just an unintended consequence of some minor engineering decision?
Whim of an unknown engineer creating or destroying million dollar industries down the line...
I don't have a strong opinion on this, but a comment in the article lead me to this discussion, which is just wild: https://github.com/ninja-build/ninja/issues/1482
I get a sense that the maintainers hold a similar sentiment as the author of this piece, but it's never expressed, but the frustration feels real.
He calls it a laptop since Framework calls its computers "laptops" and the whole setup is battery powered.