nsm

This is potentially a very attractive replacement for my Pixelbook.

What is the battery life when running Chrome OS?

If I wanted to, could I later put a full Linux or Windows in some sort of dual boot?

A lot of these are FAANG scale problems primarily when it comes to server/backend infrastructure.

For a lot of "embedded" use cases like robotics, where you are trying to squeeze out maximum performance from a single machine (the hardware you have on the robot), POSIX is and will remain a hindrance.

I loved Phabricator and still miss it at the current job. Is there a code “watching” system as good as Herald integrated into GitHub?

Highly recommend reading The Dream Machine by M. Mitchell Waldrop for a really great peak into Licklider and the revolution he brought about

The article is quite skeptical of Quaise: "While it is exciting to see the interest in geothermal, much of the effort leaves me skeptical.

Quaise is staffed heavily by former Schlumberger employees. Schlumberger is known for being too expensive and impractical in many of its business units for shale. It is on-brand that they are building a laser-like drilling technology! Quaise deserves credit for correctly identifying the challenges in geothermal economics and pursuing a path with a greater than zero chance of success. But many of their assumptions are off base. The large, bureaucratic companies you work with at Schlumberger often do things like limit trip speed to 500'/hr. One time tripping fast caused a blowout by swabbing the hole, so no rig contracted by the company can trip fast even if the blowout risk is low. Smaller companies are ripping out of the hole at 4000'/hr. Tripping in granite is like tripping in a cased hole. Most companies will push the speed to the physical limits of the crew and rig. And even at 50,000' depths, on-bottom drilling will dominate total time (assuming a high-temperature motor is available). Both PDC bits and motors suffer from the vibration drilling in hard rock causes. There is a decent chance that PDC and elastomer-free motor assemblies will see longer runs at deep depths because the rock is more ductile."

I have no background in energy at all, so I'm not qualified to comment on this at all. Just leaving it here as a counterpoint to the original article.

As an example of documentation at the same or better standard, also look at Racket. I'd say the python ecosystem is also really getting better at this in the past few years.

This is a good article. It covers a bunch of "ecosystem" stuff.

At the same time I'd generally encourage a lot of developers using plain editors and modern, but not widely used languages, to give IDEs and common languages a try. That addresses the "iteration" experience.

Modern IDEs for java, C++, C# area huge step up from whatever cobbled together setup one is likely using in neovim (saying as something who mainly used vim till about 2 years ago).

VCS integration, build integration, debugging facilities, refactoring, linting etc. are just amazing. Jetbrains IdeaVIM is also really good at getting a fast editing experience. At this point, as soon as I'm beyond a small script, it is worth it to open the project in an IDE.

We still aren't at the smalltalk or lisp machine level in certain aspects, but that is more a limitation of our larger computing platforms.

Browser password managers are probably fine for most users, but 1password is really good for specific use cases 1password works across multiple OSes, works in other browsers, allows saving much more than just passwords (ssh key management, API credentials). The ability to securely share passwords with time limited links is a big draw for me to use the subscription model. 1p cli is also seriously useful.

Also for those who are not aware, if your company uses 1p business, you get one FREE personal family account for every business user.

I've found "Challenges Using Linux as a Real-Time Operating System" by Michael M. Madden from NASA a really big help - https://ntrs.nasa.gov/api/citations/20200002390/downloads/20....

It is indeed possible that there is a philosophical gulf. However, it is also possible that engineers who dislike Bazel (and love things like Make and CMake) haven't worked in large, multi-language organizations. I'm not aware of the author's history, so I don't want to imply they haven't, I'm saying generally. Bazel is a tool that exists to solve specific problems. And it (and clones) does that miles better than any tool out there.

1. Caching, while maintaining hermeticity and correct dependency tracking.

2. Remote execution - yes, contrary to the author's general focus on small, specialized, C (or similar) tools, products out there have to deal with thousands of dependencies that take forever to build and are nice to offload to a beefy server. They also need to support several different devices and architectures.

3. Actually being able to run tests, use the same caching mechanism on tests, surface those results to CI.

4. Being able to plug in arbitrary languages into the build system, with a sane (subset of Python) DSL to write rules in. Because not every project is written in C/C++, or in a single language.

5. Having very clear separation of build phases so you can't shoot yourself in the foot.

6. A lot of hooks to provide better integration with CI, as well as to collect profiling info from your end users, so you can actually make life better for your engineering org as a member of the developer tools/infrastructure team.

In general, my gripe with Bazel complainers is there is a loud community of them on the Internet whose primary software engineering experience is either in languages that build fast, projects that are small and with few dependencies, or just have a small number of people.

