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 AndresFreundTec (andresfreundtec@mastodon.social)

  1. Embed this notice
    AndresFreundTec (andresfreundtec@mastodon.social)'s status on Wednesday, 22-Jan-2025 07:05:42 JST AndresFreundTec AndresFreundTec
    in reply to
    • LWN.net
    • Jonathan Corbet

    @corbet @LWN Do you see a lot of pointlessly redundant requests? I see a lot of related-seeming IPs request the same pages over and over.

    In conversation about 4 months ago from mastodon.social permalink
  2. Embed this notice
    AndresFreundTec (andresfreundtec@mastodon.social)'s status on Wednesday, 04-Dec-2024 04:30:14 JST AndresFreundTec AndresFreundTec
    • Russ Cox

    @rsc I've not seen a whole lot of progress. A few focused improvements in systemd's dependencies and openssh merged a few improvements. While good, they aren't really anything systemic.

    But perhaps I'm just a pessimistic^Wrealistic grump and not seeing the full picture.

    In conversation about 6 months ago from mastodon.social permalink
  3. Embed this notice
    AndresFreundTec (andresfreundtec@mastodon.social)'s status on Sunday, 20-Oct-2024 02:12:22 JST AndresFreundTec AndresFreundTec

    Does anybody have a recommendation for a decent read-heavy/only "OLTP-ish" database benchmark where the queries aren't just single-table point or range selects?

    Would like to showcase some scalability problems + solution that I see with such queries, but right now it's mostly visible with queries I made up on my own. It's easy enough to make up workloads that show almost anything, so I'd rather use something designed by someone else.

    In conversation about 7 months ago from mastodon.social permalink
  4. Embed this notice
    AndresFreundTec (andresfreundtec@mastodon.social)'s status on Sunday, 26-May-2024 18:19:41 JST AndresFreundTec AndresFreundTec
    • Kevin Beaumont

    @GossiTheDog Hah. This is weird, but not that kind of weird, I strongly suspect.

    Although I wouldn't mind getting that farm.

    In conversation about a year ago from mastodon.social permalink
  5. Embed this notice
    AndresFreundTec (andresfreundtec@mastodon.social)'s status on Sunday, 26-May-2024 18:04:17 JST AndresFreundTec AndresFreundTec
    in reply to

    https://gist.github.com/anarazel/ca7d1db68fb7380d21f6fd819a147df1

    How can two cores on the same CPU such crazily different icache behaviour? For the same process!

    In conversation about a year ago from mastodon.social permalink

    Attachments


  6. Embed this notice
    AndresFreundTec (andresfreundtec@mastodon.social)'s status on Sunday, 26-May-2024 18:04:17 JST AndresFreundTec AndresFreundTec

    Well, color me very confused. In a CPU bound workload two cores on the same socket have substantially different performance (32% slowdown). If I just migrate the running process between the cores, performance changes immediately.

    This is on 2x Xeon 5215 system.

    I checked that it's not thermals, cpu frequency/boost and the system is idle.

    Here's the odd part: The biggest difference evident in perf counters is
    a 2.5x difference in icache_64b.iftag_stall, with ~same icache_64b.iftag_miss.

    In conversation about a year ago from mastodon.social permalink
  7. Embed this notice
    AndresFreundTec (andresfreundtec@mastodon.social)'s status on Thursday, 02-May-2024 03:11:20 JST AndresFreundTec AndresFreundTec

    The "new" Linux CVE approach seems ... unhelpful at best. I know from experience that dealing with security reports is a pain and I assume that's way worse for Linux than for Postgres. But this just seems to purely be aimed at annoying everyone.

    In conversation about a year ago from mastodon.social permalink
  8. Embed this notice
    AndresFreundTec (andresfreundtec@mastodon.social)'s status on Tuesday, 09-Apr-2024 16:25:49 JST AndresFreundTec AndresFreundTec
    in reply to
    • Howard Chu @ Symas

    @hyc @carnildo From what I can tell, the check for permitted algorithms is after RSA_public_decrypt() has already been called, at least on some relevant paths.

    In conversation about a year ago from mastodon.social permalink
  9. Embed this notice
    AndresFreundTec (andresfreundtec@mastodon.social)'s status on Tuesday, 09-Apr-2024 16:23:59 JST AndresFreundTec AndresFreundTec

    @praseodym Hah. I've apparently been doing this stuff for a while.

    In conversation about a year ago from mastodon.social permalink
  10. Embed this notice
    AndresFreundTec (andresfreundtec@mastodon.social)'s status on Tuesday, 09-Apr-2024 03:53:42 JST AndresFreundTec AndresFreundTec
    in reply to
    • Adam Leventhal
    • Bryan Cantrill

    @bcantrill @ahl Now we just need to avoid derailing into a heated debate about solaris/illumos being good/bad...

    In conversation about a year ago from mastodon.social permalink
  11. Embed this notice
    AndresFreundTec (andresfreundtec@mastodon.social)'s status on Tuesday, 09-Apr-2024 03:53:41 JST AndresFreundTec AndresFreundTec
    in reply to
    • Adam Leventhal
    • Bryan Cantrill

    @bcantrill @ahl There might be more agreement on that :)

    In conversation about a year ago from mastodon.social permalink
  12. Embed this notice
    AndresFreundTec (andresfreundtec@mastodon.social)'s status on Tuesday, 09-Apr-2024 03:52:48 JST AndresFreundTec AndresFreundTec

    I did not think that finding a security vulnerability would lead to tabloids digging around my life. Including "analyzing" (aka making things up) the one personal-ish picture I've ever shared on social media. FFS.

    Oddly enough, they weren't interested in lots of kinda pretty graphs.

    In conversation about a year ago from mastodon.social permalink
  13. Embed this notice
    AndresFreundTec (andresfreundtec@mastodon.social)'s status on Thursday, 04-Apr-2024 03:34:26 JST AndresFreundTec AndresFreundTec
    in reply to
    • Kevin Beaumont

    @GossiTheDog I think there are a few people looking into that.

    If I were the team behind "jia", I'd have looked at getting into dissimilar projects, not the same project multiple times, not multiple compression libs. But of course there are other actors...

    The scariest areas I can think of are, in that order, compilers / binutils, buildsystems, "build executors" like make/ninja.

    In conversation about a year ago from gnusocial.jp permalink
  14. Embed this notice
    AndresFreundTec (andresfreundtec@mastodon.social)'s status on Thursday, 04-Apr-2024 01:55:32 JST AndresFreundTec AndresFreundTec

    I am a bit concerned by all the focus on small-ish projects with overwhelmed maintainers. There indeed are a lot of problems in that area.

    But I am certain that lots of experienced OSS devs can think of a few large and crucial projects where they fairly easily could have hidden something small in a larger change. Without a lot of prior contributions to the project.

    In conversation about a year ago from mastodon.social permalink
  15. Embed this notice
    AndresFreundTec (andresfreundtec@mastodon.social)'s status on Monday, 01-Apr-2024 10:03:50 JST AndresFreundTec AndresFreundTec
    in reply to

    One more aspect that I think emphasizes the number of coincidences that had to come together to find this:

    I run a number "buildfarm" instances for automatic testing of postgres. Among them with valgrind. For some other test instance I had used -fno-omit-frame-pointer for some reason I do not remember. A year or so ago I moved all the test instances to a common base configuration, instead of duplicate configurations. I chose to make all of them use -fno-omit-frame-pointer.

    In conversation about a year ago from mastodon.social permalink
  16. Embed this notice
    AndresFreundTec (andresfreundtec@mastodon.social)'s status on Monday, 01-Apr-2024 10:03:49 JST AndresFreundTec AndresFreundTec
    in reply to

    There are more coincidences that are even less interesting. But even the above should make it clear how unlikely it was that I found this thing.

    In conversation about a year ago from mastodon.social permalink
  17. Embed this notice
    AndresFreundTec (andresfreundtec@mastodon.social)'s status on Monday, 01-Apr-2024 10:03:49 JST AndresFreundTec AndresFreundTec
    in reply to

    Afaict valgrind would not have complained about the payload without -fno-omit-frame-pointer. It was because _get_cpuid() expected the stack frame to look a certain way.

    Additionally, I chose to use debian unstable to find possible portability problems earlier. Without that valgrind would have had nothing to complain.

    Without having seen the odd complaints in valgrind, I don't think I would have looked deeply enough when seeing the high cpu in sshd below _get_cpuid().

    In conversation about a year ago from mastodon.social permalink
  18. Embed this notice
    AndresFreundTec (andresfreundtec@mastodon.social)'s status on Monday, 01-Apr-2024 10:03:48 JST AndresFreundTec AndresFreundTec
    in reply to

    Just to be clear: I didn't mean that I didn't do good - I did. I mean that we got unreasonably lucky here, and that we can't just bank on that going forward.

    In conversation about a year ago from mastodon.social permalink
  19. Embed this notice
    AndresFreundTec (andresfreundtec@mastodon.social)'s status on Sunday, 31-Mar-2024 13:19:43 JST AndresFreundTec AndresFreundTec

    I wholeheartedly agree with what Russ wrote here:

    "Also if there's anything the community can do for Lasse personally, please pass that along."

    "Anyone can be the victim of social engineering."

    "I suspect many of us here have had nightmares about being in Lasse's
    position, and probably will have more of them in the future."

    Indeed.

    https://www.openwall.com/lists/oss-security/2024/03/30/25

    In conversation about a year ago from mastodon.social permalink
  20. Embed this notice
    AndresFreundTec (andresfreundtec@mastodon.social)'s status on Saturday, 30-Mar-2024 04:46:54 JST AndresFreundTec AndresFreundTec

    @dgilman Unfortunately I suspect we'll see a lot more such attacks going forward, in all likelihood with more success in some cases.

    In conversation about a year ago from mastodon.social permalink
  • Before

User actions

    AndresFreundTec

    AndresFreundTec

    Long time postgres developer, working at Microsoft.Account about tech, not politics. For the latter look to @AndresFreundPol

    Tags
    • (None)

    Following 0

      Followers 0

        Groups 0

          Statistics

          User ID
          252580
          Member since
          29 Mar 2024
          Notices
          22
          Daily average
          0

          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.