IRCaBot 2.1.0
GPLv3 © acetone, 2021-2022
#i2p-dev
/2022/11/18
@eyedeekay
&eche|on
&kytv
&zzz
+R4SAS
+RN
+RN_
+T3s|4
+acetone
+hk
+not_bob
+orignal
+postman
+weko
+wodencafe
An0nm0n
Arch
Coucou
Danny
DeltaOreo
FreefallHeavens_
Irc2PGuest39724
Irc2PGuest53061
Irc2PGuest55294
Irc2PGuest56732
Irc2PGuest80225
Nausicaa
Onn4l7h
Onn4|7h
Over
Sisyphus
Sleepy
SoniEx2
T3s|4_
aargh2
anon3
b3t4f4c3__
bak83
bak83_
boonst
carried6590
cumlord
dr4wd3_
dr|z3d
eyedeekay_bnc
hagen_
onon_1
plap
poriori_
profetikla
r3med1tz-
rapidash
shiver_
solidx66
u5657
uop23ip
w8rabbit
x74a6
NarratorZ Is there any plan to merge i2pd's browser and java i2p's browser?
NarratorZ We may have carried out some duplication of work...
zzz checkin deadline day, translators you have 4 hours to go
zzz I'm writing the news entries
zzz eche|on, eyedeekay, do you have an ETA for MAC bundles I can tell the users? weeks? months?
NarratorZ Another new entry?
zzz NarratorZ, I always write the news around this time
NarratorZ I've checked the Chinese console and it's currently at 100%.
zzz you're a new translator for us, right?
zzz in a few hours, I'll push the news to the "I2P News" resource, and announce it in Transifex. It will be two or three sentences. Your deadline will be Monday.
zzz that's the translation for the news feed you see in your router console announcing new releases and other info
zzz that's the way we do it every release, you can look at past announcements to see how it goes
NarratorZ 😉,Glad to help, I will start translating first time
zzz great, glad to have you on the team
zzz dr|z3d, re: p200, I didn't realize that the package came with CLI support
zzz did you see that there are shell scripts in src/deb/data/usr/share/pack200 ?
dr|z3d zzz: I think I noticed, didn't pay much attention to it. there's also the means to create a deb file and other stuff.
dr|z3d yeah, .deb and .rpm are provisioned, looking at the build.
dr|z3d in fact, they get built when you run mvn package.
dr|z3d does this change your stance on including it in canon? :)
dr|z3d I could probably have saved myself a little bit of time if I'd noticed the build.xml file.
dr|z3d or maybe not, seems like it's doing something slightly different.
zzz it's just a way for you to support building a pack200 updater with java 14+, should you choose to
dr|z3d java -cp /usr/share/pack200/pack200-@VERSION@.jar io.pack200.Driver "$@" seems like it could probably be run directly from ant if you've already got the pack200.jar compiled.
dr|z3d but yeah, well spotted!
zzz sure you could do it that way, or include the scripts, or both, it's just clues to how to go about it since the support is there
zzz I tested basic CLI yesterday, works fine
dr|z3d I've got an elf'd pack200 in /usr/bin/ .. not sure if that would get removed if I uninstalled java < 14, but I guess it would work with later javas while it's present.
dr|z3d still, you didn't answer my question. are you reconsidering your stance on inclusion? :)
zzz certainly not
dr|z3d if you carry on playing with it, the arguments I'm using to get the smallest possible zip file are: --strip-debug --effort=9 --modification-time=latest --segment-limit=-1
zzz if strip-debug loses the line numbers in stack traces, that's going to make it a lot tougher to diagnose problems
zzz yolo
dr|z3d ah, good point. I'll dig deeper, thanks.
dr|z3d -G --strip-debug
dr|z3d Strips attributes used for debugging from the output. These include SourceFile, LineNumberTable, LocalVariableTable and LocalVariableTypeTable. Removing these attributes reduces the size of both downloads and installations but reduces the usefulness of debuggers.
zzz want my crash test jsp?
zzz > cat null.jsp
zzz Integer foo = null;
zzz foo.intValue();
zzz put in apps/routerconsole/jsp
dr|z3d I guess LineNumberTable provides the line numbers in the stack trace, so I'll reinstate debugging stuff.
dr|z3d what's that likely to do?
zzz just tests the error page
zzz when you go /null in the browser. you'll see the stack trace
dr|z3d ah, gotcha. thanks.
dr|z3d I'm working on the assumption LineNumberTable removes the line numbers, so I'm removing the strip-debug arg.
zzz sounds right, you could use /null to prove it, or to test new CSS shenanigans for the error page
dr|z3d thanks, the latter case is handy, sometimes hard to provoke an error to see what's needed to style it, so in the past I've just waited for unforeseen crashes.
zzz perhaps the finest coding in my career :)
dr|z3d oh, yeah, it's up there. definitely chocolate star territory :)
dr|z3d I got a question for you, re UDPSender.
dr|z3d MAX_HEAD_LIFETIME specifically, any reason it's set at 3s. was there any testing to arrive at that value?
dr|z3d and as a followup, does that get overriden by codel targets?
dr|z3d I'm asking because intuitively 3s sounds like an awfully long time for a packet to hang around.
zzz according to git blame, that's from 2012, so it predates codel, and I don't recall reason or testing
zzz it would be large on purpose, just as a failsafe, but probably not necessary now that we have codel
dr|z3d ok, thanks. maybe due for a revisit, perhaps. I'm testing at 1/2 that value right now.
zzz I doubt it ever happens in practice, probably better to remove it and let codel do its thing rather than play with tweaks that are untestable
dr|z3d and yeah, I figured packets would probably get evicted from head long before that max is reached with codel.
dr|z3d ok, so maybe just set it to whatever the codel target is, then?
zzz no, just remove the test completely, it's duplicative of what codel is doing
dr|z3d while ( (_keepRunning) && packet == null ) { then I guess, strips the max_head variable..
dr|z3d oh, wait.
zzz just while(keeprunning)
dr|z3d gotcha
dr|z3d or more like while (_keepRunning) { :)
zzz actually your way is right
zzz wonky jrandom code
dr|z3d never did quite understand value vs _value, but I try and not break things :)
zzz _ prefix is our convention for globals declared at top of class
dr|z3d ah, ok
zzz in java terms, "fields" vs local variables
dr|z3d gotcha, thanks.
zzz Jetty uses the same style but these days it's not very common elsewhere
zzz in i2pd you'll see e.g. m_KeepRunning; in android you'll see a lot of mKeepRunning, seems to be quite common way of doing it
zzz tl;dr just a naming convention, not language syntax
dr|z3d got it, thanks
dr|z3d discovered that variable in pursuit of optimal codelTarget and codelInterval values. it looks like the defaults are impeding throughput, based on "in the field" testing.
dr|z3d I've been using 50/1000 for a while, seems to give better results. 100/1000 I'm about to start testing.
zzz be sure to watch the stats if you're tweaking codel params
dr|z3d yeah, I'm looking at the drops and delays on graphs.
zzz and review the codel papers so you understand what the params do
dr|z3d yup, I think I've got a handle on the values.. I suspect different rules apply to I2P vs normal network operation.
zzz depends where the queues are
zzz some are in places where high latency is expected. the udp sender queue is very much a "normal network operation" queue
zzz where you don't want to tolerate a lot of latency
eyedeekay I am still waiting on Ech to reply to my mail, when he does I know more but for now estimate should be a matter of no more than a month, probably less
dr|z3d I guess that's also somewhat contingent on the size of the queues as well. I'm bumping those up to to test if throughput improves, as well.
zzz eyedeekay, for both x86 and arm? or will arm take longer?
zzz dr|z3d, might be a different stat for tail drop on queue overflow, not sure
eyedeekay Both should take the same amount of time,
zzz ok eyedeekay
eyedeekay I don't foresee any issues with the difference, other than the hardware itself
zzz sure. your answer is based on research on arm mac order/ship and setup time and est. time to decide who gets it?
eyedeekay IMO it will be Echelon, just need to clear that with him
zzz ok lets await his response, let's see if he's as optimistic as you are, given that you're assuming he does a lot but he said he doesn't have a lot of time
eyedeekay Alternative where I do the build and the signing involves him transferring the cert to me
zzz sure
eyedeekay We can do it that way, will just depend on what he says
zzz that's why I proposed you do the build and he does the signing/notarization
zzz which requires two round trips, but might be the quickest solution
eyedeekay If we need to we can do that now, I made it so it's possible for a builder who can't sign to generate an appimage that can be transferred to a signer, used to be they had to happen on the same machine at the same time
dr|z3d apologies if it's a silly question, but is the performance advantage from a native ARM binary for Apple really worth all the extra effort?
dr|z3d I mean, there's a point where good enough trumps absolutely the best performance available.
zzz don't recall but you might find old posts from zab about it on our forum
dr|z3d yeah, I think I recall those suggesting jbigi perf was better natively, but the question is "does it really improve things that much to be noticeable to the end user?"
zzz whether it was or not, we made the decision for it to be an official product, so here we are.
zzz check old meeting logs
NarratorZ Perhaps disguising UDP traffic as TCP is a more obvious improvement
NarratorZ ISP don't like UDP.
zzz this is why I'm so prickly about making explicit decisions about official products and graduating things out of beta
dr|z3d sure, I get that. beta gives you an opt out.
NarratorZ Sorry, I seem to have digressed
dr|z3d UDP disguised as TCP sounds like a job for shadowsocks, no?
NarratorZ shadowsocks is just UDP over TCP
NarratorZ vmess and Trojan also
NarratorZ If we want to fool the ISP,faketcp would be good
NarratorZ NTCP2 is a bit old, we now probably only SSU2 can catch up with times?🤣
zzz a bit old? lololol
dr|z3d a bit old, zzz. :)
dr|z3d we want a new protocol with every release!
zzz we just spent a year replacing 17-year-old SSU with SSU2, the takeaway is to kill our 4 year old child also? this is some House of the Dragon shit
NarratorZ How about introducing libp2p, they also provide the Noise protocol
NarratorZ ssu can use 17 years is not without reason, the firewall on the udp restriction means not much, unless the direct blocking of IP
NarratorZ This doesn't mean that um... We're invisible enough.
NarratorZ Just an idea, I will find time to refine it
eyedeekay libp2p is great at being pluggable, but the best version of it is the Go one, last I checked the Java version was nowhere near as feature-rich
NarratorZ At least TCP and Noise are already supported
zzz we are not tor, we don't have pluggable transports, and we don't make a new transport every 6 months
NarratorZ Ah yes, I don't support pluggable transfers either. This is just stalling.
zzz news pushed to tx
zzz tx CLI will stop working in two weeks. gaaaaah
zzz ok, time to wrap things up
zzz eyedeekay, you ready for a checkin deadline? android and win bundle in good shape?
zzz oh yeah, french/spanish/italian/portuguese go to three plural forms, that's the tx change we avoided last time by a day
zzz let's hope it works
zzz translations pulled and checked in
zzz eyedeekay, holler when you're ok with the checkin deadline
zzz fun fact: this will be the smallest release by lines-of-diff in 7 years
eyedeekay zzz I'm ready, sorry I was stuck doing house stuff earlier
eyedeekay I got the last few things I needed in yesterday though
zzz super, here we go