cultural reviewer and dabbler in stylistic premonitions

  • 52 Posts
  • 264 Comments
Joined 3 年前
cake
Cake day: 2022年1月17日

help-circle

  • When it’s libre software, we’re not banned from fixing it.

    Signal is a company and a network service and a protocol and some libre software.

    Anyone can modify the client software (though you can’t actually distribute modified versions via Apple’s iOS App Store, due to Apple’s binary distribution system being incompatible with GPLv3… which is why unlike the Android version there are no forks of Signal for iOS) but if a 3rd party actually “fixed” the problems I’ve been talking about here then it really wouldn’t make any sense to call that Signal anymore because it would be a different (and incompatible) protocol.

    Signal (the company) must approve of and participate in any change to Signal (the protocol and service).


  • Downvoted as you let them bait you. Escaping WhatsApp and Discord, anti-libre software, is more important.

    I don’t know what you mean by “bait” here, but…

    Escaping to a phone-number-requiring, centralized-on-Amazon, closed-source-server-having, marketed-to-activists, built-with-funding-from-Radio-Free-Asia (for the specific purpose of being used by people opposing governments which the US considers adversaries) service which makes downright dishonest claims of having a cryptographically-ensured inability to collect metadata? No thanks.

    (fuck whatsapp and discord too, of course.)


  • it’s being answered in the github thread you linked

    The answers there are only about the fact that it can be turned off and that by default clients will silently fall back to “unsealed sender”.

    That does not say anything about the question of what attacks it is actually meant to prevent (assuming a user does “enable sealed sender indicators”).

    This can be separated into two different questions:

    1. For an adversary who does not control the server, does sealed sender prevent any attacks? (which?)
    2. For an adversary who does control the server, how does sealed sender prevent that adversary from identifying the sender (via the fact that they must identify themselves to receive messages, and do so from the same IP address)?

    The strongest possibly-true statement i can imagine about sealed sender’s utility is something like this:

    For users who enable sealed sender indicators AND who are connecting to the internet from the same IP address as some other Signal users, from the perspective of an an adversary who controls the server, sealed sender increases the size of the set of possible senders for a given message from one to the number of other Signal users who were online from behind the same NAT gateway at the time the message was sent.

    This is a vastly weaker claim than saying that “by design” Signal has no possibility of collecting any information at all besides the famous “date of registration and last time user was seen online” which Signal proponents often tout.




  • You can configure one or more of your profiles’ addresses to be a “business address” which means that when people contact you via it it will always create a new group automatically. Then you can (optionally, on a per-contact basis) add your other devices’ profiles to it (as can your contact with their other devices, after you make them an admin of the group).

    It’s not the most obvious/intuitive system but it works well and imo this paradigm is actually better than most systems’ multi-device support in that you can see which device someone is sending from and you can choose to give different contacts access to a different subset of your devices than others.





  • The network never went down.

    You say that but, everything I ever posted on identica (and also on Evan’s later OStatus site Status.Net, which i was a paying customer of) went 404 just a few years later. 😢

    When StatusNet shut down I was offered a MySQL dump, which is better than nothing for personal archival but not actually useful for setting up a new instance due to OStatus having DNS-based identity and lacking any concept for migrating to a new domain.

    https://identi.ca/evan/note/6EZ4Jzp5RQaUsx5QzJtL4A notes that Evan’s own first post is “still visible on Identi.ca today, although the URL format changed a few years ago, and the redirect plugin stopped working a few years after that.” … but for whatever reason he decided that most accounts (those inactive over a year, iiuc, which I was because I had moved to using StatusNet instead of identica) weren’t worthy of migrating to his new pump.io architecture at all.

    Here is some reporting about it from 2013: https://lwn.net/Articles/544347/

    As an added bonus, to the extent that I can find some of my posts on archive.org, links in them were all automatically replaced (it was the style at the time) with redirects via Evan’s URL shortening service ur1.ca which is also now long-dead.

    screenshot of Roy Batty (Rutger Hauer) in the 1982 film Blade Runner, during his "Tears in rain" monologue. (no text)

    imo the deletion of most of the content in the proto-fediverse (PubSubHubbubiverse? 😂) was an enormous loss; I and many other people had years of great discussions on these sites which I wish we could revisit today.

    🪦

    The fact that ActivityPub now is still a thing where people must (be a sysadmin or) pick someone else’s domain to marry their online identity to is even more sad. ActivityPub desperately needs to become content addressable and decouple identity from other responsibilities. This experiment (which i learned of via this post) from six years ago seemed like a huge step in the right direction, but I don’t know if anyone is really working on solving these problems currently. 😢




  • Do tech journalists at the New York Times have any idea what they’re talking about? (spoiler)

    'We’re going to talk about these stories.'

    The author of this latest advertorial, Kevin Roose, has a podcast called “Hard Fork”.

    Here he and his co-host attempt to answer the question “What’s a Hard Fork?”:

    kevin roose: Casey, we should probably explain why our podcast is called “Hard Fork.”

    casey newton: Oh, yeah. So our other names didn’t get approved by “The New York Times” lawyers.

    kevin roose: True.

    casey newton: And B, it’s actually a good name for what we’re going to be talking about. A “hard fork” is a programming term for when you’re building something, but it gets really screwed up. So you take the entire thing, break it, and start over.

    kevin roose: Right.

    casey newton: And that’s a little bit what it feels like right now in the tech industry. These companies that you and I have been writing about for the past decade, like Facebook, and Google, and Amazon, they’re all kind of struggling to stay relevant.

    kevin roose: Yeah. We’ve noticed a lot of the energy and money in Silicon Valley is shifting to totally new ideas — crypto, the metaverse, AI. It feels like a real turning point when the old things are going away and interesting new ones are coming in to replace them.

    casey newton: And all this is happening so fast, and some of it’s so strange. I just feel like I’m texting you constantly, “What is happening? What is this story? Explain this to me. Talk with me about this, because I feel like I’m going insane.”

    kevin roose: And so we’re going to try to help each other feel a little bit less insane. We’re going to talk about these stories. We’re going to bring in other journalists, newsmakers, whoever else is involved in building this future, to explain to us what’s changing and why it all matters.

    casey newton: So listen to Hard Fork. It comes out every Friday starting October 7.

    kevin roose: Wherever you get your podcasts.

    This is simply not accurate.

    Today the term “hard fork” is probably most often used to refer to blockchain forks, which I assume is where these guys (almost) learned it, but the blockchain people borrowed the term from forks in software development.

    In both cases it means to diverge in such a way that re-converging is not expected. In neither case does it mean anything is screwed up, nor does it mean anything about starting over.

    These people who’s job it is to cover technology at one of the most respected newspapers in the United States are actually so clueless that they have an entirely wrong definition for the phrase which they chose to be the title of their podcast.

    “Talk with me about this, because I feel like I’m going insane.”

    But, who cares, right? “Hard fork” sounds cool and the times is ON IT.


  • I started to python one and half week ago. So I’m still beginner.

    Nice work! Here are a few notes:

    The WeatherApp object has a mix of attributes with long-term (eg self.LOCATIONS) and short-term (eg self.city) relevance. Instance attributes introduced in places other than __init__, which makes it non-trivial for a reader to quickly understand what the object contains. And, actually, self.{city,lat,lon} are all only used from the add_city method so they could/should be local variables instead of instance attributes (just remove the self. from them).

    There seem to maybe be some bugs around when things are lowercase and when not; for example checking if self.city.lower() in self.LOCATIONS but then when writing there the non-lower self.ctiy is used as the key to self.LOCATIONS.

    The code under if rep == "1" and elif rep == "2" is mostly duplicated, and there is no else branch to cover if rep is something other than 1 or 2.

    It looks like the config only persists favorites so far (and not non-favorite cities which the user can add) which isn’t obvious from the user interface.

    Passing both location and locations into WeatherAPI so that it can look up locations[location] is unnecessary; it would be clearer to pass in the dict for the specific location. It would also be possible to avoid the need for LOWLOCATIONS by adding a non-lowercase name key to the per-location dictionaries that just have lat and lon right now, and then keeping LOCATIONS keyed by the lowercase names.

    HTH! happy hacking :)




  • Arthur Besse@lemmy.mlMtoLinux@lemmy.mlWhat was Linux like in the 90s
    link
    fedilink
    English
    arrow-up
    2
    ·
    edit-2
    1 个月前

    encryption would prevent the modem from seeing it when someone sends it, but such a short string will inevitably appear once in a while in ciphertext too. so, it would actually make it disconnect at random times instead :)

    (edit: actually at seven bytes i guess it would only occur once in every 72PB on average…)


  • Arthur Besse@lemmy.mltoOpen Source@lemmy.mlEU OS
    link
    fedilink
    English
    arrow-up
    5
    ·
    1 个月前

    As I wrote in the thread about this last month on !linux@lemmy.ml:

    I wonder how much work is entailed in transforming Fedora in to a distro that meets some definition of the word “Sovereign” 🤔

    Personally I wouldn’t want to make a project like this be dependent on the whims of a US defense contractor like RedHat/IBM, especially after what happened with CentOS.

    and, re: “what do you mean ‘redhat is a defense contractor’?!”: here are some links.

    screenshot of RedHat PDF saying: Compress the kill cycle with Red Hat Device Edge.
