My friend and former colleague has built a bunch of stuff over magic-wormhole like fowl[0], shwim[1] and so on. There is a lot of nice work on "dilated" wormhole.
HN user
vu3rdd
https://rkrishnan.org
There are pre-build packages for OSX, most GNU/Linux distros. I have built it on Windows using the "Microsoft C/C++ compiler for python" that Microsoft makes available for gratis download.
Have you tried Gridsync, a GUI for Tahoe-LAFS?
I have been reading it as well. For my taste, it is a bit too verbose.
I like to see something along the lines of the K&R book or the GoPL book. I was hoping that "Programming Rust" is such a book, but I was disappointed. And (may be it is just me) I like to see exercises in Programming books.
Happy to see the modules chapter and the testing chapter early enough in the book.
Thanks. The new format looks a lot better, IMHO.
Reminds me of the ancient Indian parable in Panchatantra - http://panchatantra.org/of-crows-and-owls/the-brahmin-and-th...
Thanks. Updated the link.
One of the authors of Tahoe-LAFS and the original creator of zfec, Zooko, co-authored a paper on the performance of such codes.
http://nisl.wayne.edu/Papers/Tech/code-pf-fast09.pdf
Luigi Rizzo is the original author of the fec C library.
I co-maintain zfec (and the Debian package of it) along with Zooko. A new release of zfec is planned to be out soonish.
edit: removing the <> delimiters around the URL. Sorry!
People who believe in these ideas are a minority, it seems. Every 'aptitude safe-upgrade' tells me that more and more disk space is required to install the packages.
OpenBSD project seem to be doing the right thing (as they always did, imho) by deleting a lot of code from the base and not letting it to rot.
Good points.
As a programmer, one has no choice most of the time on what language a program should have been written, in my career, I have mostly been modifying and adding code than writing new code from scratch. This mostly means C, for anything close to hardware, as electrical/electronics engineers are familiar with it. Another way of saying this is that, "I program in whatever language, my team is programming in".
Embedded systems also have size limitations and the problem of bootstrapping on new hardware. C has time and again proven to be easy.
If you examine a typical GNU/Linux distro, you see all kinds of programs written in C that ought to have been written in a type safe language because most of the time, C's features were not required for the program.
I wish more and more "new" programs are written in all kinds of languages (not just Rust, but in Python or Haskell or OCaml ..) other than C and that we restrict C to the things we really need it for.
Overall, knowledge of C is only going to help. Whether you want to use it to use it for your next project is something that depends on the problem at hand.
netsurf?
The essence of the language has not changed. But C99 came out with a few nice things. There is also C11 which brought in a few new things as well. It would have been nice to bring the book up to C99.
"Modern C" is a good book on some of the new features.
http://icube-icps.unistra.fr/img_auth.php/d/db/ModernC.pdfWhy is it OK to lock down smartphones, TV devices, consoles, but not OK for PCs?
IMHO, it is not OK to lock down things you own. I have been a victim. I bought an AppleTV v2 and a planned obsolescence by Apple and Google rendered it useless (with a YouTube API version requirement).
PCs are special in that, they are general purpose devices and not appliances. If you are using it as an appliance, chances are, you are not interested in running another operating system on it.
I wish the original course is offered in an alternate platform like edX.
Very nicely said!
Sad is also being at the mercy of Apple to do "upgrades" of software, being at the mercy of Apple for security fixes.. the list goes on.
There is this nice guide: https://emailselfdefense.fsf.org/en/
It has instructions for all major operating systems.
I am posting the article "No silver bullets" again, in the wake of the npm fiasco. I think it is an essential reading for every programmer, every year!
That's a great list, all in one place! Thanks to the author of that web page.
I don't see how this message is reassuring. Are they expecting the customers to just take their word? Without Apple showing the world, every bit of software that they run on their phones, these statements are at best, meant to mislead the users that Apple is doing something on the user's behalf.
I forget where I read it, but it was many years ago. But paraphrased, it read "never believe anything you read in print". It was quite an eye opening statement for me.
Yes, indeed. Even with the 101 level haskell I write, it feels so right. I exactly know where the side effects are and the semantics of the program is so clear.
...fear that my program isn't abstracted far enough...
This. I feel exactly the same. I read various concepts like Free Monads, I go find papers and read them. But when I sit down to write code, my code is a blob doing IO. I can use State monads, StateT etc. But the result is not the elegant programs that I see on books and blog posts.
I am also very pragmatic. I want to build tools that implement an idea I have. I want to build as soon as possible to try these ideas out. But when programming in Haskell, I find myself code golfing and lost in the means rather than the ends.
I played with Racket and used to lurk on their mailing lists for many years! I haven't seen a friendlier community than the Racket community anywhere else.
DrRacket is a great environment to learn programming and play with various concepts, both for beginners and advanced users alike.
While what you are saying is very true, recent developments around systemd seem to have changed a few people to target linux-kernel based systems than the BSDs.
As the autoconf files suggest, a lot of GNU software was written in the most general way possible, targeting even the macos/osx/windows/aix/hpux etc.
In this age of easy virtual machine installations, it seems odd that software authors of popular software are not targeting at least the BSDs.
I think the author should have called it "Why C and C++ are awful _teaching_ languages".
Ditto. I am looking forward to it as well. I am a big fan of the writings from the folks at Bell Labs. The awk book, the "software tools" book, the TPoP book. They are some of the finest programming books ever.
The paper seem closely related to another paper by all the three authors and the late Len Sassaman, titled "The Halting Problems of Network Stack Insecurity".
I think a lot of comments in this thread are too harsh. I am a C programmer myself and see the value of it in embedded systems, operating system kernels etc.
While it is possible to write correct programs in C and C++ (which are very different languages, but usually mentioned together because of their names and history), it is too easy to make mistakes that are not caught by the compiler. It is easier to be sloppy in C than in say, Go or Rust. I have seen this in my own code and also in others' code.
C is not the only way to write system programs. Oberon, Inferno are good examples of OS environments written in safer languages.
But I agree that some of the disadvantages of C are also its advantages.
The author of the blog post has more followup posts:
http://trevorjim.com/why-safe-languages-are-the-best-way-to-achieve-memory-safety/
http://trevorjim.com/an-unsafe-legacy/
http://trevorjim.com/unsafe-at-any-speed/
[edit: fix typos, rephrase a few sentences, fix links]Highly recommend the Coursera Course called "software security".
To me, a fast bootup is a non-issue. I want "less magic" with my computers. I want to have control over my system. Surely it must be possible with systemd. But the good old sysv-init works for me and I am familiar with it. Shoehorning any system for every possible need is probably a bad idea. True with systemd and true with sysv-init or any system.
Yes, I follow that process too. I almost always use netinst. There is also a mini iso.