From joe at begriffs.com Tue Sep 1 01:14:45 2020 From: joe at begriffs.com (Joe Nelson) Date: Mon, 31 Aug 2020 20:14:45 -0500 Subject: Software the keeps working Message-ID: <20200901011445.GG38427@begriffs.com> Continuing the thoughts about software stability, here's a new article: https://begriffs.com/posts/2020-08-31-portable-stable-software.html From dave at 19a6.net Tue Sep 1 02:57:01 2020 From: dave at 19a6.net (Dave Bucklin) Date: Mon, 31 Aug 2020 21:57:01 -0500 Subject: Software the keeps working In-Reply-To: <20200901011445.GG38427@begriffs.com> References: <20200901011445.GG38427@begriffs.com> Message-ID: <20200901025701.GA27843@19a6.tech> On Mon, Aug 31, 2020 at 08:14:45PM -0500, Joe Nelson wrote: > Continuing the thoughts about software stability, here's a new article: > > https://begriffs.com/posts/2020-08-31-portable-stable-software.html What a coincidence -- I just stumbled across How to Write Unmaintainable Code[0]. Reading through it, I've definitely seen some of these behaviors in the wild, and I may have unwittingly committed some of these sins myself. Global scope and dynamic typing is where it's at, y'all! On the other end of the spectrum are NASA's ten rules for developing safety-critical code[1]. [0]: https://github.com/Droogans/unmaintainable-code [1]: http://web.eecs.umich.edu/~imarkov/10rules.pdf From nicholasdrozd at gmail.com Tue Sep 1 22:19:28 2020 From: nicholasdrozd at gmail.com (Nicholas Drozd) Date: Tue, 1 Sep 2020 17:19:28 -0500 Subject: Software the keeps working In-Reply-To: <20200901011445.GG38427@begriffs.com> References: <20200901011445.GG38427@begriffs.com> Message-ID: > The C standard library has no generic collections. You have to write your own linked lists, trees, and hash tables. Real Programmers? might like this, but I don?t. This reminds me of something Bjarne Stroustrup once said: > There is no language called "C/C++". The phrase is usually used by people who don't have a clue about programming (e.g. HR personnel and poor managers). Alternatively, it's used by people who simple do not know C++ (and often not C either). When used by programmers, it typically indicates a "C++ is C with a few useful and a lot of useless complicated features added" attitude. Often, that is the point of view of people who like to write their own strings and hash tables with little knowledge of the standard library beyond printf and memcpy. There are people who stick to a restricted subset of C++ for perfectly good reasons, but they (as far as I have noticed) are not the people who say "C/C++". https://www.stroustrup.com/bs_faq.html From nicholasdrozd at gmail.com Sun Sep 6 01:33:19 2020 From: nicholasdrozd at gmail.com (Nicholas Drozd) Date: Sat, 5 Sep 2020 20:33:19 -0500 Subject: Software the keeps working In-Reply-To: <20200901011445.GG38427@begriffs.com> References: <20200901011445.GG38427@begriffs.com> Message-ID: Well, it hasn't even been a week since this article was published, and here I've found myself using a nonstandard C extension. I want it to be portable. What does the article say I should do? > If you do want to use compiler extensions..., wrap them behind your own macros so that the code stays portable. The example shown deals with a fairly simple macro definition. In contrast, the following program relies fundamentally on a language extension to govern its control flow: ////////////////////////////////////////////////////////////////////// #include #include #define DISPATCH if (!TICK) exit(0); TICK--; goto *dispatch[TICK % 2]; #define SHOW_AND_GO(MESSAGE) printf("%s\n", MESSAGE); DISPATCH; int main (int argc, char* argv[]) { static void* dispatch[] = { &&A, &&B }; int TICK = strtol(argv[1], NULL, 10); A: SHOW_AND_GO("I'm portable"); B: SHOW_AND_GO("I'm portable not"); } ////////////////////////////////////////////////////////////////////// What could be done in this case to make the code portable? From joe at begriffs.com Sun Sep 6 18:39:32 2020 From: joe at begriffs.com (Joe Nelson) Date: Sun, 6 Sep 2020 13:39:32 -0500 Subject: Software the keeps working In-Reply-To: References: <20200901011445.GG38427@begriffs.com> Message-ID: <20200906183932.GA11691@begriffs.com> Nicholas Drozd wrote: > What could be done in this case to make the code portable? The boring answer would be, write normal (non-macro) code: #include #include int main (int argc, char **argv) { long n; if (argc < 2) return EXIT_FAILURE; n = strtol(argv[1], NULL, 10); while (n >= 0) puts(n-- % 2 ? "I'm portable not" : "I'm portable"); return EXIT_SUCCESS; } (This code also behaves properly when n<0, vs attempting to read a negative index from the dispatch array.) Keeping in the spirit of the original, we could use function pointers rather than the "address" of labels: #include #include long TICK; #define DISPATCH if (TICK < 1) exit(0); TICK--; (*dispatch[TICK % 2])(); #define SHOW_AND_GO(MESSAGE) printf("%s\n", MESSAGE); DISPATCH; void a(void); void b(void); void (*dispatch[])(void) = {a, b}; void a(void) { SHOW_AND_GO("I'm portable"); } void b(void) { SHOW_AND_GO("I'm portable not"); } int main (int argc, char* argv[]) { if (argc < 2) return EXIT_FAILURE; TICK = strtol(argv[1], NULL, 10); a(); return 0; } This behaves the same as the original macro example, including repeating "I'm portable" twice initially on odd inputs. I guess one way it differs is that it would keep growing the call stack, whereas the gotos would be more efficient. From joe at begriffs.com Mon Sep 7 18:57:20 2020 From: joe at begriffs.com (Joe Nelson) Date: Mon, 07 Sep 2020 13:57:20 -0500 Subject: Next project Message-ID: <1eJh~.rnf48jNnEz1@begriffs.com> Now that I'm done with writing an article, it's time to think about next projects. Been reflecting on how doing an A+ job doesn't matter if the project is unambitious. I don't want to keep puttering on minutiae. I'm looking for a big project, where even if I don't fully succeed, the effort is going to inspire people. Posting here to get more ideas, to help think outside my rut. Here are some ideas: * Online Recurse Center for all. Since the plague, RC has switched to online-only batches [0] . Can we do it better? Build it around open protocols and remove their members-only restriction? I imagine something like Twitch, where you can tune into people working on programs, but then you could pair with them too. It could be like a worldwide cafe where groups are always there and building things. * Hacker exospace. Everyone carries bits and pieces in their backpacks, converges to a random spot, and assembles the equipment. It's all designed to be fast to set up and tear down, so you could set up in a skyway, food court, or park. If you get hassled, the equipment disappears and you reassemble elsewhere. Equipment ideas: * portable projector * wireless router with 4G bridge * mobile laptop harness * backpack coffee dispenser * portable charger * see also: backpack base station [1] * Email powersuite. Set of tools to extend email, such as sending large files by splitting into the message/partial MIME type, creating a web or gopher view for mbox files (selective "public inbox"), image gallery from maildir (for craigslist alerts), SMS bridge, etc. My mimedown tool was kind of the first step in that direction. * Better bike route planner. I use Google maps to plan my rides, and switch into street view at points along the way to assess if it looks safe for biking. It works, but I'd like a system that could take into account pavement quality, or invent routes to maximize different parameters. * Twin Cities backup. We all run our own NAS, and they mirror each other's data. Maybe everybody gets a certain space quota. We could throw our encrypted files on there for a robust locally-controlled backup system. * Zoom for geeks. A portable peer-to-peer X11 video chat application that can punch through NATs. Lightweight video chat with no central company or web browsers. * Treehouse for masochists. One of those interactive learn-to-code sites, but in this one you start out with a low level language and a virtual memory-mapped disk. You have to write your own data structures, filesystem, networking stack, etc. * Non-proprietary meetup.com. Each group gets RFC 6638 [2] CalDAV scheduling, an email list, an IRC channel with a bouncer, and a donation payment processor. -------------- next part -------------- A non-text attachment was scrubbed... Name: references.uri Type: text/uri-list Size: 202 bytes Desc: not available URL: -------------- next part -------------- An HTML attachment was scrubbed... URL: From joe at begriffs.com Mon Sep 7 20:50:59 2020 From: joe at begriffs.com (Joe Nelson) Date: Mon, 7 Sep 2020 15:50:59 -0500 Subject: Next project In-Reply-To: <1eJh~.rnf48jNnEz1@begriffs.com> References: <1eJh~.rnf48jNnEz1@begriffs.com> Message-ID: <20200907205059.GA22727@begriffs.com> Maybe the limiting factors of my ideas are a) assuming that electronic communication is difficult, when in fact it's a solved problem; or that if only we were following certain RFCs then that would be a meaningful improvement b) technological self-indulgence: addressing minor irritations in ways that require only programming Maybe I should be looking at major problems that are staring me in the face, or problems where programming is just one part of the solution. For instance, misinformation and sensationalism feed into people's pre-existing beliefs. Providing access to primary sources might be helpful, like searchable text transcripts of all city board meetings. Or a searchable database of our city's budget, with charts showing how funding changes over time. Another entirely non-technical project is to research and write about institutions or policies with the same level of care as my computing articles. For instance, investigate the US electoral college, or the doctrine of qualified immunity, and discover what the goals were behind them, and whether the goals were served in application. A kind of "Chesterton's fence" series. Anyway, this may be wandering off-topic for the list... Just trying to think how to be most useful, before reflexively jumping into another random project. From salo at saloits.com Mon Sep 7 21:13:04 2020 From: salo at saloits.com (Timothy J. Salo) Date: Mon, 7 Sep 2020 16:13:04 -0500 Subject: Next project In-Reply-To: <1eJh~.rnf48jNnEz1@begriffs.com> References: <1eJh~.rnf48jNnEz1@begriffs.com> Message-ID: <67e42a9e-89a3-e692-0e49-d1279cb01fbc@saloits.com> On 9/7/2020 1:57 PM, Joe Nelson wrote: > Now that I'm done with writing an article, it's time to think about next > projects. You might consider a distributed system. Here are some that involve sensing: o Real-time city-wide/county-wide/region air quality measurements. Perhaps, maintain the data in a time-series database. Maybe, use AI/ML techniques to analyze the data. Display the data in a visually exciting manner (which should be a requirement for any project). o Shot spotter. o Weather (temperature / pressure / precipitation) o Hydrology (precipitation, stream gauges, weather) o Detect and track cars with no license plates o ... You might also consider, for example, using Rust. My first recommendation for writing reliable code is: "Don't use C". Evaluate Rust as a systems language, and compare it to C. -tjs From starl3ss at protonmail.com Mon Sep 7 21:42:05 2020 From: starl3ss at protonmail.com (starl3ss at protonmail.com) Date: Mon, 07 Sep 2020 21:42:05 +0000 Subject: Next project In-Reply-To: <1eJh~.rnf48jNnEz1@begriffs.com> References: <1eJh~.rnf48jNnEz1@begriffs.com> Message-ID: Can I shamelessly vote for you to look at the hacker exospace? Cryptoparty and Cyberia could both probably make good use of the project, plus, if you got started, we've got some people who might be able to help solve corner cases and field test stuff. I wonder how well a wifi network goes through a snow fort, and what you could do to improve it.... Anyways, it really jumped out at me. Additionally, some way to map wifi networks kids can use to attend school could be immensely helpful, too. Including a way to let households nearby 'volunteer' network availability and for families to request wifi from a neighbor for educational use could also be really nice. Initial stages would probably involve driving through many streets checking availability of public wifi networks. Cheers! Starless -------------- next part -------------- An HTML attachment was scrubbed... URL: From erikbpanderson at gmail.com Mon Sep 7 22:18:00 2020 From: erikbpanderson at gmail.com (Erik Anderson) Date: Mon, 7 Sep 2020 17:18:00 -0500 Subject: Next project In-Reply-To: <1eJh~.rnf48jNnEz1@begriffs.com> References: <1eJh~.rnf48jNnEz1@begriffs.com> Message-ID: I love all the ideas you shared, Joe. From a lens of (global) impactfulness, I particularly like the following two for having great potential for building community and collaboration. I suspect most people on the list would find one or both personally useful. > Online Recurse Center for all. Since the plague, RC has switched to online-only batches. Can we do it better? Build it around open protocols and remove their members-only restriction? I imagine something like Twitch, where you can tune into people working on programs, but then you could pair with them too. It could be like a worldwide cafe where groups are always there and building things. Definitely a grand plan. Just the idea of powerful pairing tools would be fantastic. > Non-proprietary meetup.com. Each group gets RFC 6638 CalDAV scheduling, an email list, an IRC channel with a bouncer, and a donation payment processor. I can't speak poorly enough of Meetup.com. Sounds like an alternative aimed at the software/technology world? Or are you thinking of feature-parity with additional non-proprietary features for accessibility/extensibility? > Treehouse for masochists. One of those interactive learn-to-code sites, but in this one you start out with a low level language and a virtual memory-mapped disk. You have to write your own data structures, filesystem, networking stack, etc. Lol at your phrasing, "Treehouse for masochists"! It would be cool to have a multi-user/multi-agent environment for "network masochists" too! From bavier at posteo.net Tue Sep 8 01:29:14 2020 From: bavier at posteo.net (Eric Bavier) Date: Mon, 07 Sep 2020 20:29:14 -0500 Subject: Next project In-Reply-To: <1eJh~.rnf48jNnEz1@begriffs.com> References: <1eJh~.rnf48jNnEz1@begriffs.com> Message-ID: <27785506dd4b800c60a972b6a382702827d02d73.camel@posteo.net> Hi! project time! :) On Mon, 2020-09-07 at 13:57 -0500, Joe Nelson wrote: > * Better bike route planner. I use Google maps to plan my rides, and > switch into street view at points along the way to assess if it > looks > safe for biking. It works, but I'd like a system that could take > into > account pavement quality, or invent routes to maximize different > parameters. OsmAnd (osmand.net) has a local routing algorithm that can take a lot of different configuration parameters into account. I've wondered before whether it could be extended to consider some more bike-centric parameters. OpenStreetMap has keys for path quality and such; how much coverage they have in your area might vary. > * Treehouse for masochists. One of those interactive learn-to-code > sites, but in this one you start out with a low level language and > a > virtual memory-mapped disk. You have to write your own data > structures, filesystem, networking stack, etc. Start with a virtual punched-tape reader :) > * Non-proprietary meetup.com. Each group gets RFC 6638 [2] CalDAV > scheduling, an email list, an IRC channel with a bouncer, and a > donation payment processor. Have you had a look at Mobilizon (https://mobilizon.org/about/mobilizon )? Cheers, `~Eric From mxu at uribe.cc Tue Sep 8 12:42:36 2020 From: mxu at uribe.cc (Mauricio Uribe) Date: Tue, 8 Sep 2020 08:42:36 -0400 Subject: Next project In-Reply-To: <1eJh~.rnf48jNnEz1@begriffs.com> References: <1eJh~.rnf48jNnEz1@begriffs.com> Message-ID: Joe, This is a great list of ambitious efforts! May i suggest that - wth all due respect - perhaps you not start your own thing...Here me out... Whenever I've struggled during the last few years on "what do i do next", or something along those lines, I've had great luck actually helping others with their effort **first**...and inevitably, some aspect of someone else's project sparks an idea for me; creates a trigger for some effort that was deep inside of me. Half the times my idea or inspiration is related or has to do with that person's project, maybe even a tangent. The other half of the times, it has nothing at all - like zilch - to do with that effort. In essence, my helping someone else just greases the wheels of my brain to think of things i might not have thought at all...Or were buried so deep in my subconscious, that i could not surface them on my own.? Plus, hey, the side benefit of lending a hand to your friend, or a stranger that really benefited from your help or expertise. Now, to my above suggestion, I'd offer 2 thoughts for you... *?> Zoom for geeks.* A portable peer-to-peer X11 video chat application that can punch through NATs. Lightweight video chat with no central company or web browsers. Instead of this specialized zoom, why not work with the folks on jitsi, or some other existing open source option in this space...but try to incorporate some aspects that you had in mind here (e.g. lightweightedness, etc.).? During this pandemic, the more diversity (and in my opinion open source) offerings that we have for telecoms/video conf....that are lighter weight and easy to use and deploy is needed. * * *?>Non-proprietary meetup.com.* Each group gets RFC 6638 CalDAV scheduling, an email list, an IRC channel with a bouncer, and a donation payment processor. Here again, there might be open source options that you might help with. I think Eric or someone else alrready mentioned mobilizon.? I have not used it yet, but have heard good things about it (though early days)...but one of my colleagues at my local LUG has used it and really likes it. Thanks and again kudos for your ambition Joe! -- - mxu -------------- next part -------------- An HTML attachment was scrubbed... URL: From nicholasdrozd at gmail.com Tue Sep 8 14:01:59 2020 From: nicholasdrozd at gmail.com (Nicholas Drozd) Date: Tue, 8 Sep 2020 09:01:59 -0500 Subject: Software the keeps working In-Reply-To: <20200906183932.GA11691@begriffs.com> References: <20200901011445.GG38427@begriffs.com> <20200906183932.GA11691@begriffs.com> Message-ID: > The boring answer would be, write normal (non-macro) code... As I'm sure you can imagine, I love C macros, and you will have a hard time convincing me to stop using them! And anyway, the macros are not the portability issue; the issue is "labels as values" [fn:1] (supported by both gcc and clang). The toy code above is a silly example of course, but it's based on real code dealing with Turing machines [fn:2]. The goal is to read a Turing machine program string from stdin and then execute it. Turing machines can be programmed with arbitrary control flow, and when I say "arbitrary control flow" I mean it. Like, incomprehensibly, unimaginably complex control flow, worse than the most tangled spaghetti code any human could write. What's the best way to deal with that complexity? The straightforward way to write a Turing machine "simulator" is something like this: ###################################################################### while True: if state == HALT: break color, shift, state = program[state][tape[position]] tape[position] = color position += shift ###################################################################### A nice simple `while` loop, easy to understand for any programmer. But it obscures the true nature of the Turing machine program being run. Turing machine programs do not, in general, follow a `while` structure; instead, they do who the fuck knows what. Fitting them into a control flow that we can understand makes our lives simpler, but at the cost of speed, and speed is a big deal. So I thought, can a Turing machine be programmed directly in a "high-level" language? In almost all cases, the answer is no, as most high-level languages (like Python, for instance) are not capable of expressing arbitrary control flow. But C is! Once the labels are set up, control can be passed around at will. In standard C, however, the destination of a goto statement must be known at compile time. But we don't know the destinations at compile time, since they won't be known until the program string is read in. This is where labels-as-values comes in. The question remains: how can C code like this be made portable? Probably there is no good, non-clunky way to do it. Really, the code is not written in C at all. Instead, it's written in a distinct language identical to C but with novel control flow operators added. Making it "portable" would amount to writing the same code over again in standard C and then ifdefing it in. Further discussion of "computed gotos": [fn:3] * Footnotes [fn:1] https://gcc.gnu.org/onlinedocs/gcc/Labels-as-Values.html [fn:2] https://github.com/nickdrozd/pytur/blob/master/machine-4-2.c [fn:3] https://eli.thegreenplace.net/2012/07/12/computed-goto-for-efficient-dispatch-tables From june at causal.agency Tue Sep 8 17:07:27 2020 From: june at causal.agency (June Bug) Date: Tue, 8 Sep 2020 13:07:27 -0400 Subject: Software the keeps working In-Reply-To: References: <20200901011445.GG38427@begriffs.com> <20200906183932.GA11691@begriffs.com> Message-ID: > In standard C, however, the destination of a goto statement must be > known at compile time. But we don't know the destinations at compile > time, since they won't be known until the program string is read in. > This is where labels-as-values comes in. > > The question remains: how can C code like this be made portable? > Probably there is no good, non-clunky way to do it. Really, the code > is not written in C at all. Instead, it's written in a distinct > language identical to C but with novel control flow operators added. > Making it "portable" would amount to writing the same code over again > in standard C and then ifdefing it in. This can be done in portable C using X macros, something like this: int main(void) { #define XLABELS \ X(foo) \ X(bar) \ X(baz) enum { #define X(id) id, XLABELS #undef X } label = foo; dispatch: switch (label) { #define X(id) case id: goto id; XLABELS #undef X } foo: label = bar; goto dispatch; bar: label = baz; goto dispatch; baz: label = foo; goto dispatch; } I?m not sure if compilers are able to optimize this form to the same extent as the C extension (something to investigate on godbolt.org) but it is at least possible in portable C. From chris at mikk.net Tue Sep 8 20:23:00 2020 From: chris at mikk.net (Chris Mikkelson) Date: Tue, 8 Sep 2020 15:23:00 -0500 Subject: Software the keeps working In-Reply-To: References: <20200901011445.GG38427@begriffs.com> <20200906183932.GA11691@begriffs.com> Message-ID: <20200908202300.GA54660@mikk.net> On Tue, Sep 08, 2020 at 01:07:27PM -0400, June Bug wrote: > > > In standard C, however, the destination of a goto statement must be > > known at compile time. But we don't know the destinations at compile > > time, since they won't be known until the program string is read in. > > This is where labels-as-values comes in. > > > > The question remains: how can C code like this be made portable? > > Probably there is no good, non-clunky way to do it. Really, the code > > is not written in C at all. Instead, it's written in a distinct > > language identical to C but with novel control flow operators added. > > Making it "portable" would amount to writing the same code over again > > in standard C and then ifdefing it in. > > This can be done in portable C using X macros, something like this: > > int main(void) { > #define XLABELS \ > X(foo) \ > X(bar) \ > X(baz) > > enum { > #define X(id) id, > XLABELS > #undef X > } label = foo; > > dispatch: > switch (label) { > #define X(id) case id: goto id; > XLABELS > #undef X > } > > foo: > label = bar; > goto dispatch; > bar: > label = baz; > goto dispatch; > baz: > label = foo; > goto dispatch; > } > > I???m not sure if compilers are able to optimize this form to the > same extent as the C extension (something to investigate on > godbolt.org) but it is at least possible in portable C. The above looks equivalent to the traditional finite state machine loop: enum { foo, bar, baz, } state = foo; for (;;) { switch(state) { case foo: label = bar; break; case bar: label = baz; break; case baz: label = foo; break; } } except with an extra jump out of the switch to a corresponding named label. That said, the branch prediction aspects of the computed goto are quite intriguing. -- Chris Mikkelson | That is a form of errant pedantry up with which chris at mikk.net | I will not put. | -- Winston Churchill From dave at 19a6.net Tue Sep 8 21:02:08 2020 From: dave at 19a6.net (Dave Bucklin) Date: Tue, 8 Sep 2020 16:02:08 -0500 Subject: Software the keeps working In-Reply-To: References: <20200901011445.GG38427@begriffs.com> <20200906183932.GA11691@begriffs.com> Message-ID: <20200908210208.GA10010@19a6.tech> On Tue, Sep 08, 2020 at 09:01:59AM -0500, Nicholas Drozd wrote: > So I thought, can a Turing machine be programmed directly in a > "high-level" language? In almost all cases, the answer is no, as most > high-level languages (like Python, for instance) are not capable of > expressing arbitrary control flow. But C is! Once the labels are set > up, control can be passed around at will. You could also probably cook up something rather heinous in Forth! From dave at 19a6.net Tue Sep 8 21:20:28 2020 From: dave at 19a6.net (Dave Bucklin) Date: Tue, 8 Sep 2020 16:20:28 -0500 Subject: Next project In-Reply-To: <1eJh~.rnf48jNnEz1@begriffs.com> References: <1eJh~.rnf48jNnEz1@begriffs.com> Message-ID: <20200908212028.GB10010@19a6.tech> On Mon, Sep 07, 2020 at 01:57:20PM -0500, Joe Nelson wrote: > ? Email powersuite. Set of tools to extend email, such as sending large files > by splitting into the message/partial MIME type, creating a web or gopher > view for mbox files (selective "public inbox"), image gallery from maildir > (for craigslist alerts), SMS bridge, etc. My mimedown tool was kind of the > first step in that direction. Was this intended for me? :-D I love the "public inbox" idea. I also love mimedown and mean to install it one of these days. > ? Non-proprietary meetup.com. Each group gets RFC 6638 CalDAV scheduling, an > email list, an IRC channel with a bouncer, and a donation payment > processor. Others have mentioned Mobilizon. I'd be down to install it somewhere. I think a killer, libre events management system would go a long way toward weakening Facebook's grip on humanity. I've been reading about graph databases (e.g., Neo4j), and think it would be interesting to initiate some kind of knowledge graph project. From ian at ianbicking.org Wed Sep 9 01:59:16 2020 From: ian at ianbicking.org (Ian Bicking) Date: Tue, 8 Sep 2020 20:59:16 -0500 Subject: Software the keeps working In-Reply-To: <20200901011445.GG38427@begriffs.com> References: <20200901011445.GG38427@begriffs.com> Message-ID: I might have heard about it here, but in case I haven't, you might all find this project interesting: https://collapseos.org/ ? trying to create an OS for after the collapse of civilization. I encountered it through this discussion of Forth: https://collapseos.org/forth.html It takes the "software that keeps working" concept further than seems reasonable to me, but I appreciate the sentiment. On Mon, Aug 31, 2020 at 8:14 PM Joe Nelson wrote: > Continuing the thoughts about software stability, here's a new article: > > https://begriffs.com/posts/2020-08-31-portable-stable-software.html > -- Ian Bicking | http://ianbicking.org -------------- next part -------------- An HTML attachment was scrubbed... URL: From joe at begriffs.com Wed Sep 9 02:12:36 2020 From: joe at begriffs.com (Joe Nelson) Date: Tue, 8 Sep 2020 21:12:36 -0500 Subject: Next project In-Reply-To: References: <1eJh~.rnf48jNnEz1@begriffs.com> Message-ID: <20200909021236.GC22727@begriffs.com> starl3ss at protonmail.com wrote: > Can I shamelessly vote for you to look at the hacker exospace? > Cryptoparty and Cyberia could both probably make good use of the > project, plus, if you got started, we've got some people who might be > able to help solve corner cases and field test stuff. That one definitely interests me. Here are my ideas about it so far. Participants arrive with rugged self-contained "boxes" of equipment. They might be lunch boxes, or pelican cases, or custom-sewn backpacks. Netbox ------ This would contain a router, wireless access point, switch, and battery. It would also host a DNS server. Everyone's computers in the exospace can communicate through the netbox. Ideally there could be an interface to register your computer's mac address with a custom name, like "starless.local". Any time you connect to an assembled exospace, it would assign your device the same '.local' name, and thus it would be easy for laptops and phones to find each other and talk directly. The netbox would be designed to be able to bridge to an outside wifi or ethernet connection. The '.local' addresses and their IPs would route amongst themselves, but other traffic would go to the internet provided by the physical environment. We could load up the SSIDs and passwords for tons of coffee shops, stores, etc into the netbox. It would connect to whatever is around, and participants' computers wouldn't need to know which. The netbox is like a simplified version of the discontinued "Pirate Box" https://piratebox.cc/ The pirate box also did some file sharing, and a captive portal, but our our devices do a single thing and do it well. Juicebox -------- An big uninterruptible power supply built into an airport luggage case with wheels and telescoping handle. Add a retracting 50 ft extension cord to plug it into an outlet in the local area. Other devices can sip from the juicebox. Bitbox ------ An SSD NAS in rugged packaging with its own battery pack. Can connect over wifi, or via direct ethernet connection to the netbox switch. Synology products, for instance, come pre-loaded with great file sharing features. https://www.synology.com/en-us/dsm/feature/file_sharing Dazzlebox --------- Contains a projector, and inputs for HDMI, DVI, VGA. Have a side pouch that contains adapter cables for phone video inputs. Also include a video capture device inside so you can record a screen capture as it's being projected. This box, like the others, would have a dedicated battery. Boombox ------- Speaker with a small computer attached that you can stream to over the network. Also has a mic in and headphone out. Fusionbox --------- Works with the juicebox. Holds a stack of solar panels that you take out and set up in an array. Contains a voltage converter and an electrical outlet that you can plug the juicebox into. Making a product out of it? --------------------------- After perfecting prototypes, Cyberia could sell pre-made boxes or something. Could be a source of income. > I wonder how well a wifi network goes through a snow fort, and what > you could do to improve it.... Not sure, although they do make external 2.4/5 ghz wifi antennas that connect to coax cables. Pack the antenna into snow on the roof and route the cable inside... From salo at saloits.com Wed Sep 9 02:18:31 2020 From: salo at saloits.com (Timothy J. Salo) Date: Tue, 8 Sep 2020 21:18:31 -0500 Subject: Next project In-Reply-To: <20200909021236.GC22727@begriffs.com> References: <1eJh~.rnf48jNnEz1@begriffs.com> <20200909021236.GC22727@begriffs.com> Message-ID: <4fdd8948-05f0-cd48-c361-e4d09fb038ed@saloits.com> On 9/8/2020 9:12 PM, Joe Nelson wrote: > Netbox > ------ > [...] > The netbox would be designed to be able to bridge to an outside wifi or > ethernet connection. Starlink. -tjs From joe at begriffs.com Thu Sep 10 03:53:50 2020 From: joe at begriffs.com (Joe Nelson) Date: Wed, 9 Sep 2020 22:53:50 -0500 Subject: Next project In-Reply-To: References: <1eJh~.rnf48jNnEz1@begriffs.com> Message-ID: <20200910035350.GE22727@begriffs.com> Mauricio Uribe wrote: > This is a great list of ambitious efforts! May i suggest that - wth > all due respect - perhaps you not start your own thing... That's a good point: it's better to cooperate and reduce fragmentation. > Instead of this specialized zoom, why not work with the folks on > jitsi, or some other existing open source option in this space...but > try to incorporate some aspects that you had in mind here Now that you mention it, Jitsi has a pretty nice desktop client. Check out the features... https://en.wikipedia.org/wiki/Jitsi#Jitsi_Desktop Maybe this is the video solution I was looking for. From joe at begriffs.com Fri Sep 11 04:50:37 2020 From: joe at begriffs.com (Joe Nelson) Date: Thu, 10 Sep 2020 23:50:37 -0500 Subject: Next project In-Reply-To: <67e42a9e-89a3-e692-0e49-d1279cb01fbc@saloits.com> References: <1eJh~.rnf48jNnEz1@begriffs.com> <67e42a9e-89a3-e692-0e49-d1279cb01fbc@saloits.com> Message-ID: <20200911045037.GH22727@begriffs.com> Timothy J. Salo wrote: > o Detect and track cars with no license plates That's a very interesting one. It probably walks a fine line with the privacy of everyone else who passes across the license plate cameras. But yeah it would be great to catch those creeps. > You might also consider, for example, using Rust. My first > recommendation for writing reliable code is: "Don't use C". > Evaluate Rust as a systems language, and compare it to C. At least for me right now, learning another language sounds boring compared to learning more about a problem domain. Besides, I'm already proficient in Haskell, which is another language in the "tough love" compiler genre. One problem domain that would unlock a lot of possibilities for me is parsing. In my experiment with IRC I wrote some awkward code to read the protocol. It would be great to be able to parse more powerfully. I ordered a book about Lex and Yacc, and will practice building parsers. Those utilities are actually provided by POSIX, so they fit with the theme of long-term tools for the toolbox. https://pubs.opengroup.org/onlinepubs/9699919799/utilities/lex.html https://pubs.opengroup.org/onlinepubs/9699919799/utilities/yacc.html From joe at begriffs.com Fri Sep 11 05:00:18 2020 From: joe at begriffs.com (Joe Nelson) Date: Fri, 11 Sep 2020 00:00:18 -0500 Subject: Next project In-Reply-To: <20200908212028.GB10010@19a6.tech> References: <1eJh~.rnf48jNnEz1@begriffs.com> <20200908212028.GB10010@19a6.tech> Message-ID: <20200911050018.GI22727@begriffs.com> > > ? Email powersuite. > > Was this intended for me? :-D I love the "public inbox" idea. I also > love mimedown and mean to install it one of these days. And did I mention I'd write it in Awk? j/k ;) > > ? Non-proprietary meetup.com. > > I think a killer, libre events management system would go a long way > toward weakening Facebook's grip on humanity. Part of the Facebook allure is probably that many non-technical people are there and using it already, so advertising events reaches a wide audience. From joe at begriffs.com Sat Sep 12 03:48:20 2020 From: joe at begriffs.com (Joe Nelson) Date: Fri, 11 Sep 2020 22:48:20 -0500 Subject: Next project In-Reply-To: References: <1eJh~.rnf48jNnEz1@begriffs.com> Message-ID: <20200912034820.GJ22727@begriffs.com> Erik Anderson wrote: > > Non-proprietary meetup.com. > > I can't speak poorly enough of Meetup.com. Sounds like an alternative > aimed at the software/technology world? Or are you thinking of > feature-parity with additional non-proprietary features for > accessibility/extensibility? I was going to say that what I found lacking on Meetup was integration with other systems, like synchronizing their web calendars with a native calendar app, or getting event updates over RSS. However now that I look into it more, I see they do support those. For instance at the bottom of https://www.meetup.com/TwinCities-C-Meetup/events/calendar/ there are small links like this: Subscribe to a feed of this calendar: RSS Atom iCal Outlook Subscribe to a feed of RSVPs to this group's Meetups: RSS Atom It's not prominent, but it's there. To be honest, for my own needs our simple mailing list is enough. We're able to plan events and do RSVPs. So the Meetup alternative project is of less interest than other stuff I guess. Unless you can think of think of other ways to extend it. From joe at begriffs.com Sun Sep 27 23:57:28 2020 From: joe at begriffs.com (Joe Nelson) Date: Sun, 27 Sep 2020 18:57:28 -0500 Subject: Mimedown message, take two In-Reply-To: <20200711055622.345C63280060@mailuser.nyi.internal> References: <20200711055622.345C63280060@mailuser.nyi.internal> Message-ID: <20200927235728.GA7738@begriffs.com> Thanks to this Tushar guy I learned how to do proper (non-greedy) text justification: https://www.youtube.com/watch?v=RORuwHiblPc I added that capability to mimedown https://github.com/begriffs/mimedown/blob/a7ffdd2010e253772e2b44aa044d4248994fbb80/wrap.c#L92-L161 During the process I learned a trick and a lesson which might be useful for the list. Fun trick --------- The trick is a clever (?) way to count downward in a loop with an unsigned counter. I previously avoided countdowns because of their potential for infinite loops: /* when i is unsigned, infinite loop! */ for (i = n-1; i >= 0; i--) ... After hitting 0, the counter wraps to its highest value, still non-negative. However, the trick is to do this: /* fixed */ for (i = n-1; i < n; i--) ... Assuming n is less than the maximal value for its type, then the unsigned wrap-around will put i>n. To document that we could add, e.g. for size_t n: for (i = n-1, assert(n < SIZE_MAX); i < n; i--) Painful lesson -------------- Didn't think I'd make a dumb mistake, but I did. The bug it caused was super weird, which is what made the whole thing so frustrating. Basically the program worked fine for many inputs, but certain inputs broke consistently on every run. The broken ones didn't seem to have any particular distinguishing factor. Some inputs broke, some didn't. Something as simple as adding or removing a random word in a paragraph would do it. When I examined core dumps with the debugger, I would find that the middle of arrays of pointers to input words had crazy values. Most of the array was fine, but one or two entries partway through would just flip to nonsense. Maybe you C veterans already have an idea what my problem was. I couldn't comprehend what was changing those entries, and added a watchpoint in the debugger on those parts of memory. It detected that free() and malloc() were touching them. How could this be? After all, the elements were in the middle of a chunk of memory I had already allocated. The answer realloc(p, new_count) vs realloc(p, new_count * sizeof *p); Yep, I didn't reserve enough memory, so the middle of my array was unprotected and claimed by future allocations. Automating resizable array? --------------------------- I asked the ##C channel on Freenode if there is a linter to catch the realloc accident. One person said they would use a mini-library to handle resizable arrays, and recommended this: https://github.com/nothings/stb/blob/master/stretchy_buffer.h I liked the idea, but IMHO the code is fatally flawed. The idea is that it allocates an array for you, with a little extra space at the start to hold the number of allocated and used items. Its macros know how to peek backward to read that information, but your code can use the rest of the array with a normal pointer. There are three problems: 1. (Not a showstopper, but) they measure memory sizes with int, and should technically be size_t 2. In an error case, the stb__sbgrowf() function returns (void *) (2*sizeof(int)) hoping that stb__sbraw will turn it to NULL #define stb__sbraw(a) ((int *) (void *) (a) - 2) but this assumes NULL is bitwise 0. Also I don't think you can legally cast raw non-zero numbers to a void pointer. I was trying to think whether you could use a uintptr_t somehow to pull the trick off, but couldn't find a way to make it work. 3. Shifting the array forward to make room for the size info can break the memory alignment of the remaining items. What do you all think, is the stretchy buffer idea doomed, or can it be salvaged into strictly conforming code?