gnu

Very nice post Robin! And so honest! Subscribed via my rss reader.

I also forgot to add one thing that tripped me recently but I am sure a solution exists for it that I am not aware of.

In Debian we do: apt-cache search <search string>

It gives quick results.

The equivalent in nix is (correct me if I am wrong, it has been a while since I did this): nix-env -qaP <search string>

This command takes so long to execute. On a tiny VPS, when I did this, it ran out of memory. I wish things like this are improved.

NixOS and Guix are nice! Guix folks are doing some wonderful work off late.

I have used NixOS for a while. But for casual desktop GNU/Linux users, it seem like solving a problem that doesn't exist. Have been using Debian on all my computers since 1998. Unless you are using Debian unstable and updating it daily, I hardly hit any breakage.

Servers and deployments is another story.

Christian Kellermann wrote this nice "Code it yourself Manifesto" [0] that always rings true with me. It is more important now than ever before. I believe OP is talking more or less the same thing.

[0] https://pestilenz.org/~ckeen/blog/posts/ciy-manifesto.html

Same. I am in the industry for 20+ years and thankfully none of my jobs have involved anything close to ads.

I have been meaning to learn the Plan 9 dialect of C but haven't gotten around to it.

I too learned C from K&R and really loved it. I did not have any other thing to do and there was no internet and no one telling me that C is bad. Nor was I aware of other cool languages. I did not even have a computer at that time, so I wrote most of the exercises on paper. Later my father bought me a 486DX66 and I typed in most of the programs in the book. Those were fun times!

Sure, but that is meant as a personal thing and not meant as a general statement. Everyone should evaluate whether the book (any book) works for their needs.

The main reason is that, it was a very dry read with various rules and syntax etc and I got bored looking at it quickly. It almost felt like I am reading an abridged version of the standard itself. The exercises didn't appeal to me much.

I didn't mean to dis the efforts of the author at all. There is no other book that covers the modern parts of the standard well. I am not aware of any other C book that covers the wide chars than this book.

I didn't enjoy this book, to be blunt. K&R still holds up as an interesting read, despite it not being updated to latest ANSI C standards. It is probably not a good first book.

A few C books I like:

  * C: A reference manual.
  * C: Interfaces and Implementations.
  * Deep C secrets.
  * C: Traps and Pitfalls.

Awesome! Thanks.

Thanks so much for giving us BigBlueButton.

Some of the folks in the Debian community have been trying to package it up in Debian and found it a bit challenging that some of the dependencies of BBB work only with specific Ubuntu versions. Would you please help address that and help them move forward with packaging it up and include it in Debian? Thanks again.

Relevant: https://www.gnu.org/philosophy/right-to-read.en.html

Interesting! Is there any document that I can read about your reimplementation? Or any code?

Exposing something as files is kind of like a "protocol". The alternative would have been a library (implemented in a language) that would make things confine itself to the ecosystem of the language. Instead, anyone who can talk to files and directories can interact with this program!

There are applications where this may not entirely be a match though..

keybase is unfortunately one of those programs that combine many things into one - somewhat antithetical to the Unix philosophy of doing one thing well.

For kbfs, tahoe-lafs is a nice alternative. I don't know about the fuse interface as I haven't used it, but it has some solid fundamentals behind it, actively being developed and can be self hosted.

GPG still works! GPG also is a swiss army knife, unfortunately. There is OpenBSD signify (or minisign) if you want signatures.

There is also age - https://github.com/FiloSottile/age

There is tahoe-lafs. Give it a try.

Thanks. Where can I see the second edition draft?

edit: This one? https://github.com/rust-lang/book.git

> Many of Rust's designers are experienced systems programmers. A _lot_ of effort goes into making it systems-ready.

That is promising. Thanks. I am certainly playing with it at home.

> Systems programming does not preclude a language from having a good type system or higher level abstractions.

I didn't say that system programming does not need a good type system. I am also not saying that it is impossible to design operating system software with Rust.

As someone who had been on both the sides of the abstraction and having closely interacted with the system programmers, I think it is just too hard to convince them to use Rust. It is not just about the language alone, it is about what minimum you need to bootstrap a system (among many other things).

Anyway.. good luck to the OP in "rewriting everything in rust" and also getting it to the same quality/feature parity as others in the game and also get others to use it as well.

Great. They all look great. The ones like higher kinded types are the ones that I am highly suspicious of. The typical C programmer who pokes around hardware data sheets and writes drivers and stuff will likely not pay much attention to Rust if such complex features are added.

Also features like that makes me wonder if you folks are really targeting C/System programmers. Sorry if I sound negative, that isn't my intention.

Another gripe I have is that the Rust Book examples are all targeted at non-system programmers. It would have been nice if certain programs written in K&R book or from one of those books from the Bell Labs Unix folks (like "The practice of programming" or "software tools") is written in Rust as a demonstration.

May I ask what those big ones are? How is it going to affect/improve the life of a systems programmer?

I was referring to the RFCs. They also seem to include language changes. Happy to be proved wrong.

Rust is nice. But the article miss one important point. Modern software engineering is a collaborative effort (well, it has always been, afaik). I write code for others to understand. I find Rust code significantly hard to read (I am saying this as an experienced C/C++ programmer and as an intermediate haskeller). Yes, one can write write-only code in any language. I think it is extremely important to write code that others can understand and imho, it trumps all other reasons. Not trying to underplay the value of type safety. It is fantastic. My Haskell programs have much much less bugs and I tend to get it to work, much faster than when I do C/C++ code. I would expect some of that goodness to be in Rust programming as well.

It would have been fantastic, if Rust took only a few steps further from Cyclone. I also wish that Rust authors stop adding more and more features. The target audience, namely low level system programmers, tend to work close to hardware and think along those lines, so bombarding them with type theory concepts is only going to shoo them away.

Just my 2 cents.

How are the security update/fixes handled in NixOS?

Modern 'Linux' systems are full of programs that violate Unix philosophy.

cdrecord, ffmpeg, emacs, dbus, imagemagick, all modern browsers ... the list goes on and on. plumber(4) does what dbus is trying to do, with very little amount of code and text file based rules.

I see it as a missed opportunity for linux kernel and hence to the wider audience to experience a computing environment that is a joy to use.

Since no one mentioned Plan 9, I thought I will mention one of the many features that makes Plan 9, one notch above Unix to make it easy in the web era.

In Plan 9, literally everything has a file abstraction. This also includes sockets. So, even shell programs can be network programs without external programs like curl or wget or anything like that. For anyone interested, look at webfs(4). You may say that this can be implemented with fuse. But having something first class, designed to operate well within the file abstraction, is very different from something that has been added as an afterthought. In some sense, the BSD folks who added sockets into Unix really screwed it up and missed the Unix philosophy altogether.