There is a world of software out there beyond the Web and C UNIX utilities. Try doing any high end computer vision, robotics or HPC work and you've to deal with a bunch of dependencies trying to solve very complicated problems. One can discuss whether some of those dependencies are well designed or not, but at the end of the day they are very good at their job and don't have much competition.

Bazel solves a lot of problems for a lot of these people, so calling it "questionable" is quite ignorant.

Building something like this to work with existing code in compiled languages is REALLY HARD. However, take a look at rr and Pernos.co.

Both LISP and Smalltalk were entirely based around having this kind of hands-on, interactive, full development environment available not in prod as well. In some sense what you are doing was the future people thought we would have, and it is a regression in some aspects that most production software runs in this bare bones system where someone can't stop it at an arbitrary point, and then have all the tools originally used to create that software available to them to observe the system.

I’m curious. Why not create a new google account that is not used for anything but Tailscale and use that?

I actually attempted some of 2021's Advent of Code in Koka.

It was fun for the first couple of questions, but then got really painful for a couple of reasons. None of this is a complaint on the project, as it is still a research language and has not had a lot of effort invested into getting others to use it.

What I really liked was how easy it was to write parsers due to the effect system. i.e. you'd write a parser that looked like a direct imperative translation of the BNF grammar or the problem statement, and then the effect system would propagate the actual input through the call graph and each parser would only have to deal with its small part.

However several things made me get frustrated and stop which wouldn't have happened with better documentation and more source code to look at.

As someone who has no theory background in effect systems, the syntax was very oblique. i.e. when do I need to mark that my function needs to have a `| e` effect or a `, e` effect. I'm not a fan of the Haskell style of introducing single-letter free variables without any syntactic convention. For example, in Rust, the tick is used to clearly mark that something is a lifetime annotation. The rules about how lifetimes propagate, and so when you need to introduce 2 or more lifetimes are explained clearly (if not in the Rust docs, then somewhere else on the internet). That wasn't the case for Koka's effect syntax. In addition, I would sometimes stumble onto effect annotations that should've worked according to my limited understanding, but didn't. The compiler errors in such cases were really meaningless to me. Other times, I feel like the errors almost indicated that what I was doing was semantically correct, but was not yet implemented in the compiler. Also apparently the `_` has special meaning at the beginning of an effect annotation, but I only found this out from trial and error. Eventually I would just give up on annotating any functions until the compiler complained, but this made it difficult for me to understand my own code (it was like writing Python without type annotations).

The API docs are mostly just type signatures, which means unless it is some simple function, or it is used in the koka implementation sources, you are left scratching your head about how to use the standard library. Things like `ref()` types could also use much more elaboration.

Also, at the end of the day, Advent of Code solutions are generally pretty small scripts, where there isn't a need for effect systems. It was often easier to just use Python and its solid standard library.

Overall, it is an interesting language and I'll definitely keep an eye on it.

My very limited code if anybody is interested: https://github.com/nikhilm/AdventOfCode2021

I also created a minimal Ninja implementation in Rust some time ago. My goals were to implement it in terms of the Build Systems a la carte paper. Of course, hard to compete with the original ninja authors who obviously understand it much better. For example I used a separate lexer and environments, which got a little annoying and is something explicitly called out in their design.

https://github.com/nikhilm/ninja-rs

This is part of the general trend in robots summed up roughly like: 1. Corporations want to save money and are willing to spend up front for it. People will replace personal vehicles far more slowly. 2. A restricted environment is way easier to engineer a robot for vs. arbitrary environments. 3. It is easier to train workers about working around heavy machinery than to teach arbitrary humans to look both ways before crossing the street. 4. It is way easier to get permission on privately owned land than to convince the government for a state or nation wide laws.

I work in autonomous drones and see similar trends in that space too.

Exactly! I would love to own a simple compact car like the Honda Fit or similar with an electric drive train and without leather seats, fancy wheels and various electronic assistive driving features.

Thanks! However it requires Pharo 6.1, and Pharo is at v9 now.

I would also really like to use Pharo more. I tried it for Advent of Code last year [0]. However, I just can't get over the unmanageable custom windowing system going on within the main window. Their isn't an easy way to iterate through windows, find windows, close windows and stop them from overlapping with each other all the time! It would be great to have some kind of Jetbrains/VSCode/modern IDE style layout where all the ancillary structures become panes that are always in a particular position and can be toggled on and off.

