vika_nezrimaya has quit [Ping timeout: 250 seconds]
<ashkitten>
kinda funny to me when ppl just start off in ffxiv, ask how long it is, and then go "what have i gotten myself into.."
endformationage has joined #nixos-chat
<ar>
eyJhb: … .java?
<__monty__>
ar: Not enough type annotations.
<ar>
__monty__: the filename says <something>.java
<ar>
<something>Tree.java even
<__monty__>
Looks more like python but they connected the def keyword to the name of the function...
<__monty__>
Maybe they meant js?
<pie_>
i mean, its intellij idea and theres a bunch of jar files on the left
<pie_>
but whatever is highlighted happens to be covered in that image
<pie_>
ar: it says BinTree per the crumbs thingy at the top
<pie_>
actually in hindsight im not sure how i "managed" to read that
<pie_>
oh lol its actually readable in the title bar tho
<pie_>
kind of weird that there's all that red on the right though, thats supposed to be showing syntax errors, so maybe they replaced the middle of the screen
<samueldr>
there are two kind of UIs for programmery type stuff on TV
<samueldr>
bad on purpose
<samueldr>
bad by accident
<samueldr>
considering the context, it's likely bad on purpose
<pie_>
release the series as gpl due to footage of source code
<pie_>
or whatever java stdlib is licensed under
<samueldr>
you mean absolutely no license, but full copyrights to ORACLE?
<samueldr>
see google v. oracle
<pie_>
aha
<qyliss>
all glory to oracle
<MichaelRaskin>
I guess their plan is to mess it bad enough to count as parody
* samueldr
can't find citation
<samueldr>
there was a post from someone allegedly in the know that *they* do it on purpose
<MichaelRaskin>
You mean Oracle or studios?
<samueldr>
studios
<samueldr>
and when you think about it, it's kinda obvious when it's on purpose, and when it's not
<samueldr>
here they literally have the right IDE for java, java source code tree, even a java file on the split on the right%
<samueldr>
!*
<MichaelRaskin>
And they do it on purpose with the purpose being avoiding exact depiction of other people's code?
<samueldr>
on purpose to infuriate nerds
<eyJhb>
It hurts sometimes
<eyJhb>
The context was database schemas
<eyJhb>
Go figure
<samueldr>
is figure a Go library to deal with database schemas?
<MichaelRaskin>
That would be go get figure
<MichaelRaskin>
I guess go figure could produce an UML schema of the current project?
<eyJhb>
50% sarcasm, 50% not? :p
<MichaelRaskin>
In the bright world of postirony nobody is even able to measure sarcasm!
<MichaelRaskin>
How can we incentivise more Sony-hack-like stuff?
<eyJhb>
Also, apparantly the database schema/database replication also fucked up the "chef" scripts :D I still love the series thou...
<MichaelRaskin>
Just to give studios a counterincentive, you know
<samueldr>
MichaelRaskin: proof of stake on a public ledger
<samueldr>
or is it proof of work?
<samueldr>
anyway, put blockchain it it
<MichaelRaskin>
Well, how one proves that the leak is not generated from thin air, though?
<MichaelRaskin>
Actually, given the modus operandi, it is even better
<MichaelRaskin>
One can post a fabrication, and the studios are pretty much guaranteed to issue a DMCA takedown because it is fastest, and then we have a public statement that the fabrication is actually legit
<eyJhb>
Christ, how did it come to this? :D
<samueldr>
in the next spiderman, batman fights against kingpin
<qyliss>
For small changes, the commit they were based on is meaningless information
<samueldr>
with only rebase merges the graph is not better as it's just a line, right?
<qyliss>
It's a line for most things
<__monty__>
Git doesn't really care about patches. It's all about versions. So that statement is suspect.
<qyliss>
Stuff like merging staging-next should be a merge commit
<qyliss>
And then the graph is actually useful
<MichaelRaskin>
Well, git's style of making an ASCII art graph is not helping any
<qyliss>
__monty__: not in its internal data structures, no, but think about how it was designed to be _used_
<MichaelRaskin>
It was not
<samueldr>
not designed to be used?
<MichaelRaskin>
At no point in Git history there is no trace of it being actually designed
<MichaelRaskin>
Otherwise we would not end up with _the only_ DVCS that has no support for syncing reflog, or with a VCS carefully optimising its FS operations for best safety under FS semantics no currently popular FS provides
<MichaelRaskin>
(ext3 had different consistency model from ext4)
<qyliss>
Missing a feature doesn't mean it wasn't designed
<samueldr>
I'm not sure "to make graphs prettier" is a good reason to use rebase merges... I'm thinking that keeping the fact that "these n commits are a discrete change merged at moment t" is better
<qyliss>
Rebase merging preserves the semantics we think of when we look at a PR
<samueldr>
though, I'm not one that can decide of this
<qyliss>
You think "I'm going to apply this diff on top of HEAD", or at least I do
<MichaelRaskin>
Once something actually goes wrong, you start caring what were the dep/revdep versions at the moment of patch being written, though
<samueldr>
I'm going to apply this change set on top of HEAD, that makes it have two parents, previous_HEAD and PR_HEAD
<samueldr>
and it additionally adds the metadata from the system that's used to do the merge
<qyliss>
What does the base of the PR even mean, though?
<qyliss>
In most cases, the branch point is totally meaningless
<samueldr>
I haven't referenced the base of the PR branch, and that, indeed, is mostly meaningless here
<MichaelRaskin>
In most cases all history between channel cut points is meaningless
<samueldr>
I would be fine if it was "rebase and then merge commit"
<samueldr>
or even "lose base info and merge commit"
<qyliss>
MichaelRaskin: I think it would be nice if the channels repo merge-commited every time it updated
<qyliss>
Because there that information is actually meaningful
<qyliss>
I don't think that a discreet change should be spread across multiple commits, anyway
<MichaelRaskin>
I would say that it matches my expectations of what happens with git use, when the most useful part of history information ends up not being tracked completely
<MichaelRaskin>
I think we now have a defacto policy (which is of course useless) to split adding a maintainer-list entry into a separate commit, which doesn't happen to be useful too often.
<qyliss>
I think that is useful
<qyliss>
If you have to revert the package add, you don't want to also revert adding to the maintainer list
<MichaelRaskin>
I think the case where a person simultaneously creates two package addition PRs is more likely (but both cases are pretty rare)
<qyliss>
Honestly rebase, then merge would probably address my concerns
<qyliss>
There's no way GitHub supports that though, right?
<MichaelRaskin>
I guess a graph drawing tool that is not as weird as the git's one would also be sufficient
<qyliss>
I still don't like the semantics of merging a change that hasn't been developing in parallel to master, and keeping its branch point
<MichaelRaskin>
Ideally, the branch point should be chosen to reflect where the testing happenned
<qyliss>
That would also make sense
<MichaelRaskin>
Usually the _submitter_ tested at the original branch point
<MichaelRaskin>
And we never get any record about the intermediate reviewers
<lassulus>
so, rebase merges yay or nay? I can press different buttons if more people are happier this way
<qyliss>
I vote rebase
<MichaelRaskin>
I vote merge
<MichaelRaskin>
Do we now have to write two competing RFCs?
<qyliss>
Only if we're sufficiently unhappy with the current situation
<qyliss>
Which is people do whatever they think is right
<infinisil>
Oh wow.. I just wanted to do this: `cat ids | while read id; do beet mod id:$id nope=0; done`
<infinisil>
But it just didn't work, the command was only called with the first id in the file
<infinisil>
Turns out `beet` consumes all of stdin!
<infinisil>
What the hell
<ivan>
give it a < /dev/null
<infinisil>
Ah yeah or I did `echo "" | beet ...`
<infinisil>
Oh and also what the hell: I have the `nope` tag for things I don't want to listen to anymore, but somehow many songs ended up being tagged as nope even though I'd never do that on my own
<infinisil>
Which is why I had to go through all things tagged as nope to find the ones that shouldn't be there, and now running that command to fix it
<infinisil>
There's like 88 songs in there, maybe I mass-tagged a bunch of songs by accident at some point
Church- has joined #nixos-chat
<__monty__>
Or maybe your music felt like it was too good for you.
<infinisil>
Hah
<__monty__>
Just gonna drop this here again, trying to get some spirit going for a #nixos AoC leaderboard:
<__monty__>
,aoc
<{^_^}>
Join us in the Advent of Code. We need your help, Santa's in trouble! #nixos leaderboard: 397598-41437759 https://adventofcode.com
<__monty__>
Can anyone enlighten me on why Ext4? XFS is pretty old right? And in contrast to Ext4 it seems to be more future proof and attract more future focused interest.
Church- has quit [Quit: WeeChat info:version]
<samueldr>
"why ext4?" is not really a question
<samueldr>
though from years back, when I looked at FS, it looked like ext4 was the most well-balanced FS, still being developed, and known to be stable
<samueldr>
XFS was recommended for workload with a bunch of small files though IIRC
<samueldr>
not sure how years have changed that
<MichaelRaskin>
Years ago XFS had this _interesting_ approach to ENOSPC
<samueldr>
I don't know that there is _a_ clear winner, it's all about knowing the limitations of each
<samueldr>
ext4 can be shrunk and expanded, I think some FS can't be shrunk
Church- has joined #nixos-chat
<ivan>
__monty__: I use xfs and btrfs when I really need compression
<{^_^}>
#68241 (by ivan, 13 weeks ago, open): Cannot build 32-bit json-glib on machine with large XFS filesystem
<__monty__>
ivan: That's hardly the FS's fault though.
<gchristensen>
a bunch of tools fail on large disks, it is a bit surprising
<samueldr>
while it's not the FS's fault, it's still a consequence of using it :)
<samueldr>
and part of "knowing the limitations"
<samueldr>
all FS will have advantages and drawbacks
<samueldr>
even if it's only "so damned standard it's boring"
Guanin has joined #nixos-chat
vika_nezrimaya has joined #nixos-chat
Church- has quit [Quit: WeeChat info:version]
<__monty__>
samueldr: But if the FS is storing so many files as to pose a problem. Wouldn't an FS that doesn't have that problem not be able to store so many files?
<samueldr>
I don't know
<samueldr>
that's something you have to figure out for your use case :)
Church- has joined #nixos-chat
Church- has quit [Client Quit]
Church- has joined #nixos-chat
Church- has quit [Quit: WeeChat info:version]
Church- has joined #nixos-chat
Church- has quit [Quit: WeeChat info:version]
Church- has joined #nixos-chat
Church- has quit [Quit: WeeChat info:version]
Church- has joined #nixos-chat
Church- has quit [Client Quit]
vika_nezrimaya has quit [Quit: ERC (IRC client for Emacs 26.3)]