* gchristensen
looks at gnu's image manipulator which can barely open a file without losing data
<gchristensen>
oh cool
<samueldr>
with it you can select nodes you want to remove
<samueldr>
hopefully that insight helped
<samueldr>
you could also use addition and subtraction to "fixup" issues
<gchristensen>
yup that is really helpful
<gchristensen>
I didn't know I could select a box of nodes
<gchristensen>
I'm trying to change this to make me look a bit happier and it is maybe just comical :D
<samueldr>
blaaaargh, it is so hard to "just" change the user's wallpaper in so many desktop environments
<samueldr>
or even better, the default
<samueldr>
(e.g. only if unconfigured by the user)
<samueldr>
and in some it looks like the only way is "get yourself a real FHS, kiddo"
<gchristensen>
silly software
<samueldr>
xfce kind of has a facility for that with /etc/xdg
<samueldr>
but you have to guess at all the monitor names!
<samueldr>
else it will fallback to a hardcoded value
<samueldr>
ideally it would have a first fall back to a default wallpaper agnostic from the monitor name, *then* to the hardcoded value
<samueldr>
I fear plasma will be similar according to what I read, one wallpaper per monitor
<samueldr>
it might even use not the output name (which I used monitor name until now)
<samueldr>
and instead maybe monitor metadata?
<samueldr>
nope, just "desktops", whatever it means
<abathur>
just replace every image on the system, yeah?
<samueldr>
I'm thinking about opening an RFC for desktop environment maintainers to patch-in a controllable path for the fallback location so NixOS can (finally) better assert its image
<gchristensen>
sounds good
<gchristensen>
NDG, Nix Desktop Group
<samueldr>
I guess I'll need a plasma or QT/QML expert to weight in
<samueldr>
but the scaling seems awfully weird on that one tablet I'm testing on
<samueldr>
like it's scaling up from a 1:1px render, rather than rendering at the native size or scaling down
<samueldr>
but it frankly seems like an upstream issue
<supersandro2000>
so I am searching for an invite to lobste.rs. Maybe someone?
<elvishjerricco>
Oof. Sounds like they're doing a lot of stuff that's way less efficient than ZFS's birth time magic
<elvishjerricco>
Some fairly basic file system operations will require walking all over a bunch of trees, whereas ZFS can just compare two birth times to make a decision
<aleph->
So as always zfs is bae
<elvishjerricco>
Maybe. I'm no FS engineer so maybe I'm misinterpreting the whole description
<lovesegfault>
elvishjerricco: a good opportunity to talk to Kent and see what he has to say
<lovesegfault>
they have an irc chan
<elvishjerricco>
Nah. I wouldn't know what to ask or what his answers mean :P
<lovesegfault>
"Just read the snapshots doc and wouldn't the design mean some fairly..."
luxemboye has quit [Remote host closed the connection]
luxemboye has joined #nixos-chat
<supersandro2000>
lol. I just found out that you can name files emojis in linux
<lovesegfault>
IIRC linux file names are any sequence of bytes except null (0) and '/'
<lovesegfault>
so UTF-8 is fine
<lovesegfault>
and thus emoji :D
<elvishjerricco>
Is it possible to load and run another ELF binary without forking?
<elvishjerricco>
Or exec'ing
<ashkitten>
elvishjerricco: what do you mean?
cole-h has joined #nixos-chat
<ashkitten>
like dynamic linking?
<ashkitten>
or runtime library loading?
<elvishjerricco>
ashkitten: There's a very dumb app for iOS that emulates Linux running on x86 so that you can run Alpine Linux. The actual programs are the legit x86 binaries, but they're being emulated. I'm wondering if you could emulate Linux on aarch64 instead, and load the aarch64 binaries and run those without emulation. Problem is, on iOS, you can't do stuff like exec or fork
<ashkitten>
how would you run linux binaries without emulation?
<ashkitten>
it's not a linux kernel
<elvishjerricco>
ashkitten: Well you'd emulate the syscalls of course. But the binary's actual machine code would run directly on the cpu, and its syscall functions would just call into your emulation code
<samueldr>
wine, but for linux binaries
<samueldr>
thanks, I hate it
<samueldr>
:3
<elvishjerricco>
Oh wait none of this is possible anyway, because you can't mark memory as executable on iOS at all
<ashkitten>
samueldr: bsds already have linux emulation
<samueldr>
I was half joking
<elvishjerricco>
So you couldn't jump to the binary anyway
<samueldr>
ashkitten: doesn't have involve the kernel in some ways?
<samueldr>
(I know next to nothing about their emulation[?] layer)
<ashkitten>
i believe so
<samueldr>
right, then it's cheating :)
<ashkitten>
ky0ko1 would know more
<elvishjerricco>
Considering macOS's earliest roots are BSD based, I wonder how wildly difficult it'd be to port that to macos
<samueldr>
time for my once every couple of years look at how darling is doing
<samueldr>
elvishjerricco: it's not "related" to BSD in the kernel
<samueldr>
AFAIUI
<samueldr>
it's mostly userspace
<elvishjerricco>
Oh. I thought it used the same kernel. Oh well
<ashkitten>
eh, darling's problem is mostly the proprietary userspace apis like cocoa and such iirc
<elvishjerricco>
Darling is the wine for emulating macos right?
<samueldr>
ashkitten: mach-o loader
<ky0ko1>
bsds do have linux emulation in the kernel. also, elvishjerricco you can do JIT now on iOS, but it's complicated. also, there is BSD code in the kernel, as a module.
<samueldr>
in fact darling's mach-o handling was AFAIUI pretty good a couple years back
<ky0ko1>
basically the entire freebsd kernel is taken a single kernel module
<samueldr>
it was mostly missing the system libraries
<elvishjerricco>
ky0ko1: Oh? I'll have to look into that. One sentence version of why it's complicated?
<ashkitten>
samueldr: are system libraries implemented now, then?
<samueldr>
no idea!
<samueldr>
that's why I'm looking
<samueldr>
to see if there was any progress
<samueldr>
but IIRC the prebuilt-from-xcode compiler binaries and stuff ran fine a few years back
<ky0ko1>
you're still required to do W^X, so you have to manage which parts are writable and which are executable at any given time, but you can now actually change that. i was looking into it because the same API is used on macOS for ARM and i was trying to port the JIT in the Dolphin emulator.
<ky0ko1>
you also have to set up permissions for the app to use JIT for it to work at all
<samueldr>
hm, no progress reports since 2019, but they released a new alpha in february
<ky0ko1>
by default the api will deny you access
<elvishjerricco>
Oh. Well W^X isn't that bad at all
<ashkitten>
ky0ko1: do you like darwin or netbsd better as a kernel
<samueldr>
I can't get a feeling of what progress there has been, but there's been continued development, which I guess is neat!
<ashkitten>
speaking of development i made my first pr to sway today
<ashkitten>
though i have no familiarity with the codebase so i probably did it really bad
<ky0ko1>
ashkitten: i prefer netbsd. the XNU kernel is built on mach, which is a notoriously terrible microkernel, and all that apple has done in making it usable is in spite of that, not because of it
<ky0ko1>
it does let them do some clever things though just on virtue of it being a microkernel at all
<elvishjerricco>
Clever things like what?
<ky0ko1>
a majority of actively maintained drivers work on the new ARM machines despite being compiled for amd64, because apple's preferred driver framework is entirely userland - they can just run the userland programs that implement that driver under their amd64 emulator
<ky0ko1>
under a non-microkernel system a strictly userland driver framework is the exception and not the rule
<ashkitten>
but netbsd can do that too can't it?
<ky0ko1>
no
<ky0ko1>
you are thinking of rump kernel drivers which are not quite the same thing
<ashkitten>
oh
pie_ has quit [Read error: Connection reset by peer]
<ky0ko1>
rump kernel / anykernel model does let you move quite a lot of netbsd functionality into userland but not all of it for sure
<elvishjerricco>
Is this why Apple has been encouraging devs to switch from kexts to userspace drivers for a couple years now? For seamless arm transition?
<ky0ko1>
most likely, yes
<ky0ko1>
anyone that did had working arm drivers day one
<ky0ko1>
many that didn't still don't have working arm drivers
pie_ has joined #nixos-chat
<elvishjerricco>
That is actually really cool
<ky0ko1>
the downside to that is that userland drivers are going to be slower. they don't have to be, but as i said before, mach is not a very good microkernel, and its design does not lend well to high performance. they have managed to make it work for very low latency, though, which is very impressive.
<ky0ko1>
also just to throw this out there i've been looking at implementing that exact "wine but for linux binaries" thing and, if it works, proposing it as an alternative to current netbsd linux emulation (which is outdated and buggy at the best of times)
<ashkitten>
:o
<ashkitten>
ok but consider: linux rump kernel
<ashkitten>
then u can just run binaries with that
<ashkitten>
yay
<ky0ko1>
the closest you'll get to that is usermode linux
<ky0ko1>
which.... yes you could do that
<ky0ko1>
UML is in fact actually a thing
<elvishjerricco>
Is that somehow worse than a wine like thing?
<samueldr>
still is a thing?
<samueldr>
I think UML is not a thing anymore?
<ky0ko1>
as far as i was aware it hadn't been removed from the kernel tree
<ky0ko1>
it's not a separate thing anymore, it got merged to mainline
<ashkitten>
is it more maintained than the floppy drivers?
<ky0ko1>
god i hope so
<samueldr>
oh, I had CoLinux in mind
<ky0ko1>
i was literally just ranting about linux's floppy driver earlier in the netbsd matrix channel
<ashkitten>
is it still not fixed
<ky0ko1>
what do you think the answer is
<ky0ko1>
to fix the issues i had with it it basically needed a from scratch rewrite anyway
<elvishjerricco>
What's wrong with the floppy driver? And why should we care about floppies?
<ashkitten>
elvishjerricco: you take that back
<elvishjerricco>
Lol
<ashkitten>
i care very deeply about floppies >:(
<ky0ko1>
we should care about floppies because they are important
<ashkitten>
some of my best friends are floppies!
<elvishjerricco>
Well anyway what's wrong with the driver?
<ky0ko1>
several things, some to do directly with it, and some not
<ky0ko1>
an important one is the fact that floppy based boot has been broken at least since the 3.x series and nobody knows or cares about this because, well, why would someone want to boot from a floppy in 2019/20/21
<ky0ko1>
(i want to boot from a floppy in 2021 and i know other folks who have and maintain old hardware also do)
<ky0ko1>
its the easiest way to get a 486 based machine to boot anything and if you think those are not still in use you have never met the manufacturing industry nor the science sector
<ky0ko1>
nor me
<ky0ko1>
nor the aerospace sector, for that matter
<ky0ko1>
another issue is the fact that the floppy driver, like many linux drivers, is very hardcoded for a specific setup of floppy controllers and if you have anything that does not reflect that setup it will not like you
<ky0ko1>
i have a setup that i want to use that requires the ability to drive three floppy controllers, one of which is at a nonstandard i/o port address. linux cannot handle this without a complete rewrite of the floppy driver, as well as rewritten port-specific code for each platform that can possibly use the floppy driver (even if i only care about / want to build the i386 version). i have tried, and failed.
<ashkitten>
it's not like manufacturing or aerospace companies will ever upgrade from their decade old linux systems tho
<ky0ko1>
they do, sometimes, and i am the person they come to when they want that.
<ashkitten>
ur a cool person
<samueldr>
one floppy drive at a hardcoded address should be enough for everyone
<samueldr>
(trying to paraphrase the 640KB thing badly)
<ky0ko1>
we have a system that was descended from one of those floppy-booting 486 boxen sitting in our living room right now
endformationage has quit [Quit: WeeChat 2.9]
cole-h has quit [Ping timeout: 240 seconds]
Mic92 has quit [Quit: WeeChat 3.1]
Mic92 has joined #nixos-chat
FRidh has joined #nixos-chat
<eyJhb>
ky0ko1: Where do you work?
<ky0ko1>
i do embedded software development for an international company that deals with a lot of clientele in a lot of fields
<ky0ko1>
i've worked on medical devices, industrial manufacturing stuff, cell phone rf hardware
<ky0ko1>
all kinds of things
<eyJhb>
*hissing* RF
<ky0ko1>
including code that has gone on an airplane but probably not in the way you think
<eyJhb>
Sounds cool. Somewhat like IoT/embedded hardwares a lot. Especially in the medical field.
<eyJhb>
Did you bring your laptop on the airplane? ;) :p
<ky0ko1>
the code i wrote was cabin controls for private jets, updating from their old systems that used physical switches to new systems that did exactly the same thing but with a touch screen instead of physical switches (but the same buttons in the same places)
<ky0ko1>
it was easily the least satisfying and most frivolous project i've worked on, was less accessible than the old hardware, harder to use, and the company went bankrupt for basically all of the previous reasons plus the fact that they never really had backing funding in the first place
<eyJhb>
ky0ko1: What about the MOST satisfying job?
<ky0ko1>
hmm, good question
<ky0ko1>
i think i'd have to pick either one of my previous two projects (medical autoinjector device, and workout machine firmware) or the "big" project at my previous embedded job, which was a tracking system for the state government's snowplow fleets to help them plan and deploy more efficiently during snowstorms
<ky0ko1>
(that project was a failure for a number of reasons that i'd called out early in the project, but it was still enjoyable especially after they'd realized i was right and let me loose to redo the thing right - it was too late by then though)
<ashkitten>
ky0ko1: the snowplow tracking sounded rly cool when u told me abt it
<ky0ko1>
it was!
<ky0ko1>
especially when you got to look at everything through the frontend that the client saw
<ky0ko1>
you'd open it a day before a snowstorm and start to see all the machines lighting up and going across the map of the city, see the patterns of where salt had been laid, where snow had been plowed, with hotmap coloration to show how long it had been since so you could know where plows might be needed again
<ky0ko1>
the warehouse asset tracking project there was fun too for similar reasons, plus the fact that i basically engineered it from the ground up from semi-off-the-shelf parts
<sphalerite>
ugh touch screens
rajivr has joined #nixos-chat
hax404 has quit [Remote host closed the connection]
hax404 has joined #nixos-chat
waleee-cl has joined #nixos-chat
<philipp[m]2>
Every couple of years I get very sad that we still don't have a machine readable archive of our musical heritage.
<gh0st[m]2>
Would be amazing if we had archives in Lilypond or MusicXML or something easy to play and convert to sheet music
<philipp[m]2>
Convert into sheet music, automatically create play along tracks, do statistical analysis if that's your jam.
FRidh has quit [Quit: Konversation terminated!]
luxemboye has quit [Ping timeout: 240 seconds]
luxemboye has joined #nixos-chat
__monty__ has joined #nixos-chat
<pie_>
apply ocr to sheet music scans? >_>
<pie_>
ymmv...
<pie_>
what kind of reasons<ky0ko1> (that project was a failure for a number of reasons that i'd called out early in the project, but it was still enjoyable especially after they'd realized i was right and let me loose to redo the thing right - it was too late by then though)
<pie_>
hmm i i vaguely remember clicking on some kind of snowplow tracking webapp
srk has quit [Ping timeout: 240 seconds]
<__monty__>
pie_: Are you using a matrix instance that appends rather than prepends reply-to quotes?
<pie_>
no i just do that
<pie_>
im weird
<pie_>
why
<__monty__>
Just wondering whether someone, somewhere finally started dealing with the UX problems of the IRC bridge.
<gchristensen>
gosh durnit just realized the reason my fingerprint sensor sucks so much is because of ground differences, and if I ground myself on the metal body of the laptop it'll work right away
<ar>
oh, thanks for reminding me. i haven't tried setting up that on my laptop yet
dotdotok has joined #nixos-chat
<ar>
actually the last time i did that, was on a thinkpad x300
luxemboye has quit [Remote host closed the connection]
luxemboye has joined #nixos-chat
aminechikhaoui has quit [Quit: Ping timeout (120 seconds)]
aminechikhaoui has joined #nixos-chat
<MichaelRaskin>
So it i not so much a «wrong finger» as «not finger enough» problem?
<gchristensen>
lol
<MichaelRaskin>
Not sure if the measure s are supposed to actually make printing a fingerprint more expensive, or just to convince you they make simply printing the fingerprints more expensive
<MichaelRaskin>
OK, that's how a recovery operation looks like > We patched duplicity and we are able to recreate the disk even if a part is missed. POC works. (quote from @olesovhcom / Octave Klaba)
FRidh has joined #nixos-chat
<gchristensen>
wow
cole-h has joined #nixos-chat
<pie_>
__monty__: heh
<pie_>
yes please upstream patches and make recovery ops more resilient
<aleph->
MichaelRaskin: What's the horrifying context of this?
<MichaelRaskin>
OVH SBG DC fire
<ar>
MichaelRaskin: another one?
<gchristensen>
stillcleaning up
<MichaelRaskin>
Nope, they have just reached the hard parts of the recovery
<MichaelRaskin>
And continuing the long ones, too, indeed
<MichaelRaskin>
I would not even be surprised if once they reach SBG2/SBG1 demolition they manage to recover some of the HDDs in the «burned» zones, probably with some more exciting stories to tell about all that
<pie_>
hmm catbox.moe has inconsequential hosting costs and the patreon covers half of it
endformationage has joined #nixos-chat
cole-h has quit [Ping timeout: 265 seconds]
Baughn_ has joined #nixos-chat
Baughn_ has quit [Quit: ZNC 1.6.2+deb1 - http://znc.in]
<hodapp>
shadertoy has some hella impressive stuff
<hodapp>
I have a couple things on there
<supersandro2000>
that runs in my browser at 0.5 fps
<joepie91>
30fps here
<pie_>
not sure if i want to open that and hang my computer
<supersandro2000>
probably ublock origin messing with it
<__monty__>
Opened fine on a 2010 iMac fwiw.
<supersandro2000>
other browser works fine
<pie_>
WHAT THE F*** that was written during the shader showdown?
<pie_>
otoh i guess maybe they prepared :P
<pie_>
"Live coded on stage in 25 minutes. Designed beforehand in several hours." yeah well ok :P
<pie_>
but still thats ridiculous
<pie_>
and pretty *_*
<ashkitten>
pie_: where?
<pie_>
ashkitten: hm?
<pie_>
the exclamation was because for a second i thought they threw that together in 25 minutes <pie_> WHAT THE F*** that was written during the shader showdown?
<ashkitten>
oh the shadertoy link, i thought you were referring to a livestream
rajivr has quit [Quit: Connection closed for inactivity]
<samueldr>
I was just thinking about something, but am I right in understanding that there is no common way to configure keymaps in wayland?
<samueldr>
well, keyboard layout
<ashkitten>
samueldr: it's entirely compositor dependent afaik
<samueldr>
yeah, was looking into it
<samueldr>
that's amazing if you want to replicate the success of the web
<samueldr>
well
<samueldr>
of web browsers*
<samueldr>
by pushing more and more complexity into individual compositors
<ashkitten>
is that sarcasm?
<samueldr>
so that they become basically impossible to implement
<samueldr>
kind of
<samueldr>
it's snark
<samueldr>
and I don't like saying it
<ashkitten>
fwiw i don't know if it's intended to stay that way, just i don't know of any effort to change that particular thing
<samueldr>
but I strongly think this is going full speed in the wrong direction to do so
<samueldr>
right, so now there's no way to have the nixos config handle the compositor layout AFAICT
<samueldr>
I don't like this at all :(
<ashkitten>
eh, would you prefer a heavy monolithic libwayland or a heavy wlroots and whatever other libraries abstract the intricacies of wayland?
<samueldr>
I don't exactly know
<samueldr>
but I don't like the fact that complexity is spread multiple times over multiple separate projects
<samueldr>
into somewhat incompatible ways
<ashkitten>
sure
<samueldr>
especially since in the end it's just all handled through libinput and libxkbcommon
<samueldr>
(in practice)
<ashkitten>
a common way for compositors to discover keyboard layout preferences from the system might be nice?
<samueldr>
it would help
<samueldr>
I see weston (apparently) will use /etc/xdg paths
<ashkitten>
but in the end it's up to the compositor how it wants to implement that, because the compositor is responsible for input and everything
<ar>
ashkitten: we need a systemd daemon for that! ;)
<samueldr>
unclear if sway fallsback to the /etc/sway/config file only if the user configuration is entirely missing, or for any subconfig
<ar>
samueldr: entirely
<ashkitten>
i guess the thing is that wayland is only a protocol and doesn't specify any configuration (on purpose)
<samueldr>
right, so no partial override of the global config I suppose
<ar>
iiuc there's no formal idea of "subsections"
<samueldr>
well, any option
<ashkitten>
i think i prefer it being compositor dependent but with compositors agreeing on a common way to handle it
<ashkitten>
i'd like to avoid the monolith x11 is, because you can't make a new xorg from scratch
<samueldr>
nah, instead let's make n new xorgs from scratch, or since it's not really possible, ossify around that one compositor library
<samueldr>
it's not all bad
<samueldr>
but some things feel just so backward
<drakonis>
arcan maybe?
<samueldr>
arcan doesn't aim to standardize across different implementations, so it's "its own thing" in many ways
<drakonis>
it is effectively the closest thing to a new xorg
<samueldr>
it's an interesting project
<samueldr>
if it's a set of protocols already, it feels odd how underspecified it is in many ways
<samueldr>
like they did the basic minimum and left everything else to hopefully end up working fine
<samueldr>
in the end this reduces the actual inter-operability
<samueldr>
I can't use most of a compositor with some bits of another one
<samueldr>
though to be fair I'm far from a wayland expert
<samueldr>
but the more I'm getting into it the less I find it pleasing
<samueldr>
my main fear in the end is that we'll have almost a mono-culture of a few major compositors, where I assume all wlroots compositor is "one" compositor
<samueldr>
I don't know if even feasible, but the fact that backends (e.g. KMS, fbdev) are not a common shared interface between compositors is not good
<samueldr>
I know it's negative and highly critical comments, I don't really like being negative...
<samueldr>
but I have actual concerns about it, and it's probably a decade too late to think about that
<ashkitten>
samueldr: new wayland protocols are being specified for all kinds of stuff
<samueldr>
I don't think we'll see switchable backends be part of a wayland protocol
<ashkitten>
idk how that would work?
<ashkitten>
or what you mean
<ashkitten>
compositors just use drm mostly, but they could run on anything
<ashkitten>
sway can run under x11 or wayland
<samueldr>
right now, every compositor has to implement each backends independently
<ashkitten>
i mean... there's libraries for that
<samueldr>
so adding support for, let's say, fbdev, means it's n implementations
<ashkitten>
you seem to want both wlroots to go away and for it to do everything it already does
<samueldr>
wlroots is a symptom of the problem
<ashkitten>
a symptom of what problem though?
<ashkitten>
wayland is backend independent
<ashkitten>
that's the whole point
<samueldr>
that compositors are monoliths
<ashkitten>
so you would prefer that libwayland be a monolith instead?
<samueldr>
they have to implement or at least deal with the different protocols
<samueldr>
probably
<ashkitten>
then you have your wish, in the form of wlroots
<samueldr>
not really
<ashkitten>
why not? is it not monolithic enough for you?
FRidh has quit [Quit: Konversation terminated!]
<samueldr>
because it's not used by every compostors
<ashkitten>
so?
<samueldr>
so fixing things in wlroots only fixes it in many compostiors using wlroots
<ashkitten>
i don't agree with the point of your argument
<samueldr>
you don't need to agree :)
<ashkitten>
many implementations of a well specified protocol is good
<samueldr>
maybe the protocol isn't good? I don't know :)
<ashkitten>
i think you're reaching there
<samueldr>
look
<samueldr>
I started with "I'm not an expert"
<ashkitten>
do you have concrete complaints about wayland or do you just want to complain about how you think it's architected?
<samueldr>
I want to know whether I have misconceptions
<ashkitten>
you seem to be holding fast to them
<samueldr>
but wayland itself is maybe not the issue
<samueldr>
but that there is the dichotomy of the wayland protocol, and "linux wayland servers", and that the wayland protocol is just fine? (I don't know about the wayland protocol)
<samueldr>
and that "linux wayland servers" are, then, built using something that totally not specified by wayland, because it simply is not
<__monty__>
What are the things that communicate using the wayland protocol?
<ar>
there's also the issue that different compositors do basic things differently
<ashkitten>
why would a protocol specify implementation details?
<samueldr>
and that maybe there should have been something to get them built throuhg common interfaces?
<ar>
for example, gnome people insist on client windows drawing windeco themselves
<samueldr>
okay
<samueldr>
first
<ar>
and everyone else does the opposite
<samueldr>
"wayland" is an overloaded term
<samueldr>
because it's being used to talk about the protocol and "any compositor implementation"
<samueldr>
I probably don't have any issues with the protocol
<ashkitten>
when i say wayland i mean the protocol, when i say wayland compositor i mean a compositor, when i say wayland client i mean a client
<ar>
(the opposite: compositor handles windeco, because that's the only sane way to do it consistently)
<samueldr>
ar: now you're thinking in X11 terms
<samueldr>
(note: I'm not saying whether it's good or bad)
<ar>
samueldr: sort-of, yes
<samueldr>
(I actually don't care, as long as it's well defined, and ideally user-selectable)
<ar>
samueldr: still. in this instance, gnome way of doing things practically requires everyone to depend on gtk
<samueldr>
I don't think so?
<samueldr>
the CSDs can be implemented by any toolkit?
<samueldr>
and they are?
<__monty__>
ar: I used to think it should be a central responsibility too. But I enjoy my browser not having the system window titlebar and my video player as well. So does the compositor now have to enable every trick a window wants to pull with the titlebar?
<samueldr>
that is, unless you want them to harmonize with other CSDs
<ar>
samueldr: sure, but if you want them consistent
<samueldr>
but I think that's a stated non-goal
<ar>
samueldr: then you have to interpret gtk theme somehow
<samueldr>
CSDs are not consistents by design
<ar>
__monty__: you can have rules in your display server, or clients can ask not to draw windeco on them
<ar>
but the default shouldn't require clients to reinvent the wheel
<ar>
s/can ask/should be able to ask/
<ar>
samueldr: see, that's a design problem then
<ashkitten>
ar: what does gnome do if a client doesn't draw its own window decorations?
<ar>
ashkitten: i have no idea. I'm incompatible with gnome
<ashkitten>
then you might have identified a problem that doesn't exist
<samueldr>
btw the reason I'm griping about backends is because it'll be basically impossible to "support" non-mainline linux kernels with wayland because of that fatal issue
<ashkitten>
i highly doubt that every client implements csd just for the sake of gnome, and gnome has to do something to make that client look reasonable
<ar>
also, gnome people tend to speak authoritatively about wayland issues, as if they have the final word in them
<samueldr>
(unless they already implemented the fbdev backend, or hwcomposer backend [unlikely])
<ar>
like "There are no plans to support server side decorations under Wayland, and it'd be a step backward from the path we are aiming for with Wayland"
<samueldr>
so choosing a graphical environment gets the added complexity of having to choose according to the basic features implemented for hardware support
<samueldr>
instead of just choosing a graphical environment based on what you prefer to *interact with*
<__monty__>
ar: I have to say it seems conceptually simpler to have a layer cake. Something on top of wayland which you can build on top of if you want (default decorations in this case).
<ashkitten>
samueldr: iirc there's a drm driver implemented on top of fbdev
<samueldr>
it's the other way around, fbdev in the kernel is likely running on top of DRM
<samueldr>
but it needs to be *already* in existing kernel trees
<samueldr>
looks like it hadn't been accepted in mainline yet
<samueldr>
>> It's not intended to add new features or drivers to fbdev. Instead fbdevdrm is supposed to be a template for converting fbdev drivers to DRM
<samueldr>
not sure what to make of this
<samueldr>
but if I understand it right, it's not intended to be used as it is
<ashkitten>
unfortunate
<samueldr>
it'd be instructions to convert, let's say, msmfb driver into msmfb-but-talks-drm
<ashkitten>
it seems that wlroots has pluggable backends
<samueldr>
yeah
<ashkitten>
ofc you're correct that any non wlroots compositor would need to implement the correct backends
<samueldr>
there is a PR that will never be merged with fbdev backend for wlroots
<ashkitten>
it's unfortunate that this is only an issue for phones that will never see an upstream kernel
<samueldr>
yes
<samueldr>
very
<samueldr>
I'm coming in from the point of view of reducing the effort required to start using things
<samueldr>
ideally every phone would be supported by mainline
<samueldr>
but that's not something you could ask from many individuals who could realistically be able to port the vendor kernel
<samueldr>
because see, while I have more kernel development knowledge compared to when I started, still I don't think I'd be able to handle porting to mainline
<samueldr>
but when I started, I was able to just use the existing kernels!
<samueldr>
if I had *needed* to get a mainline kernel running, I would have never started the Mobile NixOS effort
<ashkitten>
at least newer phones all use drm right?
<samueldr>
kind of
<samueldr>
there's an area of knowledge I still haven't taken time to investigate and understand
<samueldr>
but according to what I can guesstimate from the DRM X11 driver, it might not be enough because of the *GL .so drivers
<samueldr>
*might*
<samueldr>
the X11 driver tries to load a .so driver but cannot... but I literally have not looked at it more than just seeing the error and shelving the thought for much later
<samueldr>
but at the very least without acceleration it does work with the usual DRM things
tomberek has joined #nixos-chat
jess has quit [Quit: updates]
<eyJhb>
Who was it, that have the Windows, passthru, setup on NixOS with a easy command?
<eyJhb>
I have something with elvishjerricco as well yeah
<aaronjanse>
eyJhb it was cole-h
<elvishjerricco>
yea cole-h showed me how to do it. I have a dumb module for my nixos config now that kinda works
<eyJhb>
Cool. Wondering if it is worth the work to setup, so that I can "boot" into Windows, and do games.
<eyJhb>
Not sure how well that works elvishjerricco ?
<elvishjerricco>
eyJhb: It seems to work pretty flawlessly for me, except that I seem to lose my VTs. Like ctrl+alt+f1 just shows me a blank screen after giving the gpu back to linux
<elvishjerricco>
and I have a bunch of code that I don't know how it works, whether it works, or whether it's necessary :P
<eyJhb>
Might have to try and set that up at some point :D
<elvishjerricco>
(I named my desktop and the guest after the magic cards young pyromancer and monastery mentor)
<__monty__>
Any sword nerds around? I was wondering whether sheathing a double-edged sword is risky. In iaido katana are usually drawn along the hand to guide the point to the scabbard. What's the technique for double-edged swords? I can't find any videos of sheathing any swords but katana.
<elvishjerricco>
Now all I do is `systemctl start mentor-guest.service`, and the Conflicts automatically kills off the display manager, and starts up the vm
<elvishjerricco>
When it's done, it starts the display manager back up whether the qemu command succeeded or failed.
beertoagunfight has joined #nixos-chat
<elvishjerricco>
Huh. git is being very slow with "Resolving deltas". It's not bottlenecked on the disk and the loadavg is like 0.3, so I'm not sure what's slowing it down
<samueldr>
might be on the remote end
<samueldr>
AFAIUI there are multiple protocols and one of them is terrible at git
<elvishjerricco>
samueldr: Well there wasn't any network traffic, and I thought resolving deltas was just a thing git does after it's finished downloading everything it needs
<samueldr>
couldn't say then, but I've had a situation where it ended up faster to clone the (big) remote repo fresh, change the remote to that clone, fetch, put back the remote to the actual remote
abathur has joined #nixos-chat
jess has joined #nixos-chat
<elvishjerricco>
Wtf. My server suddenly can't find the boot device
<elvishjerricco>
I think the flash drive I had /boot on just suddenly up and died?
<elvishjerricco>
Plugging it into my desktop, it has no partitions and reports being 64M
<samueldr>
F
<elvishjerricco>
Is that a common way flash drives fail?
<elvishjerricco>
Well, replugging the drive into my desktop brought it back, so I guess that was just a fluke on the desktop end. But the server still won't boot from usb
<samueldr>
maybe the server decided to lose info about the boot order?
<__monty__>
Fwiw, I *have* had flash drives just suddenly die similarly.
slack1256 has joined #nixos-chat
nckx is now known as jorts
DigitalKiwi has quit [Killed (Sigyn (Spam is off topic on freenode.))]
__monty__ has quit [Quit: leaving]
DigitalKiwi has joined #nixos-chat
DigitalKiwi has quit [Remote host closed the connection]
<supersandro2000>
Why link it? It could be a valuable information...
<MichaelRaskin>
Technically speaking, it _is_ linked
<MichaelRaskin>
Both GitHub and SourceForge
<MichaelRaskin>
(Support page)
jorts is now known as nckx
<elvishjerricco>
Well it gets to grub if I take out all my hard drives
<supersandro2000>
MichaelRaskin: but I am not logically going there if I am searching the source code
<MichaelRaskin>
I only said that the source archive links are easy to find, not that links to GH/SF are easy to find
<MichaelRaskin>
But maybe you should also alter your logic to handle the horrible reality more precisely!
<MichaelRaskin>
Basically, the repository is not considered just source, it is more of a process. Normally the link it under «development», but if there is no such link, Support might contain something useful… (yes, that's a bit of troll logic)
supersandro2000 has quit [Disconnected by services]
supersandro2000 has joined #nixos-chat
<MichaelRaskin>
Hm, I dunno which parts of my reply I missed, but I agreed the repository part is not that easy (but has _some_ logic)