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?
NarratorZ
yes
zzz
ok
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?
dr|z3d
sure
zzz
> cat null.jsp
zzz
<%
zzz
Integer foo = null;
zzz
foo.intValue();
zzz
%>
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
yeah
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
dr|z3d
ok
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
yeah
NarratorZ
NTCP2 is a bit old, we now probably only SSU2 can catch up with times?🤣
zzz
a bit old? lololol
dr|z3d
haha
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
dr|z3d
haha
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