Deploy on any aircraft, pod,
sensor, or C2 node
 Ability to comply with
cybersecurity requirements
Executive summary
The U.S. Air Force and its mission partners are fielding new mission capabilities on airframes and
command-and-control (C2) nodes to compress the kill chain. The find, fix, track, target, engage,
assess (F2T2EA) process requires ubiquitous access to data at the strategic, operational and tactical
levels. Red Hat® Device Edge embeds captured, analyzed, and federated data sets in a manner that
positions the warfighter to use artificial intelligence and machine learning (AI/ML) to increase the
accuracy of airborne targeting and mission-guidance systems. Challenges of edge computing on
aircraft and other tactical C2 edge nodes include delivering consistent capabilities on diverse
hardware (new and old, connected and disconnected), meeting airworthiness security requirements,
and efficiently sustaining software at scale. The Air Force can meet these requirements with
Red Hat Device Edge, the edge-optimized software platform that is hardware agnostic.
Opportunity: Use edge technology to defeat the adversary
The Air Force and its partners are developing innovative capabilities on airborne and ground systems
to gain battlespace advantage, including:
 Coalescing and stratifying data to feed AI/ML at the edge to increase the accuracy of
targeting and mission-guidance systems and compresses the mean time to detect (MTTD),
make sense and act across all warfighter domains.
 Delivering near real-time data from sensor pods directly to airmen, accelerating the
sensor-to-shooter cycle.
 Supporting Agile Combat Employment (ACE) in the highly contested
21st-century battlespace.
 Sharing near real-time sensor fusion data with joint and multinational forces to increase
awareness, survivability, and lethality.
“With Red Hat Device
Edge Lockheed Martin
is leading the infusion
of cutting-edge
commercial technology
into military capabilities
that deliver advanced
solutions to our
customers. Unlocking
these AI technologies
can help national
security decision
makers stay ahead of
adversaries, enabling
a safer and more
secure world.”
Justin Taylor
Vice President, F-22 technology,
Lockheed Martin 1
1 Red Hat press release. “Lockheed Martin, Red Hat Collaborate to Advance Artificial Intelligence for Military Missions,”
25 Oct. 2022.

    (source)