nbpname

From having seen what happened during the development of FirefoxOS (Boot2Gecko), from a developer point of view. My take is that the biggest hurdle are not the development of the core applications, but the approval and certifications from the various partners.

For example, some company did not like the fact that the call stack could be reverse engineered … yet they would not help you build a prototype at the pace of development (and this was back in 2011)

Then once you have a working OS, the second hurdle was to demonstrate a very high number of active users, such that they dare to even consider your new environment as a potential target. This a bootstrap challenge which is hard to achieve. To get traction from App developer implied getting traction from users, which implied having apps the users care about …

While you goal of removing the application layer sounds like a nice way to work-around the bootstrap problem, I fear you will still have it at the API level.

I wish you good luck, and I hope the landscape has changed in the last decade.

I am working on solving Prompt Injection!

I am building a new kind of LLM runner which lets you understand the internal reasoning process, and which can be automated to intercept hallucinations and prompt injections before they cause more damage.

(No public code yet, but I do intend to open source it)

Thanks for caring about this topic as well.

However, asking people to pay first without an established brand nor the ability to audit the code requires a lot of trust. Without any additional judgement about the product, I would never recommend anybody to do that by fear of spyware, phishing or worse …

From the same consideration, I intend to open source my solutions. At the very least offer auditing capabilities to people like me, who are too paranoiac about security and privacy.

On the topic, I do not want to ask the user to always vouch for every usage. My goal is to detect ahead of executing any command, and offer options to re-try automatically, strip the leaking context, abstract the information or accept it. Only asking the user when there is a doubt, while not bothering the user when there is no issue.

Privacy & Security with self-hosted LLMs! You have dreamed of this too?

Today you you can self-host some models, yet this does not mean you can safely browse the web with it, and automate tasks that would interact with your email account, your bank account and your clients.

This is the reason why I left Mozilla, to work full-time on fixing these problems.

Prompt-injection, hallucinations and private information leakage might not be fixable, but they can be identified 100% of the time, deterministically, before any undesirable consequences.

https://cogilibre.com/

The value brought by NixOS is on line 6.

  --config ${config.sops.secrets."rclone.conf".path} \

NixOS let you build the abstraction you want, and mix them with abstractions provided by others, and this single line illustrates this point extremely well as `sops` is not yet part of NixOS.

Secret management would likely come in NixOS in the future, but in the mean time you can add either use https://github.com/Mic92/sops-nix or https://github.com/ryantm/agenix to make it possible to manage files which have content that should not be public.

Other package managers also provide some abstraction over the packages, and would likely see the same systemd configuration abstracted the same way in post-install scripts. Yet, the encrypted file for `rclone.conf` would come as a static path in `/etc`.

You could resume NixOS as having moved the post-install script logic before the installation, yet this tiny detail gives you additional abilities to mix the post-install scripts and assert consistency ahead of making changes to the system.

Grafting is indeed a good solution for fast security updates, except that the way this is implemented in Guix depends on the maintainer of each package. This is indeed better than Nix which relies on asking every user to replace the dependencies.

A few years ago, I made a proposal to have some automatic grafting mechanism: https://github.com/NixOS/nixpkgs/pull/10851

This would automagically work by simply maintaining 2 trees of Nixpkgs, one with the cherry-picked security updates, and one which matches the latest set of cached packages. This way one can fully benefit from the cached packages while having the ability to replaces with the latest security patches they want to import without building the world.

Unfortunately, rewritting Nixpkgs to fit the requirements needed to have the automagic mechanism is a huge project, especially given the activity of Nixpkgs. Maintaining a fork of Nixpkgs which stays up-to-date while changing its inner working cannot be held by a single person.

My hopes would be to push this to the Nixpkgs Architecture Team, while preventing them from doing mistakes by inserting extra complexity while making this work more challenging.

Interesting!

The current design seems to uses 3 transducers at 2.25 MHz with a static phase shifter added on top of the transducers. Then they capture floating / dropping particles which are moving past the design that they want to be printing.

I am currently working on building a similar mechanism as a pet project, inspired by the SonicSurface[1], with the goal of having a dynamic hologram while not requiring a huge computer hidden in the back.

[1] https://www.instructables.com/SonicSurface-Phased-array-for-...

