Tobu

Progress is fast (much better than when Vélib was launched in 2007), most arrondissements (except maybe 15th/16th) are convenient to get around, the center has some huge lanes that bode well for the future, and there's roadwork at just about every large intersection that hasn't been upgraded yet.

https://www.youtube.com/watch?v=sI-1YNAmWlk

I don't see anything available yet and the announcement is light on details. Hopefully there'll be something concrete before the end of their infrastructure week?

Rust's type system is enough to get rid of memory safety and UB, but it does that by enforcing more invariants, invariants which you also use to encode properties you care about. 70% percent of vulnerabilities are memory unsafety which is impossible in safe Rust etc etc, but a better type system, a language that doesn't disclaim commonly found code as unsupported, more productive errors, lower cognitive load… also tends to help with the rest of the bugs.

To add to your point, following Woodruff's "Weird architectures weren't supported to begin with", Robert O'Callahan pointed out[1] that for one definition of the open-source platform (looking at the requirements of Linux distributions), a new architecture would need to support at least: LLVM and GCC targets, a port of the Linux kernel, a V8 backend, and acceleration for various codecs.

And while at this point a platform needs to have support from both compilers, I can see the GCC/glibc ecosystem being made redundant; LLVM is more adaptable and has found its way into so many specialized compiler stacks.

[1]: https://lwn.net/Articles/847830/

By the way, I appreciate the support for short-term certificates as well; Letsencrypt doesn't have it, though invalidation can be detected with OCSP or draft-aaron-acme-ari.

Any status for RFC 8657, ACME CAA support? This is for restricting which account and which validation methods may issue certificates. The CPS says they may use it, which is too vague and I'm not going to test it right now.

https://www.rfc-editor.org/rfc/rfc8657.html

https://pki.goog/repo/cps/4.7/GTS-CPS.pdf

A port forwarding utility like rathole/tunnelto (tobaru/frp…) seems simpler than the proposed WireGuard setup.

ART — Another RawTherapee — could be addressing this, with recent releases: https://bitbucket.org/agriggio/art

If you need to translate between Unix time and UTC (or something geodesic like UT1), you'll be at most one second off. The difference due to leap seconds only accumulates if you need to translate something civil or geodesic (UTC, UT1, Unix time) to TAI.

Fixed hours are convenient in that they allow you to reject non-work demands over work time or work demands over non-work time.

Indeed, first result and no error checking:

https://gobyexample.com/hello-world

Indeed! This followup used sample code from the Rosetta Code wiki:

https://haslab.github.io/SAFER/scp21.pdf

The rankings move a little bit, but the relative positions of Go and Rust don't.

Wind River seems like it did okay. Bought for $884 million and sold for $4.3 billion.

https://en.wikipedia.org/wiki/Wind_River_Systems

The compiler itself is fine and its performance well managed, with weekly perf triage and efforts driven by profiling[1], but because adding dependencies is effortless and vetting them isn't, dependency trees tend to get large if not careful. In particular, widely used proc-macros (code transformations pulled by popular packages like serde, clap, tokio…) add very heavy dependencies (like syn) to the critical path. As a consequence, downloading and installing a tool from source is often a poor experience.

As far as development experience, cargo clippy / cargo check / rust-analyzer give you the feedback you need without involving codegen (except for any proc-macros in your dependency tree), and incremental compilation makes codegen faster after the first build. Work is also ongoing[2] to make debug-quality codegen faster.

Here is a quality article on the art of keeping a Rust project fast to build: https://matklad.github.io/2021/09/04/fast-rust-builds.html

The overall series on organizing a large project is worth reading as well: https://matklad.github.io/2021/09/05/Rust100k.html

[1]: https://nnethercote.github.io/2021/11/12/the-rust-compiler-h...

[2]: https://bjorn3.github.io/

Boutique carrying the finest petroleum and other refined goods:

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

(Shot during another wave of rising gas prices)

Content decryption module: https://en.wikipedia.org/wiki/Encrypted_Media_Extensions

A component that decrypts streams locally, which DRM makers intend will be restricted enough to not leak the keys it uses.

You clearly misunderstood the link you gave about Java support if you think it's relevant to how the kernel is implemented.

The kernel has extensible support for execve-ing files the kernel doesn't directly understand as binaries by forwarding them to another program that behaves as an interpreter, the binfmt-misc machinery. The docs you linked just give an example of configuring that for various types of Java files.

