<samueldr>
I guess not; once the kernel is booted, it goes to /init, as expected, here it's a shim busybox sh script to add console multiplexing, and then it execs directly into an mruby interpreter that has the boot script compiled-in
<samueldr>
(the shim script is also useful to e.g. strace or do funny console redirection of the real init)
<samueldr>
and the script? it basically has tasks, and tries to run all tasks, with some dependency management
<ashkitten>
samueldr: by the way, is there some sort of power management system available so apps running won't drain the battery like hell while the screen is off?
<samueldr>
not investigated yet
<ashkitten>
gotcha
<emily>
samueldr: nah, just post-kernel, sorry for the latency :)
<emily>
right, I was just curious about what the generation selection UI was like
<ashkitten>
i'm thinking worst case i write a script that sends SIGSTOP to most things and disables the big cores
<emily>
how is mruby? I'm procrastinating on deciding between nginx+openresty+lua and h2o+mruby for my personal site lately
<emily>
frankly I hate both Lua and Ruby in different and variegated ways.
<samueldr>
I'm not sure how to compare them as an embedded runtime
<samueldr>
when I was using lua, it was about using lua, not writing bindings
<samueldr>
and the few interops I made were using LuaJIT's FFIs
<ashkitten>
lua is apparently very flexible and can be used with basically any programming pagadigm
<samueldr>
yes
<samueldr>
it has few built-in things, few types
<samueldr>
the only "complex" type is table, which is both a "dict" and a "list"
<ashkitten>
the main issue i have with it is the difficulty in writing safe bindings for rust
<samueldr>
and in turn the table can have a "metatable" which can be used to, in lua, augment the behaviours of the table
<ashkitten>
i'd really like to see a native lua runtime in rust
<samueldr>
though here the main real reason for mruby is because I needed something that built small static binaries, in not-c, with a sane stdlib
<samueldr>
and as I am already proefficient with ruby, and mruby was simple to get going, 1+1=poc
<ashkitten>
how's crystal compare to that?
<samueldr>
I forgot about crystal
<samueldr>
so I didn't look :)
<ashkitten>
i've never used either but i knew about crystal
Synthetica has quit [Quit: Connection closed for inactivity]
<ashkitten>
i think someone is rewriting some mastodon stuff in crystal
<samueldr>
oh, and one hard part is that it needs to cross-compile
<samueldr>
this limited some options I had
<ashkitten>
i think rust is a good choice given the stated parameters but i'm biased of course
<samueldr>
I also think it would be, before going mruby I looked if it cross-compiled, it did not
<ashkitten>
cross compile to what?
<samueldr>
though I might have not liked being slowed down by learning it while writing the thing :)
<samueldr>
using nixpkgs' pkgsCross.aarch64-multiplatform
<ashkitten>
i see
<samueldr>
yeah, I should have been more careful in the wording: "in nixpkgs" :)
<samueldr>
challenges for later
<ashkitten>
rust can definitely cross compile, i don't know if anyone's built around that in nixpkgs
<samueldr>
yeah
<ashkitten>
i was running rust code on a trinket m0 a while ago, was pretty neat. there's a really robust embedded ecosystem
<samueldr>
luckily we don't need to go embedded :)
<samueldr>
the requirements are weird, stage-1 needs to fit in 8MiB compressed initramfs... but has 2+ GiB of ram to work with
<ashkitten>
i think the coolest part about running rust on embedded is leveraging the type system for safety and speed. instead of checking state at runtime, you can build your state machine into the types themselves
<ashkitten>
there's even special mutex types in the embedded crates that only allow you to lock them inside a critical section so there's no chance of deadlocking on an interrupt, which is more than the standard library mutex can guarantee
<emily>
imo rust is not ideal for UIs these days because no good qt bindings, though I hear the gtk support is great and probably works fine in the nixos context
<emily>
(also like, Rust is definitely lower level than you need, you could write this whole thing in QML's JavaScript stuff probably.)
<samueldr>
that early boot UI is driven using LVGL, will probably need bindings unless they get written in the meantime
<emily>
(there's no phone on the planet where the language choice you use for the bootloader would be a prohibitive factor.)
<samueldr>
yes
<samueldr>
8MiB for the whole initramfs :)
<emily>
(ok maybe like... if you write your bootloader in Pharo/Squeak Smalltalk... that wouldn't be great. I professionally recommend against doing that.)
<samueldr>
so the whole runtime closure has to be kept slim
<emily>
/init that just loads Guile from disk and then unleashess the raw unparalleled power of GNU Guix
<emily>
(disclaimer: I've never even used Guix and it looks cool so this shitpost is not intended as a dig)
<ashkitten>
i haven't touched qt in rust but i hear the gtk bindings are really awful, mostly because gobject is a complete mess to write bindings for in any language
<samueldr>
oh dang, I hadn't realized, but keeping it that slim may allow it to fit in the SPI flash of the PBP :)
<samueldr>
emily: there sure is something "romantic" about having one runtime/language for the whole system
<emily>
yeah
drakonis_ has joined #nixos-chat
<emily>
I have no particular attachment to Unix's awful bytestring pipes and ioctl hacks, I just don't think Scheme specifically is It™ for me, and it's not worth it to go in on some totalizing system if I don't like the foundation.
<emily>
so that I'd prefer Nix to Guix is my current guess at least but I haven't actually tried it to find out yet.
<samueldr>
I sure would like some kind of deeper object passing
<emily>
also guix sd would probably just be insufferable to use for ideological reasons.
<emily>
having to package the non-free software I'm saddled with sounds like a nightmare.
<samueldr>
I do wonder about running nix on haiku sometimes... but then I remember... phones
<emily>
samueldr: you can pass an fd over a unix socket and it kinda sorta works!
<emily>
it's not ideal but what in unix is :/
<ashkitten>
is nix heavily dependent on posix?
drakonis has quit [Ping timeout: 240 seconds]
<samueldr>
I would assume haiku is posixly enough for nix, without looking
<samueldr>
I think it's working (again) in FreeBSD, and let's not forget Darwin
<ashkitten>
darwin is pretty posixy right?
<samueldr>
ye
<samueldr>
yes*
drakonis has joined #nixos-chat
<ashkitten>
i wonder if i'll ever get back to trying to get nix working on netbsd
<ashkitten>
i stopped because i got distracted, i was just having issues compiling it at that point
<samueldr>
I *think* the freebsd-nix folks started with issues compiling, too
<samueldr>
I really don't know what's up now
<ashkitten>
idk, i was just following the compilation instructions and got bored
<ashkitten>
didnt spend much time on it
drakonis_ has quit [Ping timeout: 240 seconds]
<ashkitten>
i've never really used netbsd, anyways, and i'm happy with linux for the moment
drakonis has quit [Ping timeout: 240 seconds]
drakonis has joined #nixos-chat
<gchristensen>
samueldr: I guess instead of trying to do the fancy thing (swappable profiles at boot time) I'll do the easy thing and just make a different netboot image with a 3 byte diff
<samueldr>
:)
<elvishjerricco>
There are rumors about Apple switching to ARM in their laptops. I wonder how hard / crazy / stupid it would be to also package some usually-idle x86_64 cores in there to run apps that haven't been ported.
<samueldr>
the rumor has about as much strenght it had in 2012
<samueldr>
strenght*
<samueldr>
errr
<gchristensen>
elvishjerricco: can you imagine trying to IPC across archs? :D
<samueldr>
yes, they have a strong ARM platform, but not a desktop operating system for ARM
<samueldr>
unless they did like for x86_64 and kept it building and running internally for years
<samueldr>
but in these times of leaks, it would have been leaked :/
<elvishjerricco>
samueldr: Well iOS shares quite a bit with macOS fwiw
<samueldr>
though, I figure they'd it like microsoft are, and run it throug emulation
<samueldr>
yes, I do know
<samueldr>
basically the same underlying OS, but once you leave the foundations it's not the same
<elvishjerricco>
Forget apple then. Just in theory, it's a fun idea :P
<samueldr>
I would be (somewhat pleasingly) surprised if they kept their whole macOS systems somewhat non-x86-flavoured
<samueldr>
oh, yes
<samueldr>
x86_64 as a "compute unit"
<samueldr>
like you do with cuda cores and whatnots
<samueldr>
that sure would be fun
<ashkitten>
that's just a xeon phi
<samueldr>
and there's nothing wrong with that :)
<elvishjerricco>
But like with the ability to just run an x86_64 program transparently.
* elvishjerricco
googles xeon phi
<ashkitten>
it's a pcie card with a bunch of pentiums stapled on
<samueldr>
wondering if the classic-like approach they had during 10.1~10.4 could apply here
<samueldr>
run a full x86_64 OS, and share windows through the ARM-side compositor
<samueldr>
ashkitten: oh, I thought it was a bunch of atoms
<ashkitten>
idk, might be
<ashkitten>
i thought it was modified pentiums
<samueldr>
could be
<samueldr>
though there were multiple versions
<elvishjerricco>
That is really weird and interesting
<ashkitten>
> run a full x86_64 OS, and share windows through the ARM-side compositor
<{^_^}>
error: syntax error, unexpected ',', expecting ')', at (string):281:21
<ashkitten>
wouldn't that be possible with spectrum-os?
<samueldr>
maybe?
* elvishjerricco
googles spectrum-is
<samueldr>
yeah, the original was pentium-based, from their "failed" attempt at making a GPU, and the later model was atom-based
<ashkitten>
cole-h: jesus christ i was so surprised when i saw that image at the top of the article because it looks exactly like something i made for an older website... the code in the image is different though
<samueldr>
though tbf it should be relatively trivial to do that bit, usb gadget + rndis
<cole-h>
ashkitten: I would be shocked if the code was the same because it's directly from their codebase lol
<ashkitten>
right
<ashkitten>
but it uses the same zoom blur effect and the same code highlight colors
<elvishjerricco>
samueldr: Wait how does it run on a different computer through the USB port?
<samueldr>
elvishjerricco: it's an arm sbc
<samueldr>
power from usb port
<samueldr>
rndis usb gadget for networking
<samueldr>
vnc over the sbc
<samueldr>
is it too condensed?
<elvishjerricco>
Ah, so the mac is still running
<samueldr>
yes
<elvishjerricco>
And just kinda thin clienting to the stick
<samueldr>
exactly
<elvishjerricco>
Anyway it doesn't seem that much smaller than a Pi Zero, if any
<samueldr>
though preceding it by a year, for the release
<elvishjerricco>
Ah
<samueldr>
and a bit more for development
<samueldr>
not sure how the cpu compares, but considering it's an exynos cortex-A8 vs. the lowly broadcom armv6 in the zero, it's also likely better
<samueldr>
if an aarch64 variant of the pi zero, with the same footprint, existed that would be DIYable
waleee-cl has quit [Quit: Connection closed for inactivity]
<emily>
02:06 <ashkitten> though there's probably something that lets you do wayland over the network...
<emily>
I think a wayland xpra port is potentially in the works?
<emily>
xpra is pretty great as a replacement for X forwarding
<ashkitten>
hmmm so reading the solokey thing, i didn't realize there was a difference between the hacker version and the non-hacker version. apparently the hacker one allows you to run unsigned code, but i wonder if it's possible to make it only run signed code (from a designated signing key)
<cole-h>
This is a SoloKeys discussion channel now 👀
<samueldr>
don't worry, it'll soon come back to its regular topic of actually questions that should go on the on-topic channels
<cole-h>
:d
<ashkitten>
lol
<gchristensen>
lol
drakonis has joined #nixos-chat
<cole-h>
When your answer gets marked as the solution on discourse
<cole-h>
:D
<qyliss>
elvishjerricco: OpenGL passthrough Will probably be allowed.
drakonis1 has joined #nixos-chat
<qyliss>
samueldr, ashkitten: crosvm (the Chromium OS hypervisor) probably could emulate different architectures and provide seamless windowing.
<qyliss>
It might need some modifications to do that, but if so they wouldn't be very big.
<ashkitten>
that's good
<ashkitten>
that's one advantage spectrum would have over nixos :p
<qyliss>
(Much smaller than the modifications I'm currently making to allow virtual devices to run in their own VMs)
<qyliss>
ashkitten: it would be possible to do this on NixOS too
<ashkitten>
ah right
<qyliss>
You just need to be able to run crosvm
<qyliss>
(Which is already in Nixpkgs)
<qyliss>
You also need some other components, which are not currently in Nixpkgs, like a Chromium OS kernel and the corresponding userspace program that runs in the VM
<qyliss>
At some point I will try to upstream a chunk of https://spectrum-os.org/git/nixpkgs and then all of this should be possible on NixOS.
<qyliss>
With NixOS VMs, even. (With a custom kernel.)
<ashkitten>
neat!
<ashkitten>
i'm looking forward to running spectrum on my machines tbh
<drakonis1>
same
<qyliss>
Reminder that there's #spectrum :)
<cole-h>
So, at a brief glance, and being unfamiliar with both, Spectrum looks similar to Qubes. Am I wrong in making that assumption?
<qyliss>
Yes, Spectrum is very directly inspired by Qubes
<qyliss>
Specifically, by my frustrations with managing a Qubes system
<qyliss>
cole-h: the American equivalent is the Open Tech Fund
<qyliss>
But I hear that's rather more bureaucracy
<cole-h>
I haven't heard of either :D Either way, that's really cool. Bookmarked, to come back to at a later date
* cole-h
adds #spectrum to autojoins
<cole-h>
And samueldr thanks for the link, watching it now
<cole-h>
(and by "watching it now" I mean watched for 2 minutes and then got distracted)
drakonis_ has joined #nixos-chat
<cole-h>
I wish it was possible to specify a cursor position in PR templates so I didn't have to cut-paste my commit message to under the `motivation` header every time.
<qyliss>
Yes :(
<qyliss>
We could just drop the header
<qyliss>
Or replace it with <!-- Please describe the motivation for your pull request above this line --> or something
<qyliss>
If we do need some sort of nudge
<cole-h>
I really wish it was possible to disable the auto-linking to issues/PRs when using the pound sign
<qyliss>
Yes that too.
<cole-h>
I just pinged nixpkgs#45 twice because I was trying to specify RFC #45 in my commit message and was force-pushing :D
<qyliss>
fwiw it doesn't actually notify anything about that PR
<qyliss>
so it only matters if somebody looks at it
<qyliss>
And I doubt many people are looking at that PR :P
<cole-h>
Oh really? Great.
<samueldr>
auto-linking isn't the issue, linking is
<samueldr>
oops
<samueldr>
auto-linking isn't the issue, notifying is
<samueldr>
right?
<qyliss>
It is still annoying that it gets linked in the other direction.
<samueldr>
yeah, I add that as part of the notification
<cole-h>
Both are tbh. I hate seeing unrelated issues/PRs in unrelated issues/PRs as a result of me using the pound sign
<cole-h>
GitHub pls :'(
<samueldr>
#coolsoftwareallowsuseofhashtags
* samueldr
hates himself
<cole-h>
You're not wrong tho
<samueldr>
that was a horrible thing to say
<cole-h>
Isn't flake syntax nixos#nixpkgs now?
<gchristensen>
lol
<drakonis_>
it is, yes.
<cole-h>
Point proven
<cole-h>
;d
<samueldr>
how?
<samueldr>
that's not a hashtag, it isn't #winning or #inanestuff
<samueldr>
:)
<cole-h>
I should have seen that coming, as a fellow pedant
<drakonis_>
#letsdipPRsbeneath1700
<drakonis_>
i tried
<cole-h>
Unrelated, but: what is the formal name for the `{ pkgs, lib, ... }:` at the top of Nix files?
<samueldr>
you're focusing again on something that cannot really be done, and would only be delaying the inevitable
<samueldr>
not all PRs are mergeable
<samueldr>
,callPackage
<{^_^}>
If a Nix file foo.nix starts with something like `{ stdenv, cmake }:`, you can build it with `nix-build -E '(import <nixpkgs> {}).callPackage ./foo.nix {}'`
<samueldr>
hm
<cole-h>
Just delete and recreate NixOS/nixpkgs :D
<sphalerite>
gchristensen: well, depends what kind of extra monitor(s) you have…
<gchristensen>
sphalerite: I'm not hurtin g:P
<srk>
huh, es2gears is even slower at 5 FPS
<srk>
ah, it's compiling in background
<samueldr>
is this a phone or a laptop?
<samueldr>
(or just an sbc?)
<samueldr>
oh wait, imx_6_, don't mind me
<srk>
still 5 FPS
<srk>
samueldr: it's novena laptop
<samueldr>
oh, neat
<srk>
yeah, it runs graphics after like 5 headless years
<srk>
only needs 3 patches on top of mainline now :D
<srk>
hmm, opengl renderer string: llvmpipe
<srk>
that's not quite right I guess
<samueldr>
part of the problem, I see :)
<samueldr>
not sure where to go from there
<srk>
pff
<srk>
asking around and googling :)
<srk>
and debug output of sway or something
<yorick>
viric: oh yes, it was very fast on your 800x600 screen
<yorick>
samueldr: with wayland the compositor logic is moved to a library and the window manager links to that, yes
<yorick>
at least, that's the hope
<gchristensen>
okay cool, updating wlroots to an unreleased, random commit worked
drakonis_ has joined #nixos-chat
drakonis has quit [Ping timeout: 240 seconds]
psyanticy has quit [Quit: Connection closed for inactivity]
<srk>
uu, it works with weston.. GL renderer: Vivante GC2000 rev 5108
<viric>
yorick: yes, 800x600.
<viric>
do you think that's what mattered?
drakonis has joined #nixos-chat
drakonis_ has quit [Ping timeout: 240 seconds]
drakonis has quit [Ping timeout: 240 seconds]
waleee-cl has joined #nixos-chat
drakonis_ has joined #nixos-chat
drakonis_ has quit [Ping timeout: 260 seconds]
drakonis has joined #nixos-chat
drakonis has quit [Ping timeout: 260 seconds]
drakonis has joined #nixos-chat
<colemickens>
What webcam do y'all use in Linux? The cheapo Logitechs I have aren't configured by Linux properly by default (and was very difficult to get configured correctly even with ffmpeg/mpv), and I need to start getting some stuff setup for a proper remote/streaming work setup.
<colemickens>
cc: gchristensen since it seems like you mention conferencing/zoom a fair amount
drakonis has quit [Ping timeout: 248 seconds]
<eyJhb>
colemickens: I use Logitech Webcam C920 and it has worked quite fine
<samueldr>
caution!
<samueldr>
apparently the c920 has been hardware-revised and features dropped
<samueldr>
but I sure hate it when a model number stays the same but it becomes something else
<cransom>
the 'we silently dropped a feature and passed the savings back to ourselves' is a little infuriating.
<samueldr>
in the consumer-routers world, you can often see a model number changing platform entirely
<samueldr>
like not the same SoC, not even the same Architecture
<andi->
naive me: I wonder how they verify they work the same :-)
<samueldr>
routers?
<samueldr>
they don't, in my experience there is a small print version number somewhere and it's actually a different sku
<samueldr>
but the consumer-facing model name is the same
<joepie91>
andi-: "verify"? what are you talking about :)
<andi->
I am very much aware of the fact what they do or rather don't.. I just wish they'd have these thoughts
<andi->
because then I could accept them swapping for a cheaper platform if it does the *same*
<samueldr>
it does the same
<samueldr>
here, it's written on the marketing copy
<samueldr>
"1080p webcam"!
<yorick>
viric: yeah, I think a 12x increase in pixels might cause some slowness
drakonis has joined #nixos-chat
<viric>
yorick: I recently started a recent nixos in a 2006 laptop, RADEON xorg driver, with its own 1024x768 screen. It painted terribly slow.
<viric>
It = xterm, I mean
<yorick>
viric: that would be interesting to debug
<yorick>
might be Wirth's law
<yorick>
(Moore's Law: every few years, software will use Moore resources for inexplicable reasons)
<joepie91>
as one of the lag-behinds who stuck with running their OS off a HDD until very recently, I've noticed that over the past 5 years or so, disk access patterns of a lot of software seem to have become incredibly inefficient, presumably because the developers of the software are now testing on SSDs and no longer experience the lag induced by bad access patterns
drakonis has quit [Ping timeout: 272 seconds]
drakonis has joined #nixos-chat
<DigitalKiwi>
for some reason works on my (relative to most people really powerful) machine has become all too standard
<DigitalKiwi>
see the trend of everyone using electron...
<joepie91>
DigitalKiwi: Electron is actually not a good example here :P
<joepie91>
JS-laden websites are a better example
<DigitalKiwi>
who needs to run more than one app
<joepie91>
(developers working on Electron stuff generally know that Electron sucks, but there's no real good alternative that ticks all the boxes)
<DigitalKiwi>
i mean somehow people have managed to make apps for the last umpteen years without electron
<DigitalKiwi>
and isn't a an electron app a js laden website ;P
<joepie91>
no..
<joepie91>
and "managed to" ignores the point here
<joepie91>
you can give people a Commodore 64 today and they can "manage to" build software
<DigitalKiwi>
they literally embed a chromium and node.js in every electron app
<joepie91>
doesn't mean that it's considered in any way acceptable considering all the UX, business and technical requirements
<DigitalKiwi>
it's a locally running js laden website
<DigitalKiwi>
it's *worse* than what you're talking about
<DigitalKiwi>
since it also has to run an extra chromium
<DigitalKiwi>
and server
<joepie91>
it isn't running a "website", and I don't feel like you're really trying to understand my point here
<joepie91>
no, Electron apps do not have a "server" unless the developer makes it spin up one
<joepie91>
look, I know this ecosystem, I know how this shit works, I know why people use it
<joepie91>
it might be worth giving me the light of day
<DigitalKiwi>
node.js is not a server?
<joepie91>
no.
<DigitalKiwi>
coulda fooled me
<DigitalKiwi>
since that's what they advertise it as...
<joepie91>
Node.js is a JS runtime.
<joepie91>
a headless one.
<joepie91>
just like CPython isn't a server, and gcc isn't a server
<joepie91>
DigitalKiwi: who is "they"?
<DigitalKiwi>
run js in the browser and the server let your developers use the same language for both!
<drakonis>
ughh nix isnt bandwidth friendly
<drakonis>
i'm tight on bandwidth and internet speed
<joepie91>
that is certainly something you can do, *if* you are building a server in Node.js. but again, who is "they"?
<DigitalKiwi>
i don't care
<joepie91>
because the Node.js homepage quite clearly says "runtime", no mention of "server" anywhere
<joepie91>
yeah, so see, this is the problem, this is how this sort of thing always goes - complaining about JS-shaped things and then when being told that something is not accurate, suddenly "not caring" about the thing they were taking the time to complain about just a moment ago
<samueldr>
node.js is a server as much as ruby and python are
* joepie91
does not have patience for this sort of bashing
<joepie91>
if you have legitimate criticism, fine. but if you just want to rip on something for the sake of it, please do that elsewhere.
<DigitalKiwi>
fine, it's not a server, it's a piece of software normally ran on a server that instead electron apps run on your machine
<DigitalKiwi>
fucking pedants
<colemickens>
😕
<samueldr>
DigitalKiwi :(
Jackneill has joined #nixos-chat
drakonis has quit [Ping timeout: 240 seconds]
<samueldr>
may I remind you that, even through frustration, we try to elevate the discourse here with our language?