I have similar results when running the code in the Firefox devtools console, however, running these benchmarks in a dedicated webpage does not show the results.

When using a dedicated web page, I see results which are in the same ranges as NodeJS and Chrome: (not comparable, as running on different hardware)

   Started data Local (original) foo.html:120:11
  Finished data locality test run in  8.6800 ± 1.3095  ms. foo.html:144:11
   Started data Non-local (original) foo.html:120:11
  Finished data locality test run in  38.9400 ± 1.6195  ms. foo.html:144:11
   Started data Local foo.html:120:11
  Finished data locality test run in  6.6600 ± 1.1390  ms. foo.html:144:11
   Started data Non-local foo.html:120:11
  Finished data locality test run in  38.6400 ± 1.5861  ms. foo.html:144:11
   Started data Non-local (sorted) foo.html:120:11
  Finished data locality test run in  12.1800 ± 1.8334  ms. foo.html:144:11
   Started data Local (object) foo.html:120:11
  Finished data locality test run in  14.4500 ± 1.1492  ms. foo.html:144:11
   Started data Non-local (object) foo.html:120:11
  Finished data locality test run in  49.0000 ± 1.6576  ms. foo.html:144:11
   Started data Non-local (sorted array of indices) foo.html:120:11
  Finished data locality test run in  53.8500 ± 2.9725  ms.

I opened a bug against the devtools console of Firefox: https://bugzilla.mozilla.org/show_bug.cgi?id=1647276

I am no expert in the front-end of Firefox, but a search highlight files such as "tabbrowser.css" and "tabbrowser.js".

Have fun: https://searchfox.org/mozilla-central/search?q=&case=false&r...

This feature is really cool, however the ratio of parse-time and compile-time improvement is not always meaningful to end users. I would be curious to see the absolute & relative load-time gains.

When I was benchmarking Firefox on the same feature [1], back in November 2017, I noticed that reddit loads very little JavaScript that any improvement on it does not matter.

Also, I wish that the benchmark website domains were not truncated, such as "http://www.", and better distinguish websites such as "http://reddit." (for http://reddit.musicplayer.io) as opposed to "http://www.reddit." (for http://www.reddit.com).

[1] https://blog.mozilla.org/javascript/2017/12/12/javascript-st...

The goal is to optimize the code both at compile-time and at run-time. We need to optimize it at compile time to prevent slow start-up, and we need to optimize it at run-time to benefit from profile guided optimizations.

Both the reference to the GraalVM and a pun are intentional.

It sounds more than likely that HolyJit will use Cretonne as a backend.

For the moment it uses dynasm, just to get the prototype working, but I expect to change that in the upcoming months.

(I am the author of HolyJit)

For both SpiderMonkey and v8, this is counting the number of calls to the MacroAssembler. SpiderMonkey commonly use the prefix "masm", while v8 uses the macro "__ " to alias the MacroAssembler.

The MacroAssembler, is basically what is used to produce assembly code in both JavaScript engines.

Overlays is a way to extend Nixpkgs in a format which can easily be shared, imported and combined. An overlay can add or override packages, like any user could do before with packageOverrides.

An example of overlay is the rust overlay provided in the nixpkgs-mozilla[1] repository, which package all latest versions of the rust compiler[2].

[1] https://github.com/mozilla/nixpkgs-mozilla [2] https://github.com/mozilla/nixpkgs-mozilla/blob/master/rust-...

We have an addon called the "Jit Inspector" [1], which should report the Assembly produced by IonMonkey. Last time I tried it not all panels where functional because it was still making attempts at reporting data from JaegerMonkey, which got removed since.

The lastest solution I have seen so far is what we call the "Jit Coach" [2]. This is a devtools panel under the performance tab which reports if your function sticks in IonMonkey compiled code. Based on the MDN page this is behind a preference in "about:config".

When we compile, we record the hypothesis made by the compiler, and use these to annotate the deoptimization paths which are taken. Each time we jump back to Baseline the tool reports why we jump back to Baseline.

So far, only the front-end of IonMonkey and the deoptimization path are recorded. No other optimization phases are recorded at the moment. Sadly, it does not report the Assembly produced by IonMonkey.

[1] https://addons.mozilla.org/en-US/firefox/addon/jit-inspector...

[2] https://wiki.mozilla.org/DevTools/Performance/JIT