That and the lack of a vim editing mode (sorry, but I find it very hard to write code in an editor without vim style bindings, even though I don't use vim itself most of the time), make it a pretty painful experience.

In general, while Smalltalk the environment is a great idea, I think its UI could use some improvements and be much more keyboard driven.

Also, namespaces/modules please.

[0] https://nikhilism.com/post/2021/experiencing-smalltalk/

How easy is it to use with random notes/apps on mobile? Some reasons I prefer a non-browser manager: - On Android/iOS, 1P will integrate with the system password manager APIs to sign in to apps - I can generate/store arbitrary password-like things (SSH key passwords, secret question made up answers, 2FA backup codes) that are not associated with specific domains. At least in Chrome's default password manager there wasn't a way to do something like this.

Agreed. The app stuff is nonsense. We have one of these and they could very well have used a small display or light patterns to indicate test progress and test results without a mobile phone.

Bought a netgear router and a tplink repeater within the last year. All the cloud account crap is only required to use the mobile apps. However they all offer web interfaces directly at their ip addresses. Just use that and bypass all the dark patterns.

It sucks that companies feel the need to cloudify everything.

As Zababa said, it is more about how easy it is to write another implementation, because config files need to be read in another language than (Typescript in this case).

The easier a config language (syntactically, but also in terms of capabilities), the easier it is to write a parser in Go, and Rust and Java etc. All of this particularly matters for libraries or in larger codebases that are multi-lingual.

Using starlark here because I'm most familiar with it.

Starlark's `load()` statement is "find the file at this exact literal path from the workspace root" (no relative paths allowed either). Typescript/Javascript's import is much more complicated. If you encounter an error in Starlark, you fail right there, no exception handling to implement.

Starlark doesn't allow recursion, has an extremely limited set of built-in types and functions, and that means it is very easy to reason about, and even a naive interpreter is pretty fast at evaluating it. I'm also reasonably certain about writing a simple interpreter for it in a week if I had to port it to a new language.

Of course, I view configuration languages on a continuum.

I'd definitely want a pomodoro timer to just use a .ini file. TOML/YAML is great for where you are just going to have a bunch of plain type assignments. No JSON, because comments.

Once you want to write larger configurations, and you need to provide APIs to the user in the language, I'd pick Starlark/Pystachio because they are still intentionally restrictive and Python is one of the most popular languages out there. At this point, you are probably trying to configure something like a large build system (Bazel) or some kind of deployment cluster (say Kubernetes) and you can start providing all sorts of utility libraries (either via bindings to your programming language, or as Starlark libraries). But due to their restricted nature you can still do all sorts of bounded analysis of the evaluation. You can remove things like random() because it's a bad idea.

Yes there are use cases where you want a full blown language to configure something, but those are extremely rare and at that point I think you are no longer "configuring" but just "programming". I very much prefer to keep these 2 things separate.

I’m not on board with using a language that only has a single implementation and is complex enough that implementing others is difficult.

Please use a language designed for configuration, but still sane. There are several if we leave the JSON-inspired family. Starlark, pystachio, Dhall. All are restricted, but allow functions and code reuse. All are simple enough to write a new interpreter for.

One of the authors (Vastraukas) was also an author on “ Using Lightweight Formal Methods to Validate a Key-Value Storage Node in Amazon S3” which seems relevant (Rust code base), but does not mention this tool. I wonder if there is any relation.

https://www.amazon.science/publications/using-lightweight-fo...

I cobbled together something similar using a couple of javascript libraries. It is a really simple web-app that you can open on any phone, and it uses the phone camera to scan the barcode. It saves the results to a Google Sheets (what I wanted). The code is public, mostly because I couldn't bring myself to clean it up. If you are interested, I could make it public. I wrote about it at https://nikhilism.com/post/2021/tracking-books-i-read-using-...

TheDispatch.com if you aren't already reading it.

I agree with other posters that it is better to read news after it is no longer new. We should wait a few days to judge things so they have had a chance to settle in.

Whenever I read news about the kernel surfacing more traditionally OS level features to user space, I'm reminded of Stephen Kell's "Unix, Plan 9 and the Lurking Smalltalk"[1].

There are a lot of parallels between the Smalltalk VMs (where nearly everything about the system is editable and accessible to the user) and where Linux is heading in certain respects, except going there by a very round-about way and relying on very limited binary formats and C instead of high level languages and live objects.

[1]: https://www.humprog.org/~stephen//research/papers/kell19unix...

Another example: Cue Health makes a rapid COVID19 test. They ship you a little box, and a set of wands to insert into the box. The box should literally be able to tell you whether the test passed or failed, like thermometers, and pregnancy tests.

But no, the stupid thing requires you to install an app on your phone, create a cloud account (because we all know we can totally trust the cloud with personal data) and it will refuse to work without any of this.

I highly recommend Regolith Linux (which can also just be installed as a package on Ubuntu).

It offers a nicely setup i3 tiling WM, without having to do any configuration, and things like external displays, bluetooth and so on working out of the box, since it relies on various pieces of GNOME to do that.