42jd

Scratch was how I got started in programming back in elementary school. It was taught in our computer classes. Everything this article says is spot on, the social aspect is amazing. I made a few programs and got comments on it and stars which hooked me. Side note hearing griffpatch is still around amazes me, I remember playing his scratch programs and wishing I could eventually do that. What’s amazing is it’s all still around and runs![1]

1. https://scratch.mit.edu/users/miniman520/

The robotaxi’s draw will be its lower prices. They are removing the cost of a driver from the equation. Assuming the car felt as safe as a normal taxi, I’d take the cheaper one.

I’ve had this research paper on my reading list for a while (but haven’t gotten to reading the full thing)[1]. Not necessarily just a file system but It lays out an entire operating system backed by a database and OS state interactions are done through SQL.

1. https://vldb.org/pvldb/vol15/p21-skiadopoulos.pdf

I’m not sure how one could enable others to contribute easily but just making the code open source as is would be interesting. Those with a passing interest in search engines can browse the code of a capable engine and pick up some knowledge. While those who really want to help out will find a way to run it and contribute (in the process helping document and maybe making it easier).

My philosophy to open source is just do my personal projects in the open even if it’s not “accessible” and if someone comes along and likes it they can contribute or fork it and modify to their liking. Or they might just browse the code and pick up something in passing.

Ah that’s cool didn’t realize how old it was. The content seems to have held up well. Showed up in google when researching NAT and imo it’s up there with Tailscale’s article in terms of how well it’s written with the drawings.

What’s powerful about nix is the language IMO. I was able to build an automatic WireGuard setup[1] with tagging that automatically works on each new machine thanks to the ability to do config as code. Just provide some basic config for each machine and the code turns it into an interface with peers. The issue to me isn’t the language persay (it’s really a tiny surface area language, see the built in/lib functions [2]) but the tooling built around packaging is a hodgepodge mess of semi-documented workarounds (with Nixpkgs blessed ways vs user libraries) and is extremely difficult to approach and understand.

[1]: https://github.com/jordanisaacs/dotfiles

[2]: https://teu5us.github.io/nix-lib.html

Here are my two favorite (bookmarked) links for packaging and developing for rust. The trick is keep packaging and rust development separate and use specific dev environment flakes. So for dev work just bring cargo and rust as the nativeBuildInputs in mkShell (and any non rust dependencies) and then use standard cargo for development. But for packaging use one of the fancy tools. 1. https://srid.ca/rust-nix

2. https://discourse.nixos.org/t/cargo2nix-dramatically-simpler...

It’s a really commonly used among gen z. It’s used to mean it’s really good/one of the best. Eg these tacos are goated.

Wintergatan is doing a lot of live design/cad sessions the past few weeks on his “wintergatan live” channel which might be useful or interesting

Any password manager worth their salt has a white paper with their security design. Here is Bitwarden’s: https://bitwarden.com/images/resources/security-white-paper-...

Back in middle school we went on a trip and saw them doing the deconstruction of the elwha dam. They were around halfway done. We stood on the banks and saw the process of the reservoir turning back into a river. There was around 50 feet of sediment with old flooded trees sticking out. It is hard to overstate the effects these dams have on nature. Seeing the photos of the elwha coming back to life is always awesome :)

I’m not sure I follow. Is your issue with Wayland that it’s not like x11 with a separate server and window manager? Someone can come along and write that in the future if that’s your preference.

As Wayland is just a protocol itself, the client doesn’t care how it’s implemented. Thus I see Wayland providing the extreme flexibility to implement its protocols how you see fit. Right now wlroots makes it easiest but if in a few years another implementation proves to be better, all those client programs aren’t going to stop working. For now the scene graph allows a whole bunch of compositors/window managers to be easily written that replace x11 ones. And better designs can be further iterated.

Seems the strategy is to eliminate as many numbers/operators before you attempt to guess. Was able to get it in 4 as by the second row I had the set of values to work with.

The missing compositor issue will change a lot I believe very soon. Wlroots[1] just recently landed their scene graph api which enables building wayland compositors with full damage tracking support without needing to touch some of the low level stuff like rendering and buffer management. For example I am currently working on my own wayland compositor and it is super easy to use. Really excited for the future! [1]: https://gitlab.freedesktop.org/wlroots/wlroots

I use bemenu (https://github.com/Cloudef/bemenu) as my replacement for dmenu.

I wrote a blog post on NixOS/home manager configurations with nix flakes. I make sure to link out to other resources for those who don’t have the whole background. See: https://jdisaacs.com/blog/nixos-config/

100% this. The language is designed for its use case which is packaging and configuration (nothing more or less). It has a learning curve due to being lazy and functional but works great once you get the hang of it. But the documentation of all its functions is so annoying. You have builtins and the nixpkgs functions[1]. There is learning the language, and then learning how to use it. Then there is the entire ecosystem of custom packaging functions that have their own pros/cons [2]. The issue isn’t with the language but the difficulty with trying to make existing tooling work the Nix way. That part is where I agree with the curse of nix. But the effort is worth it because once the packaging is complete it just works (forever).

1: Best resource I’ve found is this: https://teu5us.github.io/nix-lib.html

2: The status of lang2nix: https://discourse.nixos.org/t/status-of-lang2nix-approaches/...

As a heads up they fixed the intel xe graphics sandboxing issue in firefox 96. See https://bugzilla.mozilla.org/show_bug.cgi?id=1698778 It works great on my Framework with NixOS. My about:config settings (taken from my home-manager):

graphics = { "media.ffmpeg.vaapi.enabled" = true; "media.rdd-ffmpeg.enabled" = true; "media.navigator.medidataencoder_vpx_enabled" = true; };

It's open sourced! The github repository: https://github.com/allenai/macaw