paulgdp

Sorry for the late question, I'm very interested in your experience with FoundationDB.

In just one sentence or two, how would you describe it?

> Yep, police can simply ask anyone for their passwords and if you don't give it up they can put you in jail.

This is precisely the reason why I don't want to visit the US at the moment.

The USA immigration officers can ask me to forfeit my phone's password and look at all my photos, documents, messages, call logs etc, WITHOUT SUSPICION.

Some of that data can even stay on their servers for decades, and who knows if it ends up on a CIA/NSA server.

Of course, I can always refuse, but non-cooperation with CBP means immediate denial of entry and risks of lifelong headaches with future immigration checks.

The name, the logo, the values and many important strategic decisions seems to have already been decided, before a public channel of communication has been created.

Was this created by just you, or is there already a team?

As much as I think they overreacted when banning you, it also feels like an overreaction to fork that soon.

I hope a compromise will be found, and that you'll be back on NixOS as soon as possible!

Yeah, automation in Nixpkgs is crazy and goes far beyond any other distros (that I know of).

Why spend manual time when it can be automated?

> Is nixpkgs really a monorepo as usually discussed? It's got packages, os modules, and some supporting scripts. Nix itself lives in a different place, so does the RFC planning, system artwork and a few other things. I would expect it all together to become a monorepo.

I think we can say it's a monorepo of packages in this context. Not everything from the Nix ecosystem is there. It could also bundle the website, wiki, doc etc but I don't think it matter too much.

> Debian has ~1.5k contributors, nixpkgs lists >3.5k maintainers. (Although that list is not pruned over time)

Thanks for the info, I heard that a long time ago and never checked myself! It's probably less as you say but still probably bigger than Debian.

I guess it makes sense because it's so much easier to contribute there than to Debian.

NixOS uses a monorepo and I think everyone loves it.

I love being able to easily grep through all the packages source code, and there's regularly PRs that harmonizes conventions across many packages.

Nixpkgs doesn't include the packaged software source code, so it's a lot more practical than what Debian is doing.

Creating a whole distribution often requires changes synchronized across many packages, so it really makes things simpler.

https://github.com/NixOS/nixpkgs

I think it's important to add that they both have the biggest number of packaged software and the most up-to-date software of all distributions even though they have far fewer maintainers than Debian.

https://repology.org/repositories/graphs

But you can use `envfs` to "restore" that compatibility ;)

Or something heavier like `steam-run`

I allocate all my SSD space to one ZFS pool and then:

- I can easily create new subvolumes (filesystems or block devices), for different mount points, containers, other distributions, VM disks...

- The free space is shared between all of them, no need to anticipate a partitioning layout

- I have a service that automatically snapshots some of them, others not

- I love the ZFS tools, I'm very happy to use them on all my machines

- I use NixOS everywhere and so it's also easier to share the same conf on all my machines

- I can send volumes easily from one machine to the other (zfs send)

I probably miss other things, but I also love consistency ;)

I have been using ZFS as root FS since the first release of ZFS on Linux (2013) on all my machines (laptops, NAS, server) and I can't imagine going back.

Why shouldn't it be a valid opinion to not like cryptocurrencies?

And to not want to contribute?

Why is not ok to prefer money regulated by the rule of law?

Moreover, I have no idea how I could help with the problem of recovering stolen cryptocurrency/NFTs or lost private keys.

How is it different from using Clang's CFI (control flow integrity)?

I thought this was the same technique used in webassembly.

Chromium is using this too i think

To be fair, when sending a Pixel for reparations, Google very clearly and explicitly asks to factory_reset the phone.

I personally didn't reset it when I sent my Pixel 3 to fix the charging port because my Pixel was fully encrypted.

All Pixels are encrypted by default as long as you have any kind of lock method enabled (PIN, password, shape...).

I don't really understand how this person got his files in cleartext and accessible.

"Any optimization you could do in Rust is probably easier in C++"

I think this feeling comes from the fact that it takes longer to learn the basics of Rust compared to C++.

