<Pepe>
OpenWrt 21.02 and master comes with LuCI bootstrap by default instead of a new theme OpenWrt 2020?
black_ant has joined #openwrt-devel
black_ant has quit [Changing host]
black_ant has joined #openwrt-devel
goliath has joined #openwrt-devel
<slh64>
Pepe: that's probably the better/ conservative choice for now. there's quite some regression potential involved
<Pepe>
I would say quite opposite, because for me it seems that everyone these days is using OpenWrt 2020 theme instead of bootstrap, which is shipped by default.
<jow>
I am undecided. But wouldn't mind making 2020 the default
<jow>
arguably it's the better choice because it is mobile friendlier compared to bootstrap
<jow>
but people will complain
<Pepe>
People will complain about everything. /s
<jow>
the other problem I see is that openwrt2020 is about three times larger than bootstrap
<jow>
43K vs. 13K
<jow>
that could be fixed by dropping the embedded font
<Borromini>
jow: i do find the traditional theme to be more legible on non-mobile.
<Borromini>
i gave 2020 a shot but quickly reverted
<Borromini>
the color scheme might fit the openwrt colours better but it doesn't improve usability if you ask me
hbug___ has quit [Ping timeout: 240 seconds]
<jow>
the color scheme could be tuned
<jow>
what I (from a maintainer pov) dislike about bootstrap that it is an organically grown big ball of whool
<jow>
and the dropdown menus are annoying
<jow>
hard to tweak for mobile
<Borromini>
ok
hbug___ has joined #openwrt-devel
<jow>
I do like the bright color schema and button style of bootstrap, and I favor them over 2020
<Borromini>
yeah it contributes to usability
<jow>
I could imagine a "bootstrap 2020" theme which would have the bootstrap color schema, button styles, spacing etc. but maybe have a the same left hand side menu
<guidosarducci>
I also reverted after trying 2020, wouldn't want to see it as default.
<ldir>
guidosarducci: thanks for the link!
<ldir>
I've just posted on dnsmasq list.
<ldir>
I think putting the 'block list' in a hash/tree structure and shared memory has to be the answer.
<guidosarducci>
ldir: oh, I hadn't got around to posting to the list yet. Thought you might try it out as well and see if it was clear.
ivanich has joined #openwrt-devel
<ldir>
I haven't posted your link, but I have read it, I certainly get where you're going!
<guidosarducci>
ldir: ok, that's good feedback. I'll post something tomorrow then. "hash/tree in shared mem" is something I worked out a while ago, but never got a chance to follow up. Now that folks are talking about OOM again I'm getting impatient! :)
jas4711 has quit [Ping timeout: 252 seconds]
<ldir>
As I see it there are 3 interlinked problems - large blocklists consuming memory & increasing latency - 1 you can improve memory consumption by optimising the storage of the list, but you still have to store it. 2 You can improve latency by optimising list storage/ordering. 3 tcp requests fork the whole darn thing and so all the structures that could be shared are considered by the OS as private hence potentially requiring 21 * dnsmasq mem to
<guidosarducci>
jow: dnsmasq forks to handle TCP requests
<jow>
disable tcp requests then :)
<ldir>
jow: local tcp requests are handled by a forked copy of dnsmasq
jas4711 has joined #openwrt-devel
<jow>
ldir: that means outgoing DNS requests via TCP made by dnsmasq itselfß
<jow>
?
<ldir>
jow: that's what I'm not too clear on myself - I *think* it's the local clients, but I am woolly on that.
caiortp has quit [Ping timeout: 252 seconds]
<guidosarducci>
ldir: I thought the child also does the request forwarding if not in cache, and that was why they needed a kludge for the child to communicate resolved RRs back to dnsmasq for caching. I might be hazy on things though....
<ldir>
I've been out of it for so long I'm hazy on everything
<guidosarducci>
ldir: email sent, now off to bed! I'm sure Simon will have sorted it all out when I wake up... :-)
<ldir>
ROFL!
<guidosarducci>
ldir: Only half joking really! Simon gets things done...BTW, if you have a sec could you look at a gemini/layerscape/oxnas fix? I noticed those override and disable the BPF syscall, definitely not good for the 21.02 release! https://github.com/openwrt/openwrt/pull/4068
<ldir>
rsalvaterra: will look a bit later - have the plumbers in the house at the mo. Leaky toilet ewwwwwwwwww
<rsalvaterra>
ldir: Ouch, that sucks…
<rsalvaterra>
No, wait, that actually stinks. The plumbers suck. :P
opal has joined #openwrt-devel
dedeckeh has quit [Quit: Connection closed]
hbug___ has quit [Remote host closed the connection]
NameNotFound has joined #openwrt-devel
hbug___ has joined #openwrt-devel
dedeckeh has joined #openwrt-devel
kristrev has quit [Read error: Connection reset by peer]
kristrev has joined #openwrt-devel
victhor has joined #openwrt-devel
dedeckeh has quit [Quit: Connection closed]
dedeckeh has joined #openwrt-devel
NameNotFound has quit [Remote host closed the connection]
Tapper has joined #openwrt-devel
nitroshift has quit [Remote host closed the connection]
NameNotFound has joined #openwrt-devel
deconf_ has joined #openwrt-devel
deconf_ has quit [Quit: Connection closed]
<russell-->
should hostapd and wpa_supplicant be running if all the radios are disabled?
<PaulFertser>
russell--: currently it's the way it works afaik, so yes.
* russell--
is looking to save RAM on a 32MB device
Antoine- has quit [Excess Flood]
<PaulFertser>
I just removed symlinks to wpad.
Antoine_ has joined #openwrt-devel
<russell-->
yeah, i thought of that too, works!
Net147 has quit [Quit: Quit]
Net147 has joined #openwrt-devel
Neighbor11111119 has quit [Ping timeout: 252 seconds]
Neighbor11111119 has joined #openwrt-devel
<karlp>
as an anecdote only, all of our downstream luci pages look horrible in the 2020 theme, but are fine in the bootstrap theme, and I've tried pretty hard to not do anything fancy in them. that's purely my problem though as a downstream
<karlp>
(but very truly, the 2020 one is better on mobile!)
<karlp>
it's almost definitely just my own screwups trying to hack on things and missing some markup I'm presumed to have.
<karlp>
mostly it's just wrong fonts and padding all being different.
<karlp>
I don't really know hwer epepe gets the "everyone's running 2020 anyway" data from at least :)
<jow>
judging from forum screenshots one could get the impression
<jow>
but it obviously depends on the demographic
victhor has quit [Remote host closed the connection]
<jow>
tinkerers in the various linksys wrt firmware threads are more likely to customize (install themes) than people using stock openwrt looking for advice on how to configure wifi
<jow>
personally I don't have any strong opinion about either theme, ideally I'd love to have a mixture of both
<jow>
the somewhat clean (as in code) from-scratch CSS of 2020 with the visual appearance of bootstrap
<jow>
plus maybe the lhs menu
dissonant has quit [Client Quit]
<karlp>
I'm quite ok with just following what's done.
<jow>
and I think 2020 is a better theme to base customizations on
<karlp>
we greatly preferred the look of the bootstrap them to the old "openwrt" theme we used to be based on, but it's just the style of the times :)
victhor has joined #openwrt-devel
<karlp>
and yeah, our more modern pages have been easier to adjust to things than some of the stuff we did years and years ago
<jow>
bootstrap really needs some cleanup (and better mobile support)
dissonant has joined #openwrt-devel
<jow>
karlp: btw, I've been working on templating
<jow>
so soon there'll be no nested E() soup required anymore
<karlp>
oh cool.
<karlp>
I found that realllllly hard to adjust to, it was too specific to openwrt's usecase.
<karlp>
I've not been doign anything recently anyway though, working on new gen hardware right now, not Ui improvements :)
victhor_ has joined #openwrt-devel
victhor has quit [Ping timeout: 252 seconds]
victhor_ has quit [Ping timeout: 246 seconds]
victhor has joined #openwrt-devel
victhor has quit [Ping timeout: 240 seconds]
jas4711 has quit [Ping timeout: 246 seconds]
goliath has joined #openwrt-devel
jas4711 has joined #openwrt-devel
<hurricos>
stintel: Hey, thanks for getting back. Some models don't have the 1Gib NAND, I think there's a particular revision where they abandon it + the switch on the back
<hurricos>
GiB*
<hurricos>
It's a bit of a pain because you cannot actually fit the kernel onto 8MiB :\
<hurricos>
as far as I can tell anyhow
<hurricos>
U-boot takes up a significant chunk
<hurricos>
Yeah I did a binwalk -E of the initramfs I had. It's chunky. Not sure if it's because of extra packages or because of libraries necessary for OpenWrt
<karlp>
jow: just had a bit of a run around, I've got less problems than I rememebered from last time I did it.
<hurricos>
Ultimately the best way to boot it is probably via PCIe
victhor has joined #openwrt-devel
<karlp>
it's little things like <input class="cbi-button cbi-button-add"> not rendering as a button anymore, it's nothing major.
<hurricos>
You should try that instead of anything else -- seriously. You just need to blacklist the liquidio driver and use oct-pci-boot from https://github.com/Hurricos/OCTEON-im8724-SDK
<hurricos>
Or rather, I think oct-pci-boot boots u-boot for you. Ping me back if you want me to upload the compiled u-boot binary somewhere
<karlp>
I've got some radio buttons that don't appear anymore either, but it's very likelyu just shoddy html on our end anyway, not anything I could blame openwrt2020 theme for itself :)
<jow>
karlp: thanks for checking. The <input type="button"> compat is indeed a known issue
<karlp>
that's definitely the most common thing I've noticed.
<jow>
karlp: adding either a class "btn" or using <button> should fix it
<karlp>
the radios are also <input type="radio" without being in a form.
<jow>
but maybe I'll add compat css
<jow>
since it affects so many
<karlp>
I've got one page that's horrible busted, but that's one that I _know_ is a pile of horrible nastiness anyway, so can't complain there too much :) https://imgur.com/a/0UH32q1
<jow>
hmm, yep I see
<jow>
that radio button thing is itneresting though
<jow>
ah but yes, I know why
<jow>
it requires new markup - the actual input is hidden and overlay with a sibling element to allow for actual styling
<jow>
*overlaid
<jow>
if the existing markup does not provide that extraneous element, then it is simply hidden
<jow>
or rather the <input> is simply hidden without anything repalcing it, visually