GNU social JP
  • FAQ
  • Login
GNU social JPは日本のGNU socialサーバーです。
Usage/ToS/admin/test/Pleroma FE

  • Public

    • Public
    • Network
    • Groups
    • Featured
    • Popular
    • People

Notices by LisPi (lispi314@udongein.xyz)

  1. Embed this notice
    LisPi (lispi314@udongein.xyz)'s status on Friday, 22-Nov-2024 15:53:04 JST LisPi LisPi
    in reply to
    • 翠星石
    • nyanide :nyancat_rainbow::nyancat_body::nyancat_face:
    @Suiseiseki @nyanide I wonder if one can release such projects under a nonprofit or other similar entity one created for the purpose of "owning" the resulting work.

    Of course that begs the question why would one accept the unreasonable terms Google requests to start with, of course.
    In conversation about 2 days ago from udongein.xyz permalink
  2. Embed this notice
    LisPi (lispi314@udongein.xyz)'s status on Thursday, 21-Nov-2024 19:22:19 JST LisPi LisPi
    in reply to
    • 翠星石
    • MostlyHarmless
    @Suiseiseki @MostlyHarmless It's been a few years since the last (known) instances in Firefox not dependent on Javascript, but CVEs for transport, image renderers & such are present for 2014, 2015 and 2016 that could've been turned into code execution (or demonstrably were).

    It's way more common with Javascript and it's the majority of what is being found now. Though whether that's because people stopped looking elsewhere or the codebases truly improved, I couldn't say.
    In conversation about 3 days ago from udongein.xyz permalink
  3. Embed this notice
    LisPi (lispi314@udongein.xyz)'s status on Thursday, 21-Nov-2024 16:14:57 JST LisPi LisPi
    in reply to
    • 翠星石
    • MostlyHarmless
    @Suiseiseki @MostlyHarmless There are the odd exploitable bugs in HTML/CSS parsing and rendering & such, from time to time, unfortunately.

    So while not executing arbitrary Javascript code is a good step, it only removes most of the common attack surface, not all of it.
    In conversation about 3 days ago from udongein.xyz permalink
  4. Embed this notice
    LisPi (lispi314@udongein.xyz)'s status on Saturday, 09-Nov-2024 02:06:15 JST LisPi LisPi
    in reply to
    • Håkan Geijer
    @hakan_geijer > Perhaps it's who I'm following (and what does that say)

    Probably. Pretty much everyone I follow is either talking about other things or actively encouraging ownership of such tools.
    In conversation about 15 days ago from udongein.xyz permalink
  5. Embed this notice
    LisPi (lispi314@udongein.xyz)'s status on Friday, 08-Nov-2024 15:05:45 JST LisPi LisPi
    Periodic reiteration of my profound annoyance at the unnecessary conflation of titles/subjects and content-warnings.

    I don't know if Mastodon is responsible for it, but it seems dumb-enough to be the case.
    In conversation about 16 days ago from udongein.xyz permalink
  6. Embed this notice
    LisPi (lispi314@udongein.xyz)'s status on Saturday, 02-Nov-2024 07:51:03 JST LisPi LisPi
    in reply to
    • screwlisp
    • Paul SomeoneElse
    @screwtape @pkw It'd be nice for Common Lisp to have something like Emacs Lisp's make-obsolete that is actually considered by the rest of the system.

    Compatibility layer is only good (mostly) if the signature doesn't change, otherwise it's creating an avoidable maintenance nightmare (especially if multiple versions are kept) while also worsening the usability with all sorts of docstring-only info (or worse, a bunch of undocumented behavior).

    The pattern I've observed that is most sensible for this is encoding the difference in the classes, such that one can then simply recursively upgrade the instances (now-obsolete and unused methods can possibly be safely removed at this point depending on program flow), handling all that is necessary for compatibility differences there, and otherwise preserve everything unchanged from an external user point of view.
    In conversation about 22 days ago from udongein.xyz permalink
  7. Embed this notice
    LisPi (lispi314@udongein.xyz)'s status on Saturday, 02-Nov-2024 07:07:02 JST LisPi LisPi
    • screwlisp
    • Paul SomeoneElse
    @pkw @screwtape Alternatively, if one is presenting a stable API of some sort (or supporting a versioned protocol), it could make sense to keep the old ones around.
    In conversation about 22 days ago from udongein.xyz permalink
  8. Embed this notice
    LisPi (lispi314@udongein.xyz)'s status on Monday, 28-Oct-2024 09:07:13 JST LisPi LisPi
    in reply to
    • Haelwenn /элвэн/ :triskell:
    • ??? 妛彁 :xf_nyxsigil: :xf_nyxdisapproving:
    • inkwater
    @nyx @ink @lanodan A lot of your first paragraph is mirrored in GNUnet documentation & whitepapers.

    The solution to the hardware problem is to also enable emulating/tunneling it atop other legacy hardware.

    To the third one, there's a reason they go "let's make a GNU internet" (puns, yes), sure tunneling isn't an ideal solution but it still is an option and it bypasses purposely uncooperative political fuckwads.
    In conversation about a month ago from udongein.xyz permalink
  9. Embed this notice
    LisPi (lispi314@udongein.xyz)'s status on Monday, 28-Oct-2024 08:55:50 JST LisPi LisPi
    in reply to
    • Haelwenn /элвэн/ :triskell:
    • ??? 妛彁 :xf_nyxsigil: :xf_nyxdisapproving:
    @nyx @lanodan The serious reseachers aren't exactly publishing much at the moment, other than meshnets with little retrocompatibility (which kills mass adoption).

    Sure I'd like if people just went and used the meshnets anyway but they don't.

    GNUnet's implementation has a bunch of problems and a lot of it is waiting on research to complete (no ETA) so progress can continue (I'm probably going to be long dead by the time it completes).

    What alternatives do we have? I2P? Sure it works, but it *also* has a bunch of issues.
    In conversation about a month ago from udongein.xyz permalink
  10. Embed this notice
    LisPi (lispi314@udongein.xyz)'s status on Monday, 28-Oct-2024 08:53:27 JST LisPi LisPi
    in reply to
    • Haelwenn /элвэн/ :triskell:
    • ??? 妛彁 :xf_nyxsigil: :xf_nyxdisapproving:
    @lanodan @nyx dat:// had some interesting ideas, particularly with tunnel encryption between individual peers to mitigate observability, but then they went and wasted their time with unnecessary blockhain/coin bullshit.

    I was very disappointed on noticing that.
    In conversation about a month ago from udongein.xyz permalink
  11. Embed this notice
    LisPi (lispi314@udongein.xyz)'s status on Monday, 28-Oct-2024 08:52:51 JST LisPi LisPi
    in reply to
    • Haelwenn /элвэн/ :triskell:
    • ??? 妛彁 :xf_nyxsigil: :xf_nyxdisapproving:
    @lanodan @nyx Purely by diversity of implementations BitTorrent is more resilient.
    In conversation about a month ago from udongein.xyz permalink
  12. Embed this notice
    LisPi (lispi314@udongein.xyz)'s status on Sunday, 27-Oct-2024 08:09:56 JST LisPi LisPi
    in reply to
    • Haelwenn /элвэн/ :triskell:
    • niconiconi
    • Rich Felker
    • Chris Martin
    @lanodan @niconiconi @dalias @chris__martin > with static linux binaries (like Mosaic can be ran that way)

    This is an issue mostly because the wrong layer is being distributed. The Operating System APIs for Linux are specified and standard at the ABI level, so particular cached computations (a binary) targeting that ABI will continue working in environments supporting it (different computer architectures being different environments). The stable/standard compatibility layer for most Linux binaries is typically at the source level inherited by libraries that only provide compatiblity & reliability guarantees at the source level.

    It makes no sense to distribute the program at a layer that is not subject to reliability guarantees otherwise mentioned. (related: https://gbracha.blogspot.com/2020/01/the-build-is-always-broken.html)

    (I don't think GNU LibC makes any claims of ABI stability across versions, so a given cached version of it cannot be used as a reliable primary artifact.)

    > But it'll also mean just throwing out security entirely, which enterprise software does all the time.

    Unless cryptography is involved, that shouldn't be the case and suggests there's something wrong with the running environment rather than the program.

    For cryptography there are ways of handling that, mainly presenting a stable API at some layer or another. Programs using SSH don't need to know more than its command line interface (which SSH itself has somewhat standardized I think), programs using I2P (as clients) need nothing more than standard HTTP or TCP support (through reverse-proxy tunnels) & do not care about the I2P version used. And of course, libraries presenting a stable API (whether type/function-call based or protocol-based, with appropriate upgrade support in the background), which I think is the standard way to go now, will simply keep working.
    In conversation about a month ago from udongein.xyz permalink

    Attachments

    1. No result found on File_thumbnail lookup.
      The Build is Always Broken
      Programmers are always talking about broken builds: "The build is broken", "I broke the build" etc. However, the real problem is that the ...
  13. Embed this notice
    LisPi (lispi314@udongein.xyz)'s status on Sunday, 27-Oct-2024 08:09:55 JST LisPi LisPi
    in reply to
    • Haelwenn /элвэн/ :triskell:
    • niconiconi
    • Rich Felker
    • Chris Martin
    • LisPi
    @niconiconi @dalias @chris__martin @lanodan > programs using I2P (as clients)

    Well, as servers too, it works on both ends. And SAM's protocol handles retrocompatibility too.

    Some of the other libraries for I2P do not provide compatiblity guarantees across versions, but I think they're also all deprecated for that same reason.
    In conversation about a month ago from udongein.xyz permalink
  14. Embed this notice
    LisPi (lispi314@udongein.xyz)'s status on Sunday, 27-Oct-2024 06:52:04 JST LisPi LisPi
    in reply to
    • Rich Felker
    • Chris Martin
    @chris__martin @dalias > "why does software require maintenance"

    Improperly defined interfaces between systems & libraries and software, most of the time.

    Then there's the odd once in a while (often with decades-long spacing) that one needs to change something to support a new system entirely.

    > what matters is its relationship with the surrounding context, and that context is in perpetual change.

    That's mostly true for software with unlimited scope. It is perfectly possible to have software that is /complete/ and needs no more maintenance than the second example I gave above.
    In conversation about a month ago from udongein.xyz permalink
  15. Embed this notice
    LisPi (lispi314@udongein.xyz)'s status on Friday, 25-Oct-2024 20:05:19 JST LisPi LisPi
    in reply to
    • iced depresso
    @icedquinn Yeah, wtf is up with that?
    In conversation about a month ago from udongein.xyz permalink
  16. Embed this notice
    LisPi (lispi314@udongein.xyz)'s status on Friday, 25-Oct-2024 19:53:39 JST LisPi LisPi
    in reply to
    • iced depresso
    @icedquinn It seems to be very common for management to encourage workers not to defend themselves, instead of intervening by having rude customers escorted out and/or banned depending on what they did.

    That is where I think unions would have an impact.
    In conversation about a month ago from udongein.xyz permalink
  17. Embed this notice
    LisPi (lispi314@udongein.xyz)'s status on Friday, 25-Oct-2024 19:46:07 JST LisPi LisPi
    I wonder what would help get rid of the mistreatment that is common in service jobs (particularly chain stores).

    Is unionization the answer? Or is there something else that can be done on a regulatory/legislative level (besides enshrining unions and getting rid of anti-union bullshit, of course)?
    In conversation about a month ago from udongein.xyz permalink
  18. Embed this notice
    LisPi (lispi314@udongein.xyz)'s status on Tuesday, 22-Oct-2024 16:19:11 JST LisPi LisPi
    in reply to
    • clacke
    • wakame
    • Hayley
    @hayley @wakame @clacke Ah I see. (Yeah, I somewhat remember the quote.)

    Less jokingly, I've generally been looking the way of distributed SQL databases, it seems to me they could more cleverly adjust their behavior & performance than static shards.

    I haven't had need for them though, I do not own anywhere near enough machines to make them relevant as more than a curiosity.
    In conversation about a month ago from udongein.xyz permalink
  19. Embed this notice
    LisPi (lispi314@udongein.xyz)'s status on Tuesday, 22-Oct-2024 16:19:05 JST LisPi LisPi
    in reply to
    • clacke
    • wakame
    @clacke @wakame Reminded me immediately of the "Mongo DB is Web Scale" video.
    In conversation about a month ago from udongein.xyz permalink
  20. Embed this notice
    LisPi (lispi314@udongein.xyz)'s status on Tuesday, 22-Oct-2024 16:19:03 JST LisPi LisPi
    in reply to
    • clacke
    • wakame
    • Hayley
    @hayley @wakame @clacke I don't quite get why there are so many memes about that.

    As far as I can tell, so long as one actually bothers to question the query analyzer to ensure no indexes are missing & no needlessly expensive operations are used, joins tend to perform just fine.
    In conversation about a month ago from udongein.xyz permalink
  • Before

User actions

    LisPi

    LisPi

    Hi, I'm Lispi, Lisp (Technomancer) Wizard (to eventually be).You might know me from @lispi314@mastodon.top I like Free Software, #Emacs and resilient computing a lot.I also like anime girls, animes with cute girls doing cute things and artwork with them too. Cute stories are good too.Some Pins:Software and Assumed Privilege, common problems: https://mastodon.top/@lispi314/111253066257920146Writing Privacy-preserving software & services 101: https://mastodon.top/@lispi314/110849018589421824#Kopimism #FreeSoftware #CommonLisp

    Tags
    • (None)

    Following 0

      Followers 0

        Groups 0

          Statistics

          User ID
          209694
          Member since
          6 Nov 2023
          Notices
          349
          Daily average
          1

          Feeds

          • Atom
          • Help
          • About
          • FAQ
          • TOS
          • Privacy
          • Source
          • Version
          • Contact

          GNU social JP is a social network, courtesy of GNU social JP管理人. It runs on GNU social, version 2.0.2-dev, available under the GNU Affero General Public License.

          Creative Commons Attribution 3.0 All GNU social JP content and data are available under the Creative Commons Attribution 3.0 license.