However, once one has learned C++ or Rust to a reasonable level, I would argue that Rust is actually easier to use.

This is not the same thing but many people make this claim.

Having read a great deal from him, I just want to confirm everything said about Andrew Gallant, and I absolutely trust him too!

This blog post is a great testament to his human skills: https://blog.burntsushi.net/foss/

You might be interested in reading this more serious study:

https://elifesciences.org/articles/62878

Article summarizing it:

https://www.forbes.com/sites/amandasiebert/2021/03/03/larges...

I haven't tried it yet, but Ego [1] feels like an imperfect but good enough solution to run your dev environment.

[1] https://github.com/intgr/ego

Here's a nice Twitter thread explaining how this works:

https://twitter.com/bert_hu_bert/status/1444018619059429377

I'm personally very enthusiastic about the security model of Fuchsia:

https://fuchsia.dev/fuchsia-src/concepts/principles/secure

https://www.youtube.com/watch?v=gIT1ISCioDY

I've never received such an email, but I recently moved to many different countries (many months each), how can I check to which country my account is attached to?

Does someone knows why this tweet was previously flagged on HN?

see: https://twitter.com/Pinboard/status/1399094306221166592

Your result is very surprising probably because you benchmarked on the very small example corpus whereas other languages were benchmarked on a much much bigger corpus

I guess "prescription" refers directly to your first definition but can also refer to the two other ones by metonymy [0].

[0] https://en.wikipedia.org/wiki/Metonymy

Encryption for DRM needs to happen only once per media, and then can be saved to storage and shared infinitely many times. So that's probably something else

I'm surprised that this article is not even mentioning one NewSQL DB like:

- Google Spanner

- CockroachDB

- TiDB

- YugabyteDB

- FaunaDB

Can it be that those are so little known by most developers?

A (kind of) decentralized and secure voting platform:

- distributed as a PWA(written in Rust, client and server side)

- the authenticity of voters is certified by the voters themselves validating/signing their contacts profiles (by scanning a QR-code). Similarly to the PGP web of trust.

- most of the voters data (included their private signing key) is encrypted client-side and then optionally stored on the server

- moderation policies is to be defined but would ideally by done organically by the users themselves

- the recommenced voting system to use would be by majority judgement [0]

- open source, open government model, non-profit

0: https://en.wikipedia.org/wiki/Majority_judgment

For people interested in this subject, this recent HN post might be also relevant:

https://news.ycombinator.com/item?id=25253070

My interpretation is that the end goal seems similar, but this project starts with the Rust language instead.

Rust without the use of unsafe code is considered by most to be a safe language but nonetheless, it's still useful to fuzz it to find logic bugs (like assert failures) or anything that triggers a panic (like out of bound array access or integer overflow).

More info: https://github.com/rust-fuzz

Disclaimer: I am the author of the rust fuzzer honggfuzz-rs.

Also, for a toy rust project, I wrote an implementation of a copy-on-write B+tree and I used a fuzzer (honggfuzz) to generate automatically all the test cases.

Ii was insanely effective, there were so much more edge cases than I thought. The fuzzer found all of them and got me a 100% code coverage in no time.

All I had to write as test code was a function mapping an array of random data to a series of btree instructions, apply those to both my implementation and a reference and then check that the two structures had the same data.

The Rust ecosystem has a team that tries to fuzz as many crates (rust packages) as possible [1].

Unlike C/C++ and like Python, fuzzing Rust code is not really about finding memory bugs but more about finding logical errors [2].

To do this, a project has been set up with 83 (so far) targets fuzzing the public API of 48 (so far) important crates [3].

All those targets can be fuzzed using any of the three major native code feedback-based fuzzers (AFL, LibFuzzer, and Honggfuzz).

[1] https://github.com/rust-fuzz/targets

[2] see the trophy case: https://github.com/rust-fuzz/trophy-case

[3] https://github.com/rust-fuzz/targets/blob/master/common/src/...

Disclaimer: I'm a member of this team and the author of the honggfuzz crate that makes honggfuzz work with Rust code.