If anyone had trouble parsing rustccggcc, it's rustc-cg-gcc, ie https://github.com/rust-lang/rustc_codegen_gcc

NaCL (native client) sort of did this, but through an entirely separate toolchain. It's not an easy task.

And I see the safe languages section[1] in the WasmBoxC post; that looks like it would address most of the remaining UB risk, but Firefox will take some time getting there.

[1]: https://kripken.github.io/blog/wasm/2020/07/27/wasmboxc.html...

The host application is still C, and the final compilation of the mix of C and sanitized C still relies on the optimizer to be fast, so it might be possible for the untrusted library to reveal UB in the rest of the application. I can see how the whole approach (wasm + taint) would make compromise of the sanitized bits through crafted data harder, but I'm not sure it does enough for guarding against a supply chain compromise of the library.

The README[1] is enough to understand, this is a really funky implementation and does nothing to bring useful functionality into the kernel.

It relies on TokuDB, which is a database server meant for userland, already a complex piece of code, patent-encumbered, probably well tweaked but heavy. It does not port that to the kernel, rather it reimplements userland interfaces in-kernel. For example, the file-based interfaces TokuDB expects are proxied to files in a different filesystem.

B_epsilon trees are a useful data structure, they may have a place in filesystems, but it will take a from scratch implementation to prove it. Repackaging TokuDB's patented fractal trees with extra duct tape does not address any needs outside of superficial marketing.

[1]: https://github.com/oscarlab/betrfs/blob/master/README.md

Scrubbing would be fun, I agree!

The clever idea that makes manyclangs compress well is to store object files before they are linked, with each function and each variable in its own elf section so that changes are mostly local; addresses will indirect through sections and a change to one item won't cascade into moving every address.

I'm not sure the linking step they provide is deterministic/hermetic, if it is that would prove a decent way to compress the final binaries while shaving most of the compilation time. Maybe the manyclangs repo could store hashes of the linked binaries if so?

I'm not seeing any particular tricks done in elfshaker itself to enable this, the packfile system orders objects by size as a heuristic for grouping similar objects together and compresses everything (using zstd and parallel streams for, well, parallelism). Sorting by size seems to be part of the Git heuristic for delta packing: https://git-scm.com/docs/pack-heuristics

I'd like to see a comparison with Git and others listed here (same unlinked clang artifacts, compare packing and access): https://github.com/elfshaker/elfshaker/discussions/58#discus...

Shades of https://arstechnica.com/gadgets/2021/05/freenode-irc-has-bee...

Remember when Microsoft launched a chat bot?

https://arstechnica.com/information-technology/2016/03/tay-t...

I'm not sure where the confusion is coming from.

If userspace wants to distinguish files, it normally does so with a (ino_t, dev_t) pair. With some nuance wrt inode generations if you aren't holding on to files yet want to guard against ino reuse, and some funkyness with overlayfs.

Most filesystems don't expose a way to access files by ino only, so the internal implementation generally doesn't key anything by them or rely on them itself; they're just a kind of of uniqueness cookie. But keying by them somewhere in the kernel implementation is feasible, if you scope it properly.

Interestingly, in another decision, that did go as high as the Cour de Cassation, Microsoft did get a license violation treated as counterfeiting, with higher monetary damages.

  - https://www.legalis.net/jurisprudences/cour-de-cassation-ch-criminelle-arret-du-19-avril-2017/
  - https://www.legalis.net/actualite/contrefacon-de-windows-confirmation-du-mode-de-calcul-de-la-reparation/

Found via https://linuxfr.org/users/spacefox/journaux/une-violation-de...

More here on the Entr'ouvert vs Orange case:

  - https://www.legalis.net/jurisprudences/cour-dappel-de-paris-pole-5-ch-2-arret-du-19-mars-2021/
  - https://www.legalis.net/actualite/pas-daction-en-contrefacon-pour-le-non-respect-dune-licence-de-logiciel/
  - https://www.legalis.net/jurisprudences/tgi-de-paris-3eme-ch-3eme-section-jugement-du-21-juin-2019/
  - https://www.legalis.net/actualite/non-respect-dune-licence-libre-irrecevabilite-de-laction-en-contrefacon/

They seem to conflate YouTube and YouTube music, as well.

(See here for a status update, kind of)

https://community.letsencrypt.org/t/rfc-8657-caa-extension-i...