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.
The magic sauce for desktop users is home-manager, which allows declarative setup of your user environment. And rollbacks to previous generations with one command , in the OS or the boot screen.
I use it to set up my window manager, fonts, Vim/VS Code/Firefox plugins, configure all my tools, set up user-specific systemd jobs, ...
I recently got a new laptop and I had my perfect setup in 20 minutes (install NixOS, git clone config repo, add new machine specific config (disks), apply NixOS config).
I appreciate that it's not for everyone , but it is brilliant.
How does Guix compare to Nix? It seems like by using a scheme-based DSL instead of an ad-hoc configuration language, it solves one of the main complaints the author has about Nix.
IMO Guix is better but still has some work. My major pet-peeve of Guix is it's anti-proprietary software, which is a necessary compromise. The world is composed of many different people and beliefs; software should be belief-agnostic.
I think it's worth pointing out that guix will not package proprietary or binary software in the main channels but nonguix exists for those needs if one absolutely needs to have those packages in guix. At the same time guix packages flatpak which allows one to install most, if not all, of the proprietary packages they may want to use. I think the compromise from the guix maintainers is to develop and distribute free software but at the same time being silent on how a user goes about adding proprietary packages to their system. Which is fair IMO.
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.
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.
I can also recommend Deep C Secrets. For me, a lot of C didn't really click until I read that book. In particular, having mainly done Python and other very high level languages up until that point, this book's discussion of pointers and memory were what got C to finally click for me.
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 had the same experience with this book. I set out as an intermediate C programmer and ended up just bored to tears with things I felt were obvious and frustrated that questions about “real” C code were not being answered. Also the exercises were... very involved for just trying to learn potentially simple points. I ended up giving up on the book for now, maybe I’ll pick it back up later or I’ll peruse your list.
I used k&r as my first C book. You can learn C from it. However it does teach a C that is not really used in the wild. Specifically function definitions and tri-glyphs. Its memory management is kind of hand wavy and it does not stress enough the importance of getting the types right (like the nightmare of printf). Both of which can cause memory issues very quickly. If you start with that book I would recommend one of those others to go along with it. Using C is easy. Getting it right takes time, practice, and a few stubbed toes.
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!
This sounds like an interesting organizing principle, but in practice it is implemented quite rigidly, and produces, in my opinion, two serious weaknesses.
First of all, organizing by levels of detail, rather than treating individual topics in depth all at once, means that a fair amount of related information gets spread around the book.
This might be OK if the book had a comprehensive index, or consistently used forward-references to point the reader to a detailed discussion, but the book is generally weak in these sorts of cross-references.
For example, suppose you want to look up formatting strings for use with `printf()`. The index (I am looking at the Manning version) lists exactly one entry for `printf()`, which is on page 8 -- and the actual text there just mentions basically that `printf()` is a function that exists.
You could also look up "format", which gives one reference, to page 5, where the term is introduced but hardly even defined. The index does have more entries for `snprintf()` and `sprintf()`, if you happen to think to look for those. But after you play this game for a while, it becomes clear that the index takes a quite mechanical view of these functions, content to list locations where the function gets called out in the text, but without any great concern for where they are discussed as a cohesive collection of related functionality.
To me, this levels-of-experience approach makes sense for some things, like deferring discussion of threads, and setjmp-longjmp, till later chapters. That's why I say that the book errs by sticking to the game plan too rigidly.
The second major shortcoming of this rigid levels-of-experience approach is that the book delays discussing pointers for a long time. They aren't really taken up until chapter 11. Literally the book doesn't show a basic "swap" function until page 170. This means that a lot of code examples that come before chapter 11 do quite a dance to avoid using pointers.
When, finally, pointers are discussed, I felt that the text was somewhat lackluster. There is nothing wrong with it, but if this chapter was a blog post by some random C programmer, and got posted to HN, I doubt it would garner a lot of upvotes by enthusiasts saying it was the best description of pointers they had ever read.
Thus it had an anti-climactic effect for me -- I expected that deferring the discussion of pointers for so long would have some kind of pedagogical payoff, but there wasn't anything to it that, to me, justified putting it off for so long.
I had a few other problems with the book, but nothing that, by themselves, would keep me from recommending it.
I might recommend the book to somebody who already knows C, and wanted a deep dive on certain topics. However I would steer a beginner away from it.
Somebody else on this thread mentioned another new entry to this field, "Effective C" from No Starch Press. I am in the middle of this one, and so far like it a bit more (though I am not yet a full-throated enthusiast for it). I would note that "Effective C" introduces a swap function on page 16. That would be wildly premature to the author of "Modern C", but in the end I think it will serve the beginning reader somewhat better.
I learned C from K&R. It was lent to me by an English teacher (!) from my high school and I can still recall the smell of it (stale coffee and cigarette smoke). C was my fourth language after BASIC, Pascal and 6502 Assembler.
I use C11 atomics pretty regularly. While lock-free data structures are tough to get right, there are other uses of atomics that are easy. For example, portable lock-free multithreaded statistics counters.
Indeed, C11 and C18 don't bring a lot. I'm glad that they don't because backwards compatibility and roughly predictable development of the language is important to me.
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.
We're in the process of moving away from an internal build system for the packaging to having the debian package scripts as part of the repo. This work is underway for BigBlueButton 2.3 (the next version) and beyond. Once we get them released, it's going to be a lot easier for others to build and contribute to the packaging.
Christian has also put some work into the underlying database and such lately, but the user facing part of that is Oasis [1] which aims to be an ssb interface that has a no-JS UI, with all the logic being handled by the (locally running) nodeJS server.
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.
