News for hackers. Stuff that matters.

injinj

I've been running frr (free range routing) for networking, using ospf layer 3 routing between my hosts. This allows dynamic routes to be populated throughout and makes a switched layer 2 network optional, since switches tend to be expensive and obnoxiously loud and a star topology is not necessary with a layer 3 network.

I like the Supermicro Xeon D boards because I can power 6 of them off a single power supply (the GPU cables can be converted to a 4 pin cpu).

I also use systemd-nspawn (w/ dnf --installroot or debootstrap) or docker to attach instances to the network, where each has it's own layer 3 address distributed by frr.

Thanks for the refs.

If I wanted to setup z-library on freenet, an example where reputation could be greatly enhanced by users of the service yet at odds with the legal system. Could the governed outweigh the influence of the government using the reputation system? Sorry for the silly information wants to be free argument, I know you've answered such questions ad inifinitum.

The reputation system is radical departure from freenet. This feels like a google search pagerank integrated with yelp, where you initially buy keywords from freenet.org, like a domain name purchase, and then other users add or subtract from your rating.

The other thing that is different is providing a multicast mechanism to subscribers of a service.

My memory is fuzzy, but I think the original freenet was pull based, where content was replicated around the network closer to the consumers of the data. I believe there was a well known key that signed the static content, so you could retrieve data using natural language. The well known key could be updated to point to any static content, so you could emulate push by polling the well known key and getting the latest version.

The new reputation mechanism must integrate with the subscription multicast in order to limit the abuse of the network. I'd be interested in a description on how this works.

