<OscarL>
some of those ${pythonPackage} can be just $pythonPackage
Nasina has joined #haiku
* Begasus[m]
still needs his coffee
<Begasus[m]>
:)
<OscarL>
added the comment on the PR. /me goes make some coffee too.
<Begasus[m]>
just read the email, now you tell us you don't speak bash? :P
frank_ has quit [Remote host closed the connection]
JohnnyCashSpiralSappinessCow[m has joined #haiku
<JohnnyCashSpiralSappinessCow[m>
hey, im new
<JohnnyCashSpiralSappinessCow[m>
never used irc (joined through haiku)
<JohnnyCashSpiralSappinessCow[m>
i mean, matrix
<Begasus[m]>
Hello and welcome Johnny Cash “SpiralSappiness” Cow
<OscarL>
welcome JohnnyCashSpiralSappinessCow[m ... mmm nickname seems longer than what his IRC client likes :-D
<Begasus[m]>
1-0 for matrix :P
<OscarL>
and seems Begasus[m]'s client just autocompletes the full name instead of just the nick.
<OscarL>
-1 for matrix there.
<Begasus[m]>
Depends on the client :)
<OscarL>
(at least for that client)
<OscarL>
Begasus[m]: took me till 2022 to get onboard the IRC train... now you telling me the cook kids all use matrix?
<Begasus[m]>
In Quaternion I can just start typing the nick and autocomplete
<Begasus[m]>
in NeoChat I need to use @nick for that
* OscarL
might make the change in 2050 or something
<Begasus[m]>
2022! whoot!
<Begasus[m]>
You never used Vision back in BeOS?
<OscarL>
never. just BeShare.
<Begasus[m]>
granted not much BeOS related on IRC back then, but still :)
<Begasus[m]>
we all started out as binkies :D
<Begasus[m]>
never knew the KDE stuff was going to go so fast when I started tackling/playing around it at the end of 2023
<Begasus[m]>
played around in Genio yesterday, as a comparison to kdevelop ...
<Begasus[m]>
it works well, but I just don't get the good vibes with it yet, configuring a projcect for cmake isn't as easy and needs manual intervention
<OscarL>
I wished to use Genio for larger codebases (mainly Haiku), as there the clangd-based "IDE" features could really help me.
<OscarL>
But Haiku's codebase seems to be just too much for Genio at the moment.
<Begasus[m]>
you should give kdevelop a try :P
<OscarL>
Then tried it on smaller one, like Pe, but for the work I do there, I can just rely on Pe and TextSearch :-D
<OscarL>
I remember trying kdevelop in the KDE 2.x days.
<OscarL>
was quite impressive back then, but my hardware was always just too slow.
<OscarL>
(Only "IDE" I could comfortably use was Delphi 2 to 4 on an Athlon 900. Guess that explains why I tend to just use more basic text editors :-D)
<Begasus[m]>
for default "work" I do for haikuports, Terminal/Pe are still default too
<OscarL>
48.45 MiB for Kasts' binary... is that a static or debug build?
<Begasus[m]>
debug
<Begasus[m]>
for local builds it doesn't matter that much as those are build from master branches
<OscarL>
just curious about if it was just a static/debug build, or just a chubby app :-)
<Begasus[m]>
local package for master is 1.41MiB :P
<Begasus[m]>
main developer for Kast is Belgian too :D
<Begasus[m]>
Krita has some base devs in the Netherlands ...
<Begasus[m]>
EU! :P
<OscarL>
(re screenshot: I'd use dark theme too in Haiku, but those darn ugly "gradients" on Tracker/buttons/etc, are way too distracting to me for now :-D)
<OscarL>
better "EU" than "eeew" :-P
<Begasus[m]>
heh
<Begasus[m]>
I'm still missing some icons for Haiku's theme in dark mode
<Begasus[m]>
so when I'm building from master I don't patch the icon theme in the source
Nasina has quit [Read error: Connection reset by peer]
pvalue has quit [Quit: Vision[]: i've been blurred!]
Nasina has quit [Read error: Connection reset by peer]
jmairboeck has joined #haiku
<jmairboeck>
I just looked through HaikuPorter's ShellScriptlets.py, and I think that the new version of getPackagePrefix is the first that actually directly reads other shell variables from the recipe (PACKAGE_NAME, PACKAGE_VERSION and REVISION). Should that be avoided? Is that the reason why defineDebugInfoPackage takes the package name as the first argument? It could deduce it automatically too, just like getPackagePrefix, couldn't it?
Nasina has joined #haiku
Nasina has quit [Read error: Connection reset by peer]
<jmairboeck>
or is that intended to support defining multiple debuginfo packages? (e.g. for separated tools) I think last time I tried that, it didn't work.
Nasina has joined #haiku
Nasina has quit [Read error: Connection reset by peer]
Nasina has quit [Read error: Connection reset by peer]
<B2IA>
(UnrealNeil) bulter catsup
<B2IA>
(UnrealNeil) butler catsup
mmu_man has joined #haiku
Nasina has joined #haiku
Nasina has quit [Read error: Connection reset by peer]
BrunoSpr has joined #haiku
Nasina has joined #haiku
HaikuUser2 has joined #haiku
HaikuUser2 has quit []
BrunoSpr has quit [Quit: Vision[]: Ich wurde eingeweicht!]
BrunoSpr has joined #haiku
BrunoSpr has quit []
nephele has joined #haiku
<nephele>
Good day :)
arjen_ has joined #haiku
<nephele>
Begasus[m]: I see your struff on the forums there
<phschafft>
a good day comes with at least 20 hours of sleep plus naps.
<nephele>
do you suppose we can ask for help why system colors do not work with stuff like qt6 quaternion but do work with qt5?
<nephele>
phschafft: sleep 12 hours, wake up with a headache, sleep 4 more hours to get rid of it
<Begasus[m]>
nephele: which forum? :)
<Begasus[m]>
in case of quaternion, it's not a KDE thing, so nothing to be done there (it doesn't use the color-schemes)
MisthaLu has joined #haiku
<nephele>
ah i guess. It uses the wierd qpa thing, i guess that isn't from kde?
<Begasus[m]>
qpa?
<nephele>
it's an acronym, dunno what it stands for
<nephele>
qt for some reason has two different ways to declare guis :/
<Begasus[m]>
there is qca, but isn't involved in quaternion
<nephele>
and they are kinda incompatible and behave differently
<nephele>
ah nvm, guess qpa is a "different" qt specific thing
<Begasus[m]>
there is only qt6 and libquotient involved from what I see
<Begasus[m]>
other thing maybe the qthaikuplugin
<nephele>
the timeline in quaternion uses a different rendering thing than the sidebars
<Begasus[m]>
but that hasn't been updated for a while I think ...
<nephele>
the sidebars are i think qwidget, and the thing in the middle is the other one ...
<nephele>
i thought qthaikuplugin is for qt5 only? but dunno
<phschafft>
hm.
<Begasus[m]>
Qt6 also, but isn't a seperate package there, included in qt6_base
<nephele>
i just wish installing qt6 (for compiling) wouldn't install all these qt6 gui dev tools...
<nephele>
especially qt6 qdbusviewer
<Begasus[m]>
that's from qtdeclarative iirc
<Begasus[m]>
could probably be bisected, haven't tried that (yet)
<nephele>
I'm "okay" with installing build deps, but not with random tools cluttering my applications :D
<nephele>
or well, debug tools
<nephele>
for a message bus we don't have
<Begasus[m]>
afaik it's not really used also
<Begasus[m]>
at least didn't get anything out of it here
<nephele>
we do not have dbus normally, so that is expected
<nephele>
it's not really neccesary...
<nephele>
some apps install it, and that is really annoying. It's never needed basically, because the thing they want to talk with *over* dbus doesn't exist
<Begasus[m]>
would have to look what is required for the included apps to be sure nothing brakes the base package
<Begasus[m]>
qml/quick etc are in there
<nephele>
qml is the thing quaternion uses afaik
<nephele>
the system colors are wrong there
<Begasus[m]>
maybe it's the qml file from quaternion that needs attention?
<Begasus[m]>
it's pretty hard coded for KDE stuff also
<nephele>
No, it tries to use system colors
<nephele>
and that fails
<nephele>
it worked fine with qt5, but doesn't work with qt6
<Begasus[m]>
yeah I know, doesn't work for quaternion
<Begasus[m]>
but it does work for other KDE apps not using the color-schemes
<Begasus[m]>
I could try if latest quaternion still build with Qt5 and compare for that
<nephele>
I don't think kitsune wants to support qt5 still in general
<nephele>
There has to be some bug in qt6, or a break in behaviour, for this to occur..
<Begasus[m]>
I'm switching to Qt6 where I can also
<nephele>
neochat btw also doesn't work for me
<nephele>
it crashes
<Begasus[m]>
I'm already on 6.8.2 for that
<nephele>
and nheko tries to pull in dbus
<Begasus[m]>
disable notifications in NeoChat
<Begasus[m]>
Nheko doesn't need dbus-launch, it does QtDBus though (but a lot more do)
<nephele>
what's notifications got to do with it?
<nephele>
it crashes when trying to use the system keyring during login
<Begasus[m]>
ow
<Begasus[m]>
well, I only have it crashing when notifications are enabled, otherwise it works fine here
<Begasus[m]>
tried deleting the cache and settings for NeoChat?
<nephele>
No
Aedil has joined #haiku
<Begasus[m]>
those are the ones I delete the first when running into problems
<nephele>
doesn't seem to have either
<nephele>
no cache, and the settings only say which layout and colors
<nephele>
which doesn't correlate to the keyring
<Begasus[m]>
/boot/home/config/cache/KDE/neochat
<Begasus[m]>
and /boot/system/cache/KDE/neochat
<nephele>
why?
<Begasus[m]>
why? it's done like that for a few of those KDE apps
<nephele>
Why stuff anything into /system/cache ?
<nephele>
ugh, those things aren't even cache files!
<Begasus[m]>
chatlogs from what I can see in /boot/system/cache/KDE/neochat
<nephele>
not a cache, really a bad place to put them
<nephele>
cache dirs should be cleanable at any time and not loose *any* important data :)
<Begasus[m]>
agree, but I guess they were always there :)
<nephele>
Port problem ;)
<nephele>
Still crashes directly after login
<Begasus[m]>
ask the first who started it? :P
<Begasus[m]>
jk, could probably be fixed
<nephele>
I'm going to ask the kde developer Begasus [m], maybe they have more insight
<Begasus[m]>
maybe something to do with xdg-dirs ...
<Begasus[m]>
lol
<Begasus[m]>
if you find him let me know :D
<nephele>
maybe it should just use finddirs on haiku... it's more precise
<nephele>
last time i saw him at fosdem
<Begasus[m]>
ah right, that takes a developer to fix :)
<Begasus[m]>
set(QtMinVersion "6.4")
<Begasus[m]>
that leaves out Qt5 for quaternion
<nephele>
yes quaternion deprecated qt5 support
<nephele>
I guess I still have the quaternion dev hat somewhere xD. despite not having contributed any code
<Begasus[m]>
and more projects will folow that path
<nephele>
upgrade race :(
<Begasus[m]>
some are even moving to Qt6.8.2, and already checking out beta9 there
<nephele>
having a bit more backwards compat would be nice. It's fine if projects choose the newer stuff, but distros deprecate the older versions of the libs and frameworks, and suddenly apps that worked fine on qt3/4/5 no longer work because the framework is gone
carlomonte has quit [Quit: nyaa~]
<Begasus[m]>
did you search if it's a Haiku thing or more global one on the system colors form Quaternion?
<nephele>
it seems to be a haiku problem from what i can tell
<nephele>
(and from talking with kitsune)
<Begasus[m]>
maybe I should check if they got a matrix room for quaternion, can't start poking kitsune in the neochat room) :)
<nephele>
sure we do
<nephele>
#quotient:matrix.org
<Begasus[m]>
this works better in neochat then quaternion, (clicking on a links room) :)
dcatt has joined #haiku
<Begasus[m]>
familiar faces in there ;)
andreaallegri has joined #haiku
arjen__ has joined #haiku
<nephele>
i'm not really using matrix atm. quaternion blinds me (and text is unreadable, without proper contrast...) neochat crashes and nheko installs dbus :P
<Begasus[m]>
maybe it's qt6 6.7.2 :P
<Begasus[m]>
nah, on other laptops I have no issue either (with crashes)
<Begasus[m]>
but dogs in a bit, then a little sunday brake before I start poking around
<nephele>
Have fun, nice weather :)
<Begasus[m]>
windy :)
<andreaallegri>
wind of changes ... or ... windows changes ;)
<Begasus[m]>
tsss ... dont mess with Scorpions! :P
<andreaallegri>
xD
<andreaallegri>
alacran y pistolero ... alacran = scorpion
Nasina has quit [Read error: Connection reset by peer]
<andreaallegri>
haiku = poem os ;)
pabs has quit [Read error: Connection timed out]
pabs has joined #haiku
Aedil has quit [Ping timeout: 480 seconds]
pabs has quit [Max SendQ exceeded]
pabs has joined #haiku
<andreaallegri>
(^.^)/
maylay has joined #haiku
Nasina has joined #haiku
maylay_ has quit [Ping timeout: 480 seconds]
xet7 has joined #haiku
andreaallegri has quit [Quit: Konversation terminated!]
DKnoto has joined #haiku
zdykstra has quit [Ping timeout: 480 seconds]
Maston[m] has joined #haiku
jmairboeck has quit [Quit: Konversation terminated!]
Nasina has quit [Read error: Connection reset by peer]
zdykstra has joined #haiku
zdykstra has quit []
zdykstra has joined #haiku
Nasina has joined #haiku
xet7 has quit [Quit: Leaving]
xet7 has joined #haiku
stephan48 has quit [Ping timeout: 480 seconds]
B2IA has quit [Quit: Vision[]: i've been blurred!]
B2IA has joined #haiku
B2IA has quit [Ping timeout: 480 seconds]
B2IA has joined #haiku
nephele has joined #haiku
vezhlys has joined #haiku
stephan48 has joined #haiku
neoncortex has quit [Remote host closed the connection]
HaikuUser2 has joined #haiku
HaikuUser2 has quit []
maylay has quit [Ping timeout: 480 seconds]
maylay has joined #haiku
Nasina has quit [Read error: Connection reset by peer]
Nasina has joined #haiku
Viking667 has joined #haiku
<Viking667>
Has anyone here taken a recent look at getting sqlite3 or fossil fully working on Haiku yet? I've run into one or two problems when dealing with the ncurses-related component.
B2IA has quit [Quit: Vision[]: i've been blurred!]
<Viking667>
(I'll be back, changing clients)
Viking667 has quit []
B2IA has joined #haiku
Viking667 has joined #haiku
<Viking667>
Ahh. Now that's better.
matthewcroughan1 has joined #haiku
<matthewcroughan1>
If you can do UEFI Boot on an ARM platform, does that mean you can just straight up run Haiku? Or is that not something I can assume?
<matthewcroughan1>
OFC I'm expecting drivers to be an issue, with peripherals, but curious whether or not some basic minimal level of support is available like basic rendering
nephele has quit [Ping timeout: 480 seconds]
<x512[m]>
matthewcroughan: Core ARM support is still incomplete in Haiku kernel. It is not matter of specific hardware support, but ARM spec support itself.
<x512[m]>
Something is wrong with timer and interrupts handling.
<matthewcroughan1>
Interesting, I'd love to see the diff that fixes that, whenever it is available
<matthewcroughan1>
Since I know nothing and would like to learn
Nasina has quit [Read error: Connection reset by peer]
nephele has joined #haiku
Peppersawce has joined #haiku
Peppersawce has quit []
<Viking667>
I'll get back to this ncurses question when I get updated...
<nephele>
matthewcroughan1: EFI solves one problem, but there is more to running on architectures than just the boot prcess :) ARM64 can boot to almost the desktop AFAIk. arm however can not. There are some threads on the forum about the progress if you'd like to learn more
<matthewcroughan1>
Oh, by arm I meant 64 bit
<matthewcroughan1>
I have a phone which is running u-boot, I was wondering how trivial it could be to then boot Haiku there
<matthewcroughan1>
this u-boot has UEFI support, so I'm wondering how much stuff is therefore taken care of, and what would work if I could get to the next stage of booting haiku
<nephele>
phones are a bit notorious to support. Though having u-boot is a start. But apart from that, even if it would run, haiku doesn't really run on phones
<nephele>
maybe you'd have a usb-c output for displayport or so? but that also requires support we don't currently have iirc
<matthewcroughan1>
Yeah I'm only really interested in having USB and its own screen work
<matthewcroughan1>
mouse/keyboard/phone-screen and basic 2d is all I'm curious about
<nephele>
using your phone as a mini desktop?
<matthewcroughan1>
Well I've well and truly done that already, now I want haiku
<matthewcroughan1>
video link in case video doesn't work in your matrix client or irc client
<nephele>
but you could probably run a amd64 qemu if you wanted, not that it'd be fast
<matthewcroughan1>
this device doesn't have /dev/kvm anyway, locked away by qcom
<nephele>
kvm is an accelerator, you can run qemu without it
<matthewcroughan1>
I know, but I also know how poor it is without an accel
<matthewcroughan1>
I don't expect haiku to work, I expect mostly race conditions on startup sequences
<nephele>
well, apart from that... running a vnc client on your phone and the vm somewhere else could work. But that still wouldn't give you what you want really :D
<matthewcroughan1>
Unless you have test infra proving that things even boot and work properly in VMs without accel
<nephele>
we can boot just fine on amd64 hardware and vms, just not arm64...
<matthewcroughan1>
nixos has stuff like that, but a lot won't work without accel, provably so!
<matthewcroughan1>
a lot of programs aren't expecting things to be this slow
<nephele>
haiku works suprisingly alright without acceleration in many cases, for a vm without cpu acceleration it depends however
<matthewcroughan1>
That's what I mean, I am expecting startup to fail like all parallel initialization, tends to have race conditions
<nephele>
I don't see why bootup would fail
<matthewcroughan1>
I guess I could run qemu with a single CPU core
<matthewcroughan1>
that would get rid of that issue
<matthewcroughan1>
nephele: Because of timeouts/slowness in parallel processes and a lack of waiting/communication/handling of that between processes in the init
<nephele>
I really doubt that
<matthewcroughan1>
Why? It happens in so many other distributions and contexts. Why would you doubt that Haiku is effected by the same thing as every other kernel/OS
<nephele>
Haiku is Haiku, and not something else. I don't expect haikus bootup to have any problems in that sense, or atleast there *shouldn't* be
<matthewcroughan1>
When stuff is slower than the environment code was tested in, you easily run into breakage in a slower environment, unless the code is written to handle it.
<nephele>
since our userland applications are all multirheaded and work on message passing
<matthewcroughan1>
alright then, I can put that to the test truly ;D
<nephele>
also our dev fs is provided by the kernel directly, there is no wierd userspace daemon that has to manually make files like on linux
<matthewcroughan1>
What is the init system in Haiku?
<nephele>
hmm, i guess launch daemon would be the init system
<matthewcroughan1>
I was trying to use Nix to compile Haiku, though I got stuck at the custom fork of Jam that you guys have, and the monolithic build process that fails only 30 mins in when something small is not the way it is supposed to be
<matthewcroughan1>
I'll get there in the end
<nephele>
why'd you get stuck on jam?
<nephele>
I don't doubt there are some problems if stuff is unexpected in the build. Though we try to be compatible with severall host OS :)
<matthewcroughan1>
Yeah it's just that most build systems make things easier by saying "You don't have this" before starting the build. But in the case of Haiku with Jam, it does such minimal checking, and it'll explode 30 mins later, at which point I'll have to start the build from scratch again
<matthewcroughan1>
and without cache, due to the reproducibility aspect
<nephele>
That seems like a wierd way to go about it. Jam will only rebuild targets needed, not everything. Anyhow, is there some stuff that is not documented as required on the prequisites page you got stuck on?
<matthewcroughan1>
Right, but because build cache is often not reproducible, in most if not all build systems, it cannot be relied upon. So to verify reproducibility, you have to remove this, regardless of the build system used.
<matthewcroughan1>
i.e you don't want to end up in a state where something only works on your machine, because of the fact you ran make to produce some object cache earlier, which created something in an order, that only works on your machine.
<nephele>
Sure, okay. But I wouldn't burn my cache while I am still developing my script for the build
<matthewcroughan1>
Sure, there's no way to not burn the cache in Nix. That is the point of it.
<matthewcroughan1>
The whole point is that it enforces that burning, making it impossible to introduce things that only work on one person's machine.
<matthewcroughan1>
The downside ofc is it makes iterating on monolithic build processes quite difficult, like in the case of Haiku or let's say the Linux kernle.
<matthewcroughan1>
kernel*
<nephele>
Sure. It could help you out a bit more. I understand the end result, but enforcing that during your development is not the quickest way to go about it :/
<nephele>
I guess something like having a "build" launch an interactive shell, in which you can complete the build yourself, and manipulate the nix enviroment yourself would be an easier way to develop
<nephele>
anyhow, if something is missing on the build req page i'd be happy to know about it :)
<matthewcroughan1>
Oh, sure, that's possible. But I find personally that this often is not always a great use of time, in this case it will be due to the iteration time, but in most cases this is a distraction and you get more done with the principles.
<matthewcroughan1>
I actually think it's not missing a build req, but depending on an odd variant of a build req that is named the same as something else in the system
<matthewcroughan1>
I forget, I'll have to run the build process again, lemme d othat
<matthewcroughan1>
s/d/do/, s/othat/that/
<x512[m]>
matthewcroughan: If attempting to integrate Nix with Haiku, it is important to know, that system libraries must exactly match kernel ans system servers version. There are no syscall and internal protocols stability in Haiku.
<nephele>
As I understand it, this is about building the haiku image on some other OS with nix around our build system
<matthewcroughan1>
It's just a Linux build, and once Nix is doing the work, it'll be buildable on any distribution of Linux, and perhaps even Darwin/macOS
<matthewcroughan1>
Without container technologies like Docker, as an added bonus
wicknix_ has joined #haiku
<matthewcroughan1>
Just a single C++ binary that is 20M when statically linked, doing everything.
<nephele>
without container technology as an argument is a bit of a stretch considering nix basically does the same thing in this case
<matthewcroughan1>
I mean Nix existed since 2003, and was doing this stuff a long time before containers, so it is not a stretch.
<matthewcroughan1>
The reason /lib doesn't exist in NixOS for example, is because sandboxing didn't exist when Nix began. Removing that directory was a form of isolation, to avoid giving programs access to this dir and potentially allowing them access to something they shouldn't have.
<nephele>
freebsd jails are older yet, and solaris namespaces older even... i don't think this argument based on semantics holds up
<nephele>
what do you mean by sandboxing didn't exist? maybe it didn't on linux...
<nephele>
(and i assume you mean linux namespaces by that?)
<nephele>
plan9 also gave each application a unique view of the filesystem, and that is also older
<matthewcroughan1>
"Reproducibility is not something that we couldn't entirely guarantee, so for example if your build was actually depending on something in the slash bin directory or slash user slash bin, we couldn't actually prevent it back in 2003 because we didn't have sandboxing and name spacing"
<matthewcroughan1>
s/couldn't/could/
<nephele>
in the context of "on linux" that'd make sense, yes. But not in general
<matthewcroughan1>
Yes, but ofc Nix works in different contexts such as on Haiku and on fat32
<matthewcroughan1>
Because it uses the lowest common denominator of technologies to do what it's doing
<matthewcroughan1>
it is explicitly not fancy, or advanced, which makes it usable in more contexts than a lot of other tools
<nephele>
I guess that denominator is posixy stuff?
<matthewcroughan1>
there's something small that prevents it working on Haiku, something about symlinks
<matthewcroughan1>
some arbitrarily small value that doesn't need to be so small, like fortran's 80 char limit, if I recall correctly
<nephele>
symlinks? oh noes :)
<nephele>
I had huge problems with "symlink depth exceeded" issues on NixOS when I tried to use that a couple years back...
<matthewcroughan1>
Or is it that you don't support symlinks at all? I forget, just someone in IRC was porting Nix to Haiku and mentioned it, I could google for the convo
<nephele>
We don't support Hardlinks. We do support symlinks
<matthewcroughan1>
Not really that knowledgeable about Haiku as you can see
<matthewcroughan1>
Nix doesn't support hardlinks in the nix store either
<nephele>
symlinks seem like the wrong tool for this honestly. That's just asking for trouble. One program is all it takes to open a file "wrongly" and not follow the symlink...
HaikuUser2 has joined #haiku
<nephele>
anyhow we do support symlinks in general, so not sure what issue nix has with it
<nephele>
but regardless, that shouldn't matter when building haiku on linux
HaikuUser2 has quit []
Nasina has quit [Read error: Connection reset by peer]
<phschafft>
matthewcroughan1: what filesystem(s) are the native one(s) for nixos?
<matthewcroughan1>
native?
<matthewcroughan1>
there is no opinion on filesystem, you can use whatever you want with it
<phschafft>
but haven't you said you need symlinks?
<matthewcroughan1>
I suppose, though I can't remember if it's possible to do without them.
<phschafft>
and you also need directory names?
<phschafft>
em.
<phschafft>
and you also need directories?
<matthewcroughan1>
Yeah
<phschafft>
and you need support for a minimum length of supported paths and path components?
<matthewcroughan1>
yessir
<matthewcroughan1>
and dept
<matthewcroughan1>
depth*
<phschafft>
ok, so there is an opinion on filesystems ;)
<matthewcroughan1>
which is components, I guess
<phschafft>
I mean those requirements throw out most (by count) filesystems.
<matthewcroughan1>
fair, and I was wrong about supporting fat32, but exFAT might suffice
<matthewcroughan1>
My point was only to convey that it doesn't need very much
<phschafft>
fat is surely one that comes to mind. but also others (specifically those optimised for disks or flash or small volumes).
<nephele>
It's still a bit linux/posix centric :)
<matthewcroughan1>
a "nix store" is something that can be implemented in a number of ways, and you can add support for a new nix store implementation, as is happening with "nix-on-windows" development right now
<nephele>
I don't really understand what you need the nix store for. If you just have objects you want to expose on the filesystem somehow, why bother with symlinks?
<matthewcroughan1>
I mean if you really want a full understanding you can read the thesis, I'm sure it makes an argument you'd understand. I just use it because it makes reproducing software very easy, and they chose symlinks and "the filesystem as memory" analogies to make that happen.