all of these start with “unauthorized access” to define this term. can you please explain how open access to private repositories is not unauthorized access and how you can’t expect your data moving to private repositories to be private?
> Information security's primary focus is the balanced protection of data confidentiality, integrity, and availability
..and radicle.dev does nothing to suggest confidentiality is a focus. Words like "private" or "encrypted" don't appear on their front page.
When I saw this, I was surprised because I didn't even know they supported private repos. I just don't understand why you'd want private repositories on a peer to peer protocol. The whole point is to get away from all of the problematic things that stem from having a single point of control/failure and the hierarchies that follow therefrom. Private repositories means that you're re-implementing the very problems that you're presumably using something like Radicle to get away from, now at the application layer instead. If you can tolerate having an admin that may later be unavailable or untrustworthy such that you're locked out, why not just use github?
It's like private blog posts on wordpress. Yeah, if the feature is in there it should work but projects like these encapsulate a certain perspective, and if they're run by a small number of technologists who clearly in it because they care, then I think it's reasonable to evaluate their success based on whether they address the primary problem they're up against, not whether they have a bug in some feature they tacked on as an afterthought.
Anybody can set up encryption on a link. Shame on them for forgetting to do that, but radicle has much more ambitious goals. If they need more help than they're getting for some of the mundane stuff, well I'm not going to judge them too harshly for that.
|capture| hides an inconsistency that bugs me – everywhere else, assignment to a variable flows leftwards. |capture| is an unnatural rightwards assignment.
in general, I like zig syntax, but i find that it had very little regard to how the eye moves on the page. it’s jarring at times.
Although assignments as expressions in C are convenient, I don't think they make a ton of sense and find Zig's capture easier to read (easier to immediately see what's being evaluated)
All that shell scripting needs is the ability to spawn processes and connect their stdin/out/err together. Or at least, that's what distinguishes "scripting" from "shell scripting". Obviously, you can write a library (I like Python's Plumbum) in almost any language you like that provides this functionality conveniently. So, again: yes, Red can be used for that just as well as any other language (and, arguably, it may be better for this use than many others).
For an interactive shell, you also need a REPL, which Red provides. So if you write that library for Red, you get the interactive shell for free.
Yes, Red has many advantages: it can AOT compile to native, it's homoiconic, it has a built-in Parse dialect (so the library can be really ergonomic), the Red executable is tiny and starts up fast, it has native GUI capabilities (if you're in a Red-based shell and want to view an image, it's trivial to create a GUI window and display it there). I'm not saying Red would be a bad choice. I'm just not sure it would be my choice, given the existence of, e.g., Chicken Scheme or Smalltalk/X.
you need different packed structs for little- and big-endian data. and casting with little-endian data is a nightmare - you need to reverse-cascade your struct fields to be in accordance with the little-endian bit-pattern. (or have a comptime function that does it for you, of course. but then you lose all declarations for the struct). what should be a simple writing down of a protocol is now a pedantic and error-prone ordeal.
Generally those edge cases are always the same endianness. You don't need big and little endianness versions of the structures. What's important is that everyone agrees on the same thing.
if someone chooses to do that they own the problems.
> network byte order isn't a thing
if the network serializes/deserializes for you (kernel primitives) then you don't care what it does. if it doesn't and for some reason you choose to use big endian, again, you own the problem.
Network byte order has nothing to do with the kernel and you have to care about it
It’s a standard because neither side of the connection knows the endianness of the other side so there must be a standard. That standard is big endian regardless of your architecture or kernel or anything else
So any serialization intended go over the network should be big endian
You may have never done socket programming, or do you use wrapper libs in Zig? Because you have to send the kernel big endian port numbers for example.
What do you do if you program a kernel in Zig, or just generally do low level networking?
My point is to refute the statement that everyone has agreed to little endian, and so there aren't use cases to want to do conversion. Programs do not exist in a vacuum, most programs do not.
Well you would, of course, have a mapping layer between wire types and domain types, like in any good codebase. You do the endianness conversion at that boundary, and then you can just send it out.
then you either use an existing C library (the most likely approach) or if you are determined to re-implement it you have to be careful parsing their bytes.
evolution is a wrong concept to approach it. cancer is not a separate life form, but a bug in the regeneration system of a complicated life form. it doesn’t exist outside of it, it cannot propagate.
Cancer researchers generally refer to it as evolution, and I've never heard any complaints from the population geneticists or evo-devo folks about it, so I don't think it's a tremendously controversial way to talk about it. See for example
Excuse me, but I think zig grows ever better from driving away users who are driven away by flashy headlines and whatever is the opposite of this “activism” you suggest.
https://www.fortinet.com/resources/cyberglossary/data-securi...
https://en.wikipedia.org/wiki/Data_security
https://www.nccoe.nist.gov/data-security
etc
all of these start with “unauthorized access” to define this term. can you please explain how open access to private repositories is not unauthorized access and how you can’t expect your data moving to private repositories to be private?
reply