Re:My favorite C compiler flags during development on Sunday April 30, 2023 @06:56AM (#35761406)
That's new. Wow, latest has -mno-omit-leaf-frame-pointer (rpm --eval '%{optflags}')

Do you know of a way to get rpmbuild to keep the -ffat-lto-objects in the ar libs?

It doesn't need a raft consensus algorithm, but corrosion does converge to a consensus, doesn't it? In the OSPF example, that does needs to converge to a state that is consistent and replicated on all the routers, otherwise loops and drops will occur. I'm curious if any convergence benchmark has been done that compares raft to corrosion.
Re:AMD Announces 7950X3D, 7900X3D Upto 128MB L3 Cache on Friday January 06, 2023 @01:15AM (#34271589)
Wow, that's significant. I may have to look into that.
Re:AMD Announces 7950X3D, 7900X3D Upto 128MB L3 Cache on Thursday January 05, 2023 @10:49PM (#34270731)
That's what I got (7950x steel legend), except that I'm running 128GB memory at 4800.

Here's my stream results (with the cpu in 105watt "eco" mode):

  $ wget https://www.cs.virginia.edu/stream/FTP/Code/stream.c
  $ gcc -O3 -fopenmp stream.c
  $ a.out

  Number of Threads counted = 32

  Copy:           45571.7
  Scale:          40672.0
  Add:            45317.3
  Triad:          42759.0
With array size 8,000,000

  Copy:           31551.3
  Scale:          30983.7
  Add:            34403.6
  Triad:          34484.1
Re: on Sunday December 25, 2022 @03:44AM (#34125475)
I can never remember things. That's why my history file has 100k lines in it.

  $ do create linux bridge
  brctl addbr <bridge_name>
  ip link set <bridge_name> up

  $ do git reverse last commit
  git reset --hard HEAD~1

  $ do gcc show optimizations
  gcc -O -Q --help=optimizers
Re:Podman Desktop: A Free OSS Alternative to Docker Desktop on Wednesday November 09, 2022 @05:36PM (#33539067)
Can I use this to manage sudo containers? It's slightly amusing to see the desktop creates a podman daemon, so maybe you could create a sudo podman daemon for use with the desktop somehow?
Re:Disneyland Shanghai shuts over COVID, visitors unable to leave on Wednesday November 02, 2022 @05:16AM (#33433119)
It's sort of a neo-hukou system? A positive covid signal is basically house arrest. Since they do covid tests in batches of 20, it is expected to get false positives.
Re:Disney+ stopped working on each of my Linux machines on Saturday October 29, 2022 @02:56PM (#33386940)
In Firefox, about:config -> general.useragent.override (select string type) ->

Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:106.0) Gecko/20100101 Firefox/106.0

enable drm. Couldn't get it to work in chrome.

Re:Unlaunching the 12GB 4080 on Friday October 14, 2022 @02:03PM (#33206796)
China fomo? Are these good enough to fill the needs of AI workloads of the datacenters which can no longer get the next gen NVIDIA GPUs?
Re:Ask HN: What did Linux not do right? on Sunday October 02, 2022 @07:36AM (#33055030)
Probably a stable driver api. It was always a challenge upgrading with offbeat hardware, and the GPUs were always a pain in the butt.
Re:MQZiti – Zero Trust MQTT server and client on Thursday August 25, 2022 @06:31PM (#32600774)
Ok, thanks. The Ziti mesh optimizes for latency. Does it move existing streams around the fabric mesh when it finds a better route or only new streams? Are there plans for multicast?
Re:MQZiti – Zero Trust MQTT server and client on Thursday August 25, 2022 @06:03PM (#32600513)
This implies that Ziti layers the stream endpoints on top of a packet switched network, which could mean authentication of each packet and maintaining stream reliability in a different way than TCP does. Is that correct?

edit, this is what I'm looking for: https://github.com/openziti/fabric/blob/main/docs/p12_smart_...

Re:Time-Series Compression Algorithms on Sunday May 15, 2022 @06:55AM (#31386731)
I didn't see binary interpolative coding (BIC) referenced. It is one of my favorites introduced to me by the book "Managing Gigabytes" by Moffett and Bell [1]. It has great compression ratio for sequences and is commonly used in inverted indexes.

There is neat implementation [2] and technical paper [3] by Giulio Ermanno Pibiri, which I just found today by looking for it.

[1] https://people.eng.unimelb.edu.au/ammoffat/mg/

[2] https://github.com/jermp/interpolative_coding

[3] http://pages.di.unipi.it/pibiri/papers/BIC.pdf

FWIW, I'm happy to sponsor both, they innovate in different ways. Chess.com with their content sponsorship and deep player pools, lichess with ad-free, open source and unique UI features.
Re:Fish 3.4.0 on Sunday March 20, 2022 @06:35PM (#30747446)
Es global meetup 2022! I'm down. BYOW.
Re:Fish 3.4.0 on Sunday March 20, 2022 @02:31AM (#30740618)
Yay, another es shell user!
It looks like the input word is using lodsd instruction, loading a 4 byte word, instead of a ptr increment, which could cause a 3 byte oob read if the last byte was at address 1.

I believe this is used in millions of builds, since it's been around for 20 years and Windows has a culture of winzip style software not packaged by Microsoft, but a lone programmer trying to get by with donations.

Do you have a specific exploit description? Mark Adler can remove or mark it unsafe on the github repo given a reason.

Re:Drop-In Replacement for Memcached on Monday December 13, 2021 @08:17PM (#29546985)
A wireshark capture shows that memcrsd is breaking up the response packets, not optimizing network, sending a lot more packets than memcached. With the 100 byte size, memcached is packing 10 PDUs per packet and memcrsd is doing 1.

Using memtier_benchmark --pipeline=1 with "memcached -t 1" and "memcrsd -r 1" shows almost identical results (141943 vs 136550) on my machine (keys 1 -> 100000). The network is where most of the CPU is spent in both memcached and memcrsd cases.

I'm slightly impressed with memcrsd/rust scaling, 32 runtimes with 16 memtier_benchark threads with pipeline=9 can produce 4 million ops/sec. They need to fix the networking parts.

I think most will use horizontal scaling anyway, and simply shard the memcached's and skip the threading concurrency. Multiple memcached's with client side sharding is hard to beat.

Re:Show HN: 10-40% faster LZMA decoder using x86 CMOVcc on Monday December 13, 2021 @04:23PM (#29544844)
Decent speedup on my 3970x. Including this patch reduced the number of instructions in lzma_decoder.s (using gcc 8.3.1) by about 8% (4417 lines of asm vs 4824). With perf stat, an astonishing branches-missed reduction from 409K to 104K.

Using the firefox example from the gist:

  $ tar -cJf lib.tar.xz /usr/lib64/firefox
The xz shipped from the system:

  $ perf stat xz -c -d lib.tar.xz > /dev/null                                                                               

  Performance counter stats for 'xz -c -d lib.tar.xz':

          4,650.32 msec task-clock:u              #    1.000 CPUs utilized          
                 0      context-switches:u        #    0.000 K/sec                  
                 0      cpu-migrations:u          #    0.000 K/sec                  
               591      page-faults:u             #    0.127 K/sec                  
    19,849,912,300      cycles:u                  #    4.269 GHz                      (83.33%)
       425,290,878      stalled-cycles-frontend:u #    2.14% frontend cycles idle     (83.33%)
     1,831,640,390      stalled-cycles-backend:u  #    9.23% backend cycles idle      (83.34%)
    23,973,036,103      instructions:u            #    1.21  insn per cycle         
                                                  #    0.08  stalled cycles per insn  (83.33%)
     2,939,144,233      branches:u                #  632.031 M/sec                    (83.34%)
       409,371,860      branch-misses:u           #   13.93% of all branches          (83.33%)

       4.650679926 seconds time elapsed

       4.611657000 seconds user
       0.011931000 seconds sys
The xz patched.

  $ git clone http://git.tukaani.org/xz.git
  $ cd xz/src
  $ patch -l -p1 < ../faster_lxma_decoder_x86.patch
  $ cd .. ; autogen.sh && configure && make
  $ LD_PRELOAD=./liblzma/.libs/liblzma.so
  $ perf stat ./xz/.libs/xz -c -d ../../lib.tar.xz > /dev/null                                                              

  Performance counter stats for './xz/.libs/xz -c -d ../../lib.tar.xz':

          3,578.54 msec task-clock:u              #    1.000 CPUs utilized          
                 0      context-switches:u        #    0.000 K/sec                  
                 0      cpu-migrations:u          #    0.000 K/sec                  
               593      page-faults:u             #    0.166 K/sec                  
    15,186,685,715      cycles:u                  #    4.244 GHz                      (83.32%)
       108,663,507      stalled-cycles-frontend:u #    0.72% frontend cycles idle     (83.32%)
     8,753,057,119      stalled-cycles-backend:u  #   57.64% backend cycles idle      (83.34%)
    27,322,182,837      instructions:u            #    1.80  insn per cycle         
                                                  #    0.32  stalled cycles per insn  (83.35%)
     1,979,944,734      branches:u                #  553.282 M/sec                    (83.34%)
       104,752,154      branch-misses:u           #    5.29% of all branches          (83.34%)

       3.578973194 seconds time elapsed

       3.549329000 seconds user
       0.011942000 seconds sys
Re:QOI: Lossless Image Compression in O(n) Time on Wednesday November 24, 2021 @05:45PM (#29336075)
I believe libpng default zlib compression level is 6. libpng may use CRC (or adler) checksums, which account for around 30% of the decode time. In my experience with zlib, the higher compression levels have faster decode times. My reasoning at the time was (early '00s) that higher compression tends to code longer runs of copying of the dictionary. More time in the copy loop rather than the input and decode loop.
Re:Incident Response to September 20th 2021 on Tuesday September 21, 2021 @04:38PM (#28609618)
It does appear the "Node ID" section covers this issue, with the requirement that the public key back up the 40 bit key fingerprint.

What if the controller had a timer that could be set such that the network becomes static and unchanging when it expires?

Re:Ivermectin Systematic Study: Inconclusive on Friday August 06, 2021 @06:39AM (#28085368)
> people who view science through obtuse political lenses

It's not really that surprising. Prescribing Opioids like candy, outlandish prices for things like Insulin, bankrupting poor and uninsured for end of life treatments, covering up the gain of function research funded by the NIH, censoring all kinds of stuff, beginning with their President and probably a few of their friends. I'm sure some of those anti-vaxxers have friends who had COVID and came through it ok. And now, trust us, take this experimental vaccine without any backup plan in case it has adverse effects lasting a couple of weeks. Loss of work, maybe a hospital bed to pay for, etc.

The vaccine would better tolerated with a national health care plan and letting people take Ivermectin if they want it. At the moment, CVS won't fill a Ivermectin prescription, even though it quite safe, but they will fill up your pain pills no problem. I do think that the vaccine is marvelous, but I'm not naive to the failings of our medical system.

If SARS-COV2 has the ability to evolve really quickly, we have little chance to defeat it with vaccines and natural immunity. Cross fingers for lab-made virus.
I remember downloading and compiling Mosaic and thinking that this is stupid. A glacially slow way to display text with links and graphics, who's going to want that? Why not display text as it was meant to be displayed, on a terminal.

I still think there will be a return of peer to peer eventually, since every pocket has a computer capable of computation and bandwidth unimaginable back then. The ultimate form of data privacy is when you control the power plug.

Re:Show HN: Embedded Ring Buffer C++98 on Monday June 07, 2021 @05:27AM (#27420608)
One thing I found useful is instead of

  volatile T member;

  T access( void ) { return member; }
Use volatile on the functions instead:

  T member;

  T access( void ) volatile { return member; }
This has causes all access to this-> within the function to be volatile, including read_position, write_position, overrun_flag and data[].

When inlining these functions within other parts of the code, the compiler can hoist reads into registers from the non-volatile members unless you add the compiler barrier that @ghhhhhk8899jj mentioned.

Re:80M I/O Per Second with a Standard 2U System on Friday May 28, 2021 @12:47AM (#27311828)
That looks close to the maximum rate of an optane 5800x... 1.5 million 4k iops * 16 devices = 24 million 4k iops. It also looks close to the maximum of pcie4, 16 * 7.8GB / 4K = 32M > 25M.

Older »