<gchristensen>
having a pause button for programs isso good.
<hexa->
unthawing the discussion again!
<hexa->
eh
<hexa->
thawing
<hexa->
i'm an idiot, same as last time
<ajs124>
you know what I want a pause button for? my nix store corrupting
<gchristensen>
hexa-: hehe :)
<gchristensen>
ajs124: I wonder how you disappeared a path ...
<ajs124>
maybe the SSD being 59°C isn't good
<samueldr>
AFAIK heat isn't an issue with SSD
<samueldr>
or not as much of an issue
<gchristensen>
I did recently read a thing saying SSDs don't store good, but I think it was only when tortured especially carefully
<ajs124>
that server has been kind of crashy lately + it runs hydra, so weird things are potentially happening to its nix store
<gchristensen>
smarts?
<ajs124>
that one is tortured very carefully
<ajs124>
also, it doesn't support trim well enough that the linux kernel uses it
<ajs124>
smart doesn't show anything that looks too useful
<gchristensen>
fsck etc?
<ajs124>
I'd need to reboot or something like that. And the machine is remote with an ancient iDRAC
<gchristensen>
sounds like pain
<ajs124>
I'll just try to gather enough evidence to get people to replace it.
<gchristensen>
yeah.
<ajs124>
until then, repair the nix store regularly and hope nothing breaks
<gchristensen>
"Database sizes can range from 512 bytes up to 140,735,340,740,610 bytes. Most databases are a few megabytes to a few gigabytes in size, though terabyte-sized SQLite databases are known to be used in production." oooof
<samueldr>
makes my hair rise, but not actually scary, since it's SQLite after all
<gchristensen>
most big networked RDMBS deployments try to top out at 400G per daemon
<hexa->
ajs124: ecc ram? :P
<samueldr>
ugh, that speedy deprecation from github actions broke the mobile-nixos actions, at a time I don't really have the time to check :(
<samueldr>
I guess PRs are going unmerged for a small while
<ajs124>
hexa-: hah, no
<gchristensen>
whats that, samueldr ?
<hexa->
ajs124: rip, would've recommende edac-util then :p
<samueldr>
I (or cachix/install-nix-action@checkoutIuse?) was using add-path apparently
<ajs124>
hexa-: ECC RAM is for people that believe in cosmic radiation, which obviously cannot exist, because the earth is flat, was created last thursday and because "I want to believe"™. change my mind.
<hexa->
ajs124++
<{^_^}>
ajs124's karma got increased to 9
<hexa->
ajs124: also for people who want to gather enough evidence to get people to replace a machine
<hexa->
JJJollyjim: hi, the new topic is now matrix-appservice-irc. As it will never be merged it cleary cannot be on-topic.
<JJJollyjim>
gchristensen i think it has been in my very limited experience?
<gchristensen>
samueldr: hehe :)
<samueldr>
solved the mystery of why I was receiving double notifications
<samueldr>
double IRC client
<gchristensen>
real 0m8.671s
<JJJollyjim>
i wonder if generics will have a bad impact on go compile times like they do in rust
<JJJollyjim>
though thats mostly llvm's fault in the rust case
* samueldr
wonders about getting a display capture for whatever protocol runs to a phone display
<samueldr>
e.g. getting a pixel 2 for pieces (but it'd have to have had its bootloader unlocked beforehand), and having it all wired to a harness for easier debugging
<samueldr>
e.g. break out the buttons to the harness
<supersandro2000>
Match host server1,server2,server3 exec true
<supersandro2000>
I really really love openssh's config format
<supersandro2000>
but if you use Host it is: Host server1 server2 server3
<supersandro2000>
and the man page has nothing about that and I wasted hours to get this working.
<red[evilred]>
funny thing about matrix-appservice-irc - I starter trying to patch it, then while moping about I found someone had already doine it and it was waiting for merge
<red[evilred]>
+1 me for wasting time
<hexa->
red[evilred]: give it 9th shot already
<supersandro2000>
if we had a really cool linter we could probably speed up reviewing by a lot
<supersandro2000>
think about rubocop for nix
<pie_>
supersandro2000: that would be great (never looked at rubocop), a lot of stuff could be written down that just exists as suggestions in lots of places on issues
<pie_>
though i guess writing linter rules isnt trivial either
<pie_>
really, really, wish specs for formats would be common and accesisble <supersandro2000> and the man page has nothing about that and I wasted hours to get this working.
<pie_>
write a damn pseudogrammar at least
<red[evilred]>
Well, I guess I can rant hhhere
<red[evilred]>
fscking RedHat
<red[evilred]>
they don't label the commits in their source code which hfix the CVEs
<red[evilred]>
and they don't publish the patches
<red[evilred]>
and they don't publish the patches for backporting
<red[evilred]>
So I'm just like shrug - I dunno which of these 700 commits between the reporting date and the date they published the fixed versions is the right one
endformationage has quit [Quit: WeeChat 2.9]
waleee-cl has quit [Quit: Connection closed for inactivity]
<Mic92>
hexa-: we could make a PR to remove the systemd service file from rspamd again because appearantly they don't have the expertise to do so and have a distribution independent rspamd-systemd repo.
<MichaelRaskin>
red[evilred]: we also know when they stopped publishing usable patches, yeah (when Oracle started commercial «Oracle Unbreakable Linux» which was not much more different from CentOS)
<MichaelRaskin>
And that's why we can't have nice things. Now Oracle needs to do at least some work…
<patagonicus>
Bisecting an issue with mpv, git tells me it started with a version bump for cryptsetup. Somehow I doubt that.
<patagonicus>
Oh, yeah, looks like I was doing it wrong. At least it was reasonably obvious.
danderson has quit [Remote host closed the connection]
danderson has joined #nixos-chat
__monty__ has joined #nixos-chat
tbech has joined #nixos-chat
Psykobunny has joined #nixos-chat
<gchristensen>
hacking on the aws terraform provider is so incredibly *slow*
<__monty__>
Because of the test cycle?
<gchristensen>
not even running tests. compiling is 10s to 1min, and compiling the tests can be a whole minute too
Psykobunny has quit [Remote host closed the connection]
Psykobunny has joined #nixos-chat
Psykobunny has quit [Excess Flood]
<__monty__>
Hmm, that doesn't sound very long. What sort of rapid compiles are you used to?
<gchristensen>
a couple seconds...
<MichaelRaskin>
Notice that this is infrastructure interop, unlike normal code you don't have a benefit of code that makes sense being more likely to work
<gchristensen>
:D
<MichaelRaskin>
Also explains why Graham talks about all code aging badly so much
<MichaelRaskin>
No code ages well. Code for information processing, implemented inside a good ecosystem just does not age at all.
<MichaelRaskin>
Code for cloud interaction… oh well.
Psykobunny has joined #nixos-chat
Psykobunny has quit [Excess Flood]
<gchristensen>
finally somebody understands me
<MichaelRaskin>
I mean, in the process I do disagree with all code being bad! While commiserating with you having to write integration code, which obviously always is bad…
<MichaelRaskin>
I do sometimes think it is better to stop saying «unmaintained» equals bad, or similar things, and spell out that some bad things push a ton of pointless maintenance burden onto everyone in the blast radius.
waleee-cl has joined #nixos-chat
Psykobunny has joined #nixos-chat
Psykobunny has quit [Excess Flood]
Psykobunny has joined #nixos-chat
Psykobunny has quit [Excess Flood]
FRidh has quit [Remote host closed the connection]
<__red__>
I'm sure I'm not the first person to start a new branch off a previous branch and PR it - but it's still embarrassing :-/
<__red__>
MichaelRaskin: I'm reminded of someone saying "Never trust a package that hasn't been updated in X momths". I'm like "Do you think it may be possible that the project solved the problem that they set out to do and doesn't have any known flaws yet?"
<__red__>
apparently "broken" is so much the norm in our industry that if something isn't broken we assume it's abandoned.
<__red__>
"we"
<MichaelRaskin>
And in the process do not recognise that breaking stuff around is imposing a cost which is often avoidable
<joepie91>
__red__: so, funny thing. well, for some definition of 'funny'... that is pretty much exactly true, most software *is* constantly broken and *does* require constant maintenance. and then when someone rolls into a modular ecosystem like JS where "fully complete" things actually exist because the scope of things is so constrained... they get super confused about the concept of a library just being 'done' and often refuse to
<joepie91>
accept that possibility, instead going for some huge "maintained" thing that's broken in 200 different ways...
<joepie91>
(I'm still curious to what degree this existence of complete things plays into the "everyone builds their own new frameworks all the time" phenomenon)
Psykobunny has joined #nixos-chat
Psykobunny has quit [Excess Flood]
Psykobunny has joined #nixos-chat
Psykobunny has quit [Excess Flood]
<__red__>
joepie91: pretty much
<__red__>
that would make quite the insightful project
<__red__>
I'm not going to lie -=- I'm guilty of it too
<__red__>
The first library I wrote and published for elixir - 2 years or so ago? - I released at version 0.0.2
<__red__>
it's complete
Psykobunny has joined #nixos-chat
Psykobunny has quit [Excess Flood]
<__red__>
with no bugs that I can find at all
<__red__>
So... do I just version bump it to 1.0 for kicks?
<__red__>
It just works
<__red__>
I guess I could add property testing or a fuzzing framework for the exercise
Psykobunny has joined #nixos-chat
Psykobunny has quit [Excess Flood]
<joepie91>
__red__: if it's no longer experimental, then yes, it should be 1.0.0+ :P
<__red__>
(but at 208 downloads since 2018 - not exactly the center of the ecosystem... not exactly the "left-pad" of the ecosystem) ;-)
<__red__>
but since you mention modular code - at some point your depedency tree becomes your code
<__red__>
Koçulu is still a hero in my eyes for accidentally exposing that insane issue
<__red__>
imagine if instead of a removal he just added a maliciuos line
<joepie91>
__red__: that's not really the issue that was exposed, though. supply chain attacks have been known about for a long time
<__red__>
sure
<joepie91>
the real issue they exposed was that npm allowed people to delete packages
<joepie91>
which no other registry does for, well, precisely this reason
<joepie91>
unfortunately the takeaway a lot of people have gotten from the incident was not "npm fucked up registry policy" but "this is why small dependencies are bad!!1!" even though it has nothing to do with that
<__red__>
that is *an* issue, and certainly when you write OSS you remove your right to remove it from the ecosystem
<__red__>
so we're going to disagree on whether small dependencies are bad :-)
<__red__>
it's not that small dependencies are bad by themselves
<__red__>
it's that your dependency tree
<__red__>
sorry - your dependency *mesh* at that point
<__red__>
becomes less maintainable than your code in many cases
Psykobunny has joined #nixos-chat
Psykobunny has quit [Excess Flood]
<__red__>
and I don't think that dependency management is a solved problem yet at all
<joepie91>
that's not really the case if you actually pick your dependencies with some thought, though
<__red__>
right - but that's the problem :-)
<__red__>
people and thought
<joepie91>
well, yes, but probably in a different way than you're thinking
<joepie91>
the #1 cause I've seen for fucked-up and unmaintainable dependency trees in JS, is... people who are all "I don't want to add more dependencies than strictly necessary!" because they don't understand the economics of the ecosystem, and end up adding a few big ones, which then end up pulling in a ton of unneeded complexity, tend to be poorly maintained (because experienced devs almost always avoid such dependencies in JS),
<joepie91>
etc.
<joepie91>
it's a bit of a self-fulfilling prophecy thing
<__red__>
sure - that's a problem too
<__red__>
I have a whole talk on the subject
<__red__>
specifically about the sins of pulling in a whole framework because you only want a few functions from it
<__red__>
and finding the balance
<__red__>
the talk is called: "antkeeping for developers"
<__red__>
(and I spend most of the time talking about to how keep ant colonies as pets
<__red__>
and then there's a section that includes software at the end so I can justify the talk as a tech-talk)
<joepie91>
honestly, I've found it to be less a matter of "balance" and more a matter of "just rigorously avoid any complexity that should not be there"
<__red__>
heh
<__red__>
Right - which is the same thing
<__red__>
the ugly truth is that you can't remove complexity
<joepie91>
well I dunno, is it? :)
<__red__>
you can only hide it
<joepie91>
because that approach pretty much puts you on the "small single-responsibility dependencies only, ever" side
<joepie91>
which logically results in a lot of deps
<__red__>
the question is - do *you* manage the complexity, or do you delegate it to someone else
<joepie91>
and I'm not sure you can really speak of 'balance' there
<__red__>
maybe balance is the wrong word to use there then
<__red__>
because by balance I don't really mean "equal"
<__red__>
so yeah - wrong word
<__red__>
I can't really think of anotehr
Psykobunny has joined #nixos-chat
Psykobunny has quit [Excess Flood]
<joepie91>
__red__: "finding the right spot", maybe?
<joepie91>
and re: complexity, I agree
<joepie91>
however, you can prevent complexity from creeping in that isn't necessary for your goals :P
<joepie91>
just not the "minimum unavoidable complexity" of a problem
<__red__>
I guess "always understand there are tradeoffs, there ain't no suchh thing as a free lunch"
<joepie91>
right
<__monty__>
There's still things where I'd be surprised if single-responsibility to the level of individual functions would work tbh.
<joepie91>
well, a single responsibility doesn't always equate a single function
<joepie91>
it doesn't have to
<joepie91>
it just often happens to do so :P
FRidh has joined #nixos-chat
<__red__>
Ladies and Gentlemen, have you been introduced to your Lord and Saviour Monads?
<__red__>
brb - need to err, "wash my hair" ;-)
<__monty__>
I'm not sure responsibility is even the best word tbh. I'm thinking math libraries. Single-responsibility might be interpreted as only usable for statistics or something. While that seems like a weird artificial limitation from the math perspective.
<__red__>
in all seriousnes, this is kinda similar to the idea that functional purity and no side effects makes better software
<__red__>
but if you want your software to actually do anything
<__red__>
you have to have side effects
<__red__>
so really it's just abount managing them
<__monty__>
No you don't.
<__monty__>
You may need *effects* you don't necessarily need *side*-effects : )
<__red__>
for programs that only have one input and output - sure
<__red__>
but add a network
<__red__>
or database
<__monty__>
No, for any program.
<__red__>
this is probably an over-a-drink conversation
<__red__>
but I don't quite see how
<__red__>
(I really need to get my passport renewed)
<__monty__>
Just pointing out a terminology issue. A side-effect is different from an effect. Since you brought up monads, IO in haskell is about effects, not side-effects. `let x = putStrLn "Hi!" in sequence (replicate 3 x)`
<__monty__>
If output was a *side*-effect of evaluation of putStrLn this'd only output "Hi!" once.
<__red__>
Yes - you're right
<__red__>
this was a terminology issue
<__red__>
thank you
<__red__>
well..
<__red__>
nm
<pie_>
__monty__: TIL
<pie_>
unrelated, is __ __ a clan thing? :P
<__monty__>
pie_: It's my battlescar from starting out with python.
<pie_>
oh haha
<pie_>
didnt even register
Psykobunny has joined #nixos-chat
Psykobunny has quit [Excess Flood]
<supersandro2000>
its formatting IRC does not support Kappa
<__monty__>
supersandro2000: Some clients parse part of it.
<__monty__>
So they render it as _monty_ but bold : )
<__monty__>
Or underlined rather. This is not markdown.
<supersandro2000>
it should be markdwon
Psykobunny has joined #nixos-chat
Psykobunny has quit [Excess Flood]
Psykobunny has joined #nixos-chat
Psykobunny has quit [Excess Flood]
<LinuxHackerman>
__monty__: people mentioning you in IRC gets rendered as monty but bold in Element (the matrix client) >_<
Psykobunny has joined #nixos-chat
Psykobunny has quit [Excess Flood]
Psykobunny has joined #nixos-chat
Psykobunny has quit [Excess Flood]
<sphalerite>
aaaargh. Was wondering why my oven was taking so long to preheat, and thought that the little lamp that indicates whether it's heating was broken.
<sphalerite>
Not so, I just hat it in the mode where the fan and light is on but nothing else.
<sphalerite>
s/hat/had/
cole-h has joined #nixos-chat
<insep_>
Linux Hackerman: renders fine for me
<sphalerite>
insep_: that's because I mentioned __monty__ in matrix. If I mention __monty__ in IRC…
<insep_>
what was annoying is pinging one person with backtick in their nickname
<LinuxHackerman>
wait what!? This was different just a couple days ago!!
<infinisil>
Damn, this satellite they're launching can detect sea level changes up to 1 cm :o
<gchristensen>
infinisil: you might be interested in the pair of satellites known as GRACE, which monitor ground water by constantly pinging each other and noticing if the gravity below them is causing them to move closer or further away
<gchristensen>
further apart*
<infinisil>
Hm interesting
<sphalerite>
gchristensen: I honestly have no idea! What's proofing?
<infinisil>
I wouldn't have expected that to be detectable
<gchristensen>
sphalerite: it uses the heat from the lamp to raise the temperature enough to activate yeast
<MichaelRaskin>
infinisil: well, they seriously consider space-based gravity wave detection, which requires the same but more precise
<MichaelRaskin>
Do not underestimate interferometry
<gchristensen>
infinisil: even light rain storms can drop billions (1,000,000,000's) of liters of water, the mass is significant!
<infinisil>
> 1000000000 * l
<{^_^}>
"1000000.000000 m^3"
<infinisil>
> 1000000000 * kg
<{^_^}>
"1000000000.000000 kg"
<infinisil>
> earthMass
<{^_^}>
"5972200000000000224395264.000000 kg"
<MichaelRaskin>
Note that a million ton is actually impressively low mass to detect via redestributions on Earth scale
<infinisil>
gchristensen: ^^!
<MichaelRaskin>
Wait what
<gchristensen>
the sum total of all your ground water is many many times a light rain storm :)
<MichaelRaskin>
Floats are horrible
<sphalerite>
gchristensen: ooooh nice. Though I guess it doesn't need to be a separate mode, being equivalent to the regular fan mode and the temperature set to 0?
<sphalerite>
oh, that's only for my oven where the light is always on
<gchristensen>
well the light can make it too hot for yeast, so maybe if it is a proofing mode, it might cycle the lamp
<sphalerite>
forgot that some ovens turn the light off when they're baking stuff and the door hasn't been opened in a while
<sphalerite>
#energysaving
Psykobunny has joined #nixos-chat
Psykobunny has quit [Excess Flood]
<gchristensen>
anyone mind reviewing babby's first go?
<infinisil>
> pi = 3.14159265358979323846264338327950288419716939937510
<samueldr>
tbf, with NixOS it should be describing which attribute name the distro uses, and that there are multiple ways to use that
<samueldr>
e.g. nix-shell -p $attrname
<samueldr>
or add it to systemPackages in your configuration
<samueldr>
too many ways to shave that yak
<joepie91>
that in and of itself is not great :)
<samueldr>
yeah
<joepie91>
and each of those shell commands individually has the "obtuse flags" problem
<samueldr>
nix-shell --packages $attrname
<joepie91>
honestly we should have an add-to-system-packages command
<samueldr>
how should that work? :)
<joepie91>
modify your config and rebuild, and undo the change if rebuild fails
<samueldr>
where should it make the edit? not everyone puts their systemPackages directly at /etc/nixos/configuration.nix ;)
<joepie91>
anywhere it pleases frankly
<joepie91>
not like we don't already have this with hardware-configuration.nix :)
<samueldr>
what I want to show is that it's in the realm of extremely non-trivial things
<samueldr>
especially since we don't really have a nix-native way to edit nix files
<joepie91>
any kind of changes-your-config-for-you tool is probably going to need to work off an imported machine-generated file
<joepie91>
oh, I know that it would require a bunch of work
<joepie91>
it's part of why I'm annoyed that the Nix parser is not realistically available as a stand-alone tool
<joepie91>
but it's well within the realm of possibility
<samueldr>
for a similar system, I would propose rather something like /etc/nixos/packages.json (or .nix) which would be consumed by a default module setting when present
<joepie91>
like, this is just the "requires a bunch of work" category, not the "unsolved compsci problems" category :)
<__monty__>
Tbf -i -> --install makes it a bit closer to the other ones. And *technically* there's nothing wrong with "nix-env --install glow".
<samueldr>
I would say a packages.json would make it less likely that someone accidentally edits it in ways the "add to system" command can't resolve
<joepie91>
perhaps
<samueldr>
or, let me rephrase, in a way that still is valid, but can't be reconciled with automatic edits
<__monty__>
Could just have a contract. "Edit this file wrong and you're on your own."
<samueldr>
let's not leave a footgun hanging with "it's your own fault you shot yourself" in the lobby, please
<__monty__>
I'd just recommend against editing it.
<insep_>
__monty__: dunno, last time i tried to install stuff using `nix-env -i nixPkgs.foo` it just hang :P
<samueldr>
though another issue with that, is that the system has to be rebuilt; there is no guarantee the current configuration in the folder is the configuration currently running, so adding to system now becomes rebuild
<__monty__>
Have a file that's supposed to be changed only through the cli. Import it in the default configuration.nix, add a comment explaining why the import's there. "If you remove this import you can't use "nix install"...
<samueldr>
(or e.g. with nixops-managed systems, you could have a completely different configuration!)
<joepie91>
well, again, we already have such a sign hanging in hardware-configuration.nix
<samueldr>
sure
<samueldr>
let's continue proliferating more
<samueldr>
or maybe not?
<__monty__>
insep_: How did you verify it hanged? Did you actually wait until it crashed? And you shouldn't be passing the nixpkgs. iirc?
<joepie91>
already doing it is not a reason for making it worse; but I'm not convinced that reusing this for packages is actually making it worse
<joepie91>
it feels like a fairly fixed-cost footgun to me
<joepie91>
anyway I wasn't going to have lengthy discussions today :P
* joepie91
puts self in corner
<insep_>
i don't remember the exact command, last time i used nixos was 2 years ago, but hang as in "i returned back in 10 minutes and there's still no output in console"
<__monty__>
Imo the full problem is unsolvable. So I'm approaching this from a pragmatic 'What would improve the UX for beginners/people with fairly low demands on NixOS?"
<samueldr>
__monty__: the storage format changes pretty much nothing for the end-user
<samueldr>
using Nix is also more problematic; you can't load the nix expression and edit it
<samueldr>
you'd have to re-generate if from scratch
<samueldr>
there is no trivial way to go from a value to the original attrname
<__monty__>
insep_: It probably would have worked then : ) -A is recommended for a reason, hence the "technically."
<samueldr>
you could go to _an_ attrname, but not necessarily the one use
<samueldr>
used*
<samueldr>
so using json was not *only* about leaving fewer footguns around
<__monty__>
Wait what?
<samueldr>
it was a suggestion for practicallity
<__monty__>
Storage format?
<__monty__>
Using nix?
<__monty__>
Where are you getting these?
<samueldr>
[15:16:43] <joepie91> honestly we should have an add-to-system-packages command
<__monty__>
I didn't specify either and they both seem like inconsequential things.
<samueldr>
then I'm lost
<samueldr>
what were you going about?
<__monty__>
Yeah, I agree that would be better UX for beginners.
<__monty__>
A command that adds a package to your configuration and probably rebuilds the system.
<MichaelRaskin>
Adding packages is the easy direction, checking safety of removal is the harder one
<samueldr>
only allow attribute names found in the list managed by that system to be removed
red[evilred] has quit [Quit: Idle timeout reached: 10800s]
<samueldr>
because otherwise we're not out of the woods shaving that yak
<samueldr>
I would guess if you tried to `nixos remove-from-system bash` if it tried to somehow go through all things added to system packages, rather than only what is "managed"
<MichaelRaskin>
Well, if it is set in an included profile, maybe you do want to edit the included profile and maybe you do not
<samueldr>
MichaelRaskin: I don't follow
<MichaelRaskin>
Configuration is not just one file
<__monty__>
Me either tbh. The cli would only ever touch "packages.json" or whatever format/file it manages.
<MichaelRaskin>
Nix sometimes can help you find which file actually does a thing
<samueldr>
I know, this is why (my) the proposed solution is to have a specialized file managing specifically this feature
<samueldr>
because working from Nix expressions itself is basically a non-starter currently
<MichaelRaskin>
It seems to me that the regret about standalone Nix parser was about whether packages.json is unnecessary complication
<joepie91>
srk: huh, didn't realize someone already built that. it does seem to suffer from the 'pile of buttons' problem though...
<energizer>
i'm not convinced pile of buttons is a problem
<joepie91>
it is, if "intuitive UI" is your goal
<joepie91>
prioritization is an important part of UI design
<energizer>
faithfully representing the data model is an important part of UI design
FRidh has quit [Quit: Konversation terminated!]
* colemickens
whispers Novell Linux and walks away
turlando has quit [Remote host closed the connection]
__monty__ has quit [Quit: leaving]
bqv has quit [Quit: WeeChat 2.9]
bqv has joined #nixos-chat
bqv has quit [Client Quit]
bqv has joined #nixos-chat
<joepie91>
<energizer> faithfully representing the data model is an important part of UI design
<joepie91>
no, this is actually precisely what you should not be doing if you want good UX
<joepie91>
in fact, I'm currently working on building a new volunteer management system for the Dutch hacker camps, because the system used for this previously made exactly that mistake, and combined with its rigidity in terms of business processes, it was a nightmare to actually use
<joepie91>
it's not the user's job to understand the data model of the underlying system
<joepie91>
what you should be doing is providing a UI with a model that is easy to reason about; that doesn't mean it needs to exactly follow the internal data model
<joepie91>
it explicitly shouldn't, and the "UI model" should only encompass those things that the user cares about, in the context that they will be using them in
<joepie91>
prioritization of UI elements is one of the steps you take to accomplish that contextuality
pie_ has quit [Ping timeout: 272 seconds]
pie_ has joined #nixos-chat
bqv has quit [Quit: WeeChat 2.9]
bqv has joined #nixos-chat
<energizer>
priority is fine
<energizer>
prioritization*
<pie_>
so apparently firefox has session management addons again?