Topic for #qi-hardware is now Copyleft hardware - http://qi-hardware.com | hardware hackers join here to discuss Ben NanoNote, atben / atusb 802.15.4 wireless, and other community driven hw projects | public logging at http://en.qi-hardware.com/irclogs
<mth>
larsc: about the patches to the MIPS mailinglist: should I assume no news is good news, or does no news mean no action?
<mth>
I did Cc: those to Ralf
<mth>
I got reviews of two of the patches and fixed them to address the review comments, the third patch (multi-bank NAND) got no feedback
<mth>
the final patch is the one to make /dev/mem optional, I got the feedback that just making it optional is not enough, it should be made into a module
<mth>
which makes sense, I think, but is a lot more effort
<mth>
I plan to have a go at it though
<xwalk>
I'm having trouble with connecting the Nanonote to the network through usb. I get to the point on the wiki where it tells me to ssh or telnet into the Nanonote, but it always refuses the connection.
<dvdk>
hi xwalk
<xwalk>
dvdk: Hello.
<dvdk>
what does '/sbin/ifconfig usb0' output?
<dvdk>
and, btw, did yo uset a root password for the NN already?
<viric>
i know too many dark sides of git already :)
<viric>
git takes the worst of every user and makes it public :)
<viric>
Lying, history rewriting, forgetting branches, hiding work, ...
<viric>
And all while waving a flag "I'm a cool modern developer"
<wpwrak>
t-shirt: "git reveals your inner Sauron"
<viric>
I've heard users saying: "Of course I edit my commits before pushing them. If I made public how I work, that would make look very bad publicly"
<wpwrak>
well, it's about time we learn a few things from politics :)
<viric>
"make *me*"
<viric>
There are programmers heavily addicted to git, as it allows them to rework all they did, leaving no public trace of the edit
<wpwrak>
it would also be rather confusing to follow :)
<viric>
And then they not accepting any other VCS that was made to keep the history of the development.
<wpwrak>
i wouldn't call it an addiction, but of course, once you have the means to clean things up, you use it
<viric>
'clean things up', what an euphemism. :)
<viric>
We could do the same about Peron ;)
<wpwrak>
well, with another vcs, you'd just not commit
<viric>
clean things up
<viric>
hehe
<viric>
hm scratch about Peron. Confusion :)
<wpwrak>
(peron) the "peronist" government put pretty much a Ministry of Truth in place recently
<viric>
hehe
<viric>
That's what I mean
<viric>
Git gives everyone their own ministry of truth :)
<wpwrak>
of course, that's not for covering up anything peron did. saints don't need that. if you questioned peron, what would be next ? maradona ? absurd
<viric>
I've seen git users really ashamed of the way they work
<wpwrak>
well, the truth still comes out when you push. so it just allows you to split the usual workflow in a private and a public part
LunaVorax has joined #qi-hardware
<wpwrak>
they would probably be just ashamed with RCS ;-)
<viric>
no, the 'push' only contains your reworked version of "what happened"
<wpwrak>
s/just/just as
<qi-bot>
wpwrak meant: "they would probably be just as ashamed with RCS ;-)"
<viric>
So, I'm clearly in favour of using a VCS *to keep history*
<viric>
not only as a mechanism of *sharing code* (with no history saving), as git does.
<viric>
There are VCS who keep history, and also work well for sharing code.
<wpwrak>
i don't see a big problem. git simply makes people commit things in smaller chunks - and then they realize the smaller chunks didn't make sense, they have an easy means to correct that
<wpwrak>
if you can't do that, people simply don't commit before they think they're finished
<viric>
It's a manager of patches
<wpwrak>
so with git, you may get ten small steps. with svn it would be a daily commit.
<viric>
svn is very cumbersome related to branches
<viric>
of course I don't mean people should not branch. svn makes people not branch, I think
<wpwrak>
svn is very simple with branches. but not everyone likes that kind of simplicity ;-)
<viric>
yes, very simple
<viric>
you have changes to commit into a branch in your working dir...
<viric>
you only have to do "svn cp blablacurrentbranch blablanewbranch; svn switch blablanewbranch; svn commit"
<viric>
With attention at writting 'blablacurrentbranch', so it matches the version you are working *over*
<viric>
very simple :)
<wpwrak>
cd ../other-branch; edit; svn commit ? :)
<viric>
wpwrak: you did not explain branch creation
<wpwrak>
that's the approach svn experts recommended to me. or maybe it was an app-roach ?
<wpwrak>
mkdir ;-)
<viric>
no
<viric>
mkdir does not branch :)
<wpwrak>
it does. the directory hierarchy ;-)
<viric>
well, I mean branching from some files already comitted, not from a zero-files repository
<wpwrak>
yeah. doens't svn cp do that then ?
<viric>
yes
<viric>
I wrote svn cp, you wrote mkdir :)
<wpwrak>
ah, svn cp implies the mkdir ? didn't know that
<viric>
yes
<viric>
svn cp ^/trunk ^/branches/newbranch
<wpwrak>
i actually never created an svn branch. used some, though
<viric>
svn switch ^/brancheS/newbranch
<wpwrak>
i don't think i ever used svn switch, though
<viric>
But "^/trunk" may not be what are you working on....
<viric>
So, it's a little cumbersome.
<viric>
Not to mention that there is almost no way of getting a branching/merging graph.
<viric>
which I find quite useful.
<viric>
As the graphs would go per-file, and not per-tree.
<viric>
so
<viric>
wpwrak: when I said some VCS do better at history keeping, I was not trying to recommend svn :)
<wpwrak>
cvs then ? :)
<viric>
as my preference is not per-file graphs (like cvs or svn), but per-tree.
<viric>
There is monotone, fossil, even mercurial, who do quite a good job.
<viric>
I don't know bazaar.
<viric>
In any case...
<viric>
The drug of git spread.
<viric>
And every day more and more developers got comfortable in lying and rewriting their history of development before making it public.
<wpwrak>
one thing i rather like about git are its fast local operations. not sure how well the others do in that regard. at least bzr seems to like to "call home" from time to time. not as bad as svn, but still
<viric>
Any DVCS will not call 'home' if you don't tell it to do so
<wpwrak>
i really don't understand what you're complaining about
<viric>
:)
<viric>
ok
<viric>
I talk about git rebase, for example :)
<wpwrak>
git rebase -i ?
<viric>
-i, and without -i
<viric>
You write a commit log for a tree, and then you rebase that commit, while not changing the commit log.
<wpwrak>
well, without -i it has its uses for keeping branches up to date
<viric>
'merge' can also keep branches up to date.
<wpwrak>
yes, but in a different way
<viric>
In a way that it keeps the history of what happened.
<viric>
By rebase, you move things happened before, as if they happened later
<wpwrak>
what if you want a patch set you can submit ? then having merge points in the middle makes things messy
<viric>
And every commit log then talks about a *different tree* of what it was originally at time of writing.
<wpwrak>
it's still consistent
<wpwrak>
and it's up to you whether you need to update the commit log or not
<viric>
Because some people then describe in the commit log *the patch*, and not *the tree*
<viric>
And git becomes a patch manager
<wpwrak>
well, i would expect the commit lot to indeed describe the commit ;-)
<viric>
While git manuals claim continuously that git makes a graph of "a file tree", and not "of patches"
<wpwrak>
and yes, "patch manager" is precisely the role for which it would be used this way
<viric>
If you want a patch manager, you could use darcs, which is a VCS based on patches.
<wpwrak>
file = patch ? :)
<viric>
But the git graph is not of patches
<viric>
it's a graph of file trees.
<wpwrak>
details :) they're still commits
<viric>
haha
<wpwrak>
and a commit is a patch, from a user's point of vew
<wpwrak>
doesn't really matter how it's implemented under the hood
<viric>
then where would you claim anything about the state of a file tree, if not the commit log?
<viric>
as in "I tested this, and works"
<wpwrak>
perhaps in a mail asking upstream to pull / merge / whatever ? :)
<viric>
hahaha
<wpwrak>
obviously, if you make this kind of claims in the commit log, there's a risk of inconsistencies
<viric>
then better not to do claims about the tree
<wpwrak>
you have to decide whether the information is worth the trouble or not
<viric>
And once you rebase...
<viric>
How do you get back in case of wanting to know what happened?
<viric>
The reflog does not get public
<wpwrak>
well, human being are pretty decent at dealing with moderately inconsistent information
<wpwrak>
how do you know the statement was ever true ?
<viric>
wpwrak: I don't know if it was true. But at least context of the statement would be reproducible :)
<wpwrak>
maybe the committer already lied the first time. maybe he wrote " i tested it" because his boss told him to test it. but in reality, he didn't feel like working late, so he didn't test.
<viric>
if you go that way, we could stop using VCS at all ;)
kristoffer has joined #qi-hardware
<wpwrak>
he was in a hurry to get out of the office because he was going to a party. there, he got very drunk. forgot all about the last few hours. there was nobody else in the office. no chance of reproducing the context.
<viric>
;)
<viric>
You can also write a novel in commit logs, instead of explaining what you did there :)
<wpwrak>
some people seem to apply that context. particularly surrealists
<viric>
But I mean that git invites you, in quite enough operations, to unlink the context of the "commit log" assertions.
<viric>
With no possiblity of going back.
<wpwrak>
s/context/concept
<qi-bot>
wpwrak meant: "some people seem to apply that concept. particularly surrealists"
<wpwrak>
can't you rebase back ?
<viric>
back to what?
<wpwrak>
back to the previous base
<viric>
how do you know the previous base?
<viric>
What if there were conflicts?
<viric>
its lost. loooost
<viric>
:)
<wpwrak>
git rebase --abort ;)
<viric>
Git is the only VCS where I lost code. :)
<viric>
disappeared. shazam. :)
<wpwrak>
chances are it was still there ... just hard to find
<viric>
haha
<wpwrak>
git rarely loses things. but it's good at hiding them
<viric>
you have one month of reflog
<viric>
and garbage collection from time to time.
<viric>
(By default)
<wpwrak>
yup :)
<viric>
perfect :)
<viric>
Quoting a friend, /dev/null perfoms better ;)
<viric>
performs
<viric>
And I think next git versions may finally remember the branch names
<wpwrak>
in what way ?
<viric>
in history
<viric>
I don't know how.
<viric>
I heard the claim
<viric>
Now branch names disappear if you remove them (due to a branch being merged9
<viric>
)
<viric>
and history only shows a graph of unnamed branches
<wpwrak>
the merge commit will still tell you what you merged
<wpwrak>
and if it's a fast-forward, then you may simply have had a topic branch
<viric>
and all gets serialiezd.
<wpwrak>
not sure if you can force a merge commit, though
<viric>
serialized
<wpwrak>
that's often the idea
<viric>
I know
<viric>
I dislike all that :)
<wpwrak>
i just gives you more flexibility
<viric>
You get a serialized graph of commits with dates not matching anything at all the serialisation
<viric>
more flexibility at the expense of loosing history information of what happened.
<wpwrak>
phew. and if people don't NTP-discipline their clocks, i guess you go around and murder them in their sleep :)
<viric>
;)
<abushcrafterfor1>
dvdk: for the mplayer menu are you using its OSD menu feature?
<viric>
wpwrak: you are addicted ;)
<wpwrak>
if your VCS prevents you from having topic branches, but you want to work undisturbed on some changes, you'll then simply not switch branches or incorporate changes. and you may even cp your files away, update, then cp them back. where's your history then ?
<viric>
git addicted consider it very normal to hide or edit development procedures before sharing a private development graph.
<wpwrak>
it's nothing i hadn't done with CVS and SVN before
<viric>
wpwrak: what's different between branches and topic branches?
<viric>
git simply does not have operations to do what you want other than by loosing the history of what you do
<viric>
losing
<wpwrak>
nothing really. "topic branch" just narrows the purpose. i.e., it's work on the main branch, but you branch off it to avoid clashing with changes on the main branch (until you're ready for merging)
<viric>
many VCS support branches :)
<wpwrak>
"topic branch" is a user-level concept
<viric>
VCS let you use branches for whatever you want
<viric>
but some require more typing (like svn), but keep history (per-file, not per-tree)
<wpwrak>
(losing history) perhaps you should also ask developers to install a webcam so that you can record how they work
<viric>
wpwrak: haha :) ok
<whitequark>
pabs3: yes, it's MIT and already on github
<wpwrak>
i don't understand why you insist on preserving history that the developers don't want preserved
<viric>
Publishing the history of the files you work on is an attack against privacy.
<wpwrak>
see :)
<wpwrak>
also, when i try to follow development, i prefer a clear line
<viric>
git not only allows you to keep some things private. The git code sharing models I've seen invite you to keep your development private.
<wpwrak>
i don't really want to know all the small mishaps that occurred along the way and how they were reverted
<wpwrak>
i want to know the final solution that was finally found worth keeping
<viric>
that's the matter of a viewr.
<viric>
viewer
<whitequark>
viric: what do you think is the goal of DVCS, making code access more convenient or preserving some random sequence of actions no one cares about?
<wpwrak>
it's a matter of not wasting my time :)
<viric>
random sequence of actions?
<viric>
Who talked about random sequences of actions?
<whitequark>
yes, exactly
<pabs3>
whitequark: cool, thanks
<wpwrak>
(git code sharing) yeah, the pull model has that effect. but it's just one possible model.
<whitequark>
pabs3: just curious, what do you want to use it for?
<viric>
wpwrak: I've some complaints against git, lacking some features. But most of my complains go to that way of using git :)
Aylax has joined #qi-hardware
<viric>
whitequark: you consider your development 'random sequence of actions'?
<pabs3>
whitequark: nothing right now. maybe in the future it might be useful for adding support for some website to get-flash-videos
<whitequark>
viric: in essence, yes. "git rebase" allows you to take your commits and rework them in a way which actually makes sense from a logical perspective.
<whitequark>
e.g. "one encapsulated change" = "one commit"
<wpwrak>
viric: i find that my development often consists of actions based on a lack of comprehension
<whitequark>
that greatly helps with reviewing, bisecting, searching bugs, viewing logs and whatnot
<wpwrak>
viric: there's very little value for others to follow my through process at that level
<wpwrak>
s/through/thought
<qi-bot>
wpwrak meant: "viric: there's very little value for others to follow my thought process at that level"
<whitequark>
^ that.
<wpwrak>
whitequark: exactly :)
<viric>
well, it's clear where we disagree. I think it is of great value to have the history of what happened.
<viric>
There is no reason to destroy that.
<whitequark>
viric: I gave you a reason
<wpwrak>
viric the historian ;-)
<viric>
whitequark: presenting a development and the history of the development could be both stored.
<pabs3>
whitequark: whats this abcdump.abc file?
<whitequark>
pabs3: an ABC bytecode dumper, compiled from Tamarin sources
<viric>
You could present what you want others to care of your development in the log of a merge, without destroying the history of what you did. But git addict peoples *first* think on destroying what they did, and then think out how to present it anew.
<whitequark>
now you're making personal attacks
<viric>
haha
<whitequark>
(not that I care)
<viric>
well, I already said that I'm against how many users use git.
<viric>
not against the software. :)
<whitequark>
and on merges... when bisecting or reading log, you don't pick a giant merge and then dig into how it works
<viric>
Against, in a sense that I dislike that approach to sharing code.
<whitequark>
you just read the descriptions for the commits which do actual work
<viric>
I understand, yes.
<viric>
You take the graph of commits as if it was a way to show a development, and that can be unrelated to how you did the development.
<whitequark>
can you suggest a reason for preserving exact development path?
<whitequark>
also
<whitequark>
what should I do if I accidentally committed 110MB of .o files in?
<viric>
:)
<whitequark>
or a bunch of non-free patent-covered code
<whitequark>
or whatever
<viric>
The VCS software should let you do all you want.
<viric>
fix those cases, too.
<viric>
But I don't think it should *invite* to destroying how you did the development.
<whitequark>
viric: what value the data about "how did you do the development" has?
<viric>
The effect of that is that some developers get addicted to that model, and then they get ashamed of showing their development publicly
<wpwrak>
zero
<whitequark>
would you also suggest to store the data about disk drive head moves in the DVCS?
<whitequark>
just because you can
<wpwrak>
or perhaps even negative, because you may rely on that "information"
<whitequark>
and hey, it's DATA! let's preserve it
<viric>
Yes, I consider the history has some value
<whitequark>
what value?
<whitequark>
for what could it be used?
<viric>
in understanding what you did one thing or the other. But well, you can also go on writing misleading commit logs too, and then have no value in that
<whitequark>
in real world, that is. for what business task would you use it?
<viric>
If you do 'random commits', there is no value.
<viric>
:)
<whitequark>
people generally do mistakes most of the time
<wpwrak>
if there was something important you learned in the process, then you should document it. a VCS that preserves every keystroke would invite you to not do this, because the "information is already here"
<whitequark>
hence, commits are generally random
<viric>
ok
<whitequark>
hint: visualizing the history of project developing, or, I dunno, tracking the count of code lines written by each developer, or something like that is not a business task
<whitequark>
it doesn't add any value to your work
<whitequark>
for a FOSS project a "business task" could be considered as some task which could help it gain more users
<whitequark>
or compete better with non-free replacements
<viric>
clear, I understood about the value of random commits, and I agree.
<whitequark>
what we're writing software (including FOSS) for? sharing the source? actually no, that's just a way to do it more effectively. we write software to do real work.
<whitequark>
(if someone thinks that he should write a piece of software exactly for sharing the source, you're unfortunate enough to get gcc.)
<viric>
Maybe it is that I consider my commits (and those of who I work with) not that random
<whitequark>
viric: ok, let's only look at "non-random" commits
<whitequark>
what the history of these commits could be used for?
<viric>
1) I think it helps understanding the situation in case of troubles
<wpwrak>
a typical case would be that you do thing X. then you realize that X doens't solve the problem properly, and you do Y instead. now, if you think it's likely that someone else would also think X is a good or maybe even better solution, you should write a comment right there.
<viric>
2) It can allow others to understand ways of finding solutions to problems
<viric>
3) And it can help others not feel shame for their way of working
<viric>
I'm hitting more and more cases of paranoid people who don't accept anything other than git due to '3'
<whitequark>
so, basically, you state that a VCS must store the code in such a way that novice developers could learn from it, and force everyone else to do their work in a way which would help these novice developers?
<wpwrak>
perhaps you;re misinterpreting their motives
<whitequark>
because 1. is solved by debugging, not digging into VCS logs. if you have a piece of code which doesn't work, you insert some checks in it and see where did it go wrong.
<wpwrak>
whitequark: it sounds more as if he's asking for the VCS to keep tons of useless information around, making it harder to find the relevant information
<whitequark>
wpwrak: I'm trying to understand the motive
<wpwrak>
viric: do you read all your mails ? including the spam ? :)
<viric>
I would almost not call git a VCS, but a code-share system
* whitequark
facepalms
<wpwrak>
whitequark: maybe we just have to wait until the drugs wear off :)
<viric>
Well, I think I'll leave the talk in disagreement :) we have all different motivations
<whitequark>
wpwrak: ROFL.
<whitequark>
I'll just go destroy some history
<viric>
hehe
<viric>
yes, noone should care on the random commits :)
<whitequark>
I can't even imagine what would happen to Linux if the commits in it would be like you're suggesting
<whitequark>
because when I ported it to a some MIPS device, I did a ton of different commits over several weeks, and shared that with others who tried to hack on it too
<whitequark>
only maybe 10% of that code was useful enough to get into the final version
<whitequark>
and I have spent a lot of time rewriting it into a form where each commit was self-contained and you could actually read it and get what would happen when you apply it
<whitequark>
because otherwise it was a huge heap of intermingled parts of different experiments
<whitequark>
and I'm quite sure it's not just me who cannot develop good enough software^Wcommits
<viric>
who goes to the linux git and wants to see "how is linux developed"?
<whitequark>
erm. what?
<viric>
I mean
<viric>
I think of use cases where people want to know about the development of a very particular piece
<whitequark>
when my device hangs instead of going to sleep after some commit, I go and bisect it
<whitequark>
then I find the piece of code which caused this
<whitequark>
I want it to be a carefully written 5 lines of code with 10 lines of description which tells me everything about how it works
<viric>
We have too separate visions to make them common in a short time :)
<viric>
I leave the talk for another day :)
<whitequark>
not a 100+ line diff with all the shit which was in the head of developer and some babbling instead of comments
<whitequark>
ok
<wpwrak>
whitequark: in fact, with viric's approach, you'd most likely hit a branch you later rejected
<wpwrak>
whitequark: bisecting assumes a perfect world of linear development. reality is different, but still close enough that bisecting is often useful. if you kept all the junk around, too, then that would rarely be the case.
<wpwrak>
whitequark: of course, you could keep the junk around AND tell your vcs what the things are that you finally kept, but i doubt a lot of people would make the effort of keeping this sort of information in good shape
<whitequark>
most of people just commit all the junk to git and don't care
<whitequark>
and this is SO annoying
<whitequark>
in 80% FOSS projects, notably those with 1-2 developers, commit logs are of no value at all
<whitequark>
precisely because of the no-rebase approach
<wpwrak>
if you're a good upstream for them, you then simply send them back for cleanup :)
<whitequark>
that works for kernels, or maybe for gcc
<whitequark>
in the world of web-development it doesn't. people either really don't understand/know how to use good programming practices, or don't have enough time to do the right thing
<wpwrak>
well, web-development ... most of that is bottom-feeding anyway ;-)
<whitequark>
bottom-feeding?
<whitequark>
you mean the model of consuming content in web?
<wpwrak>
a lot of the work that goes into presenting that content
<whitequark>
I don't care about the web itself in this context. I'm talking solely about the development of software to drive the web.
<whitequark>
web is moving fast
<pabs3>
both are horrible
<whitequark>
way faster than you can keep with and write good software
<whitequark>
that's why we have PHP, for example
<whitequark>
or consider Rails, my framework of choice. it's somewhat good; for example, at one point the core team decided to take a break and spent a year on major refactoring
<wpwrak>
many things have no need to move fast all the time. eventually, your core functionality will settle. or you're screwed anyway :)
<whitequark>
it was a very good decision.
<whitequark>
Rails itself and a bunch of libraries (less than half a dozen) which are used very often are written really good
<whitequark>
80% of other software associated with it (plugins, tools, etc.) definitely isn't
<whitequark>
and this is a good statistics if we take the overall web-related software
<whitequark>
in this case it happened this way because, I think, some Ruby features make you stop for a minute, think about what you're doing and then write some good code, because otherwise it just won't work good
<whitequark>
nah. just take a look at node.js.
<whitequark>
all of the former jquery monkeys use it. you can see the result.
<whitequark>
when you're a "jquery programmer" (hint: it's like "boost programmer" for C++), it isn't any good
<viric>
the peaceful world of nanonote does not follow it...
<viric>
but there is dbus, udev, devtmpfs, consolekit, policykit, upstart, systemd, ...
<whitequark>
and if you'll put these things on NN it would be out of RAM even before it could start a login shell
<whitequark>
dbus+consolekit+policykit+systemd+pulseaudio would easily exceed 32MB of ram.
<viric>
I think all that makes the system harder to understand
<whitequark>
yes and no
<whitequark>
dbus is a bit more complex than each of distinct incompatible IPC methods in different apps, but it's standardized and now everyone uses it
<viric>
then extended acls, containers, creating namespaces, capabilities, cgroups, ...
<whitequark>
understanding dbus 1 time is easier than understanding 10 simple IPCs 10 times
<lindi->
viric: one large problem is that many admins do not want to learn these
<whitequark>
well, the truth is: OS are complex, because tasks they must do are complex.
<viric>
lindi-: well, these are new things to learn, and some of the things that have been, don't last long
<whitequark>
it's not a fake complexity out of nothing, these are solutions to real-world problems
<lindi->
viric: so they can not debug them when they do not understand how they work
<viric>
yes.
<lindi->
viric: yep, you need to be motivated to learn and play with them to master them
<lindi->
just reading some documentation can never be enough
<viric>
that's far more complex than init rc scripts, not hotpluggable devices and normal user permissions for files and processes :)
<lindi->
viric: depends. if you start from nothing then shell scripts are confusing too
<DocScrutinizer>
mooo
<lindi->
viric: but of course they have the benefit that you can ask your friend
<whitequark>
DocScrutinizer: it's 15:40 here. should be something like 12:40 where you live. morning? :D
* DocScrutinizer
patches hi screen with postit notes "cgroups!" "namespaces" "containers"...
<DocScrutinizer>
~ugt
<infobot>
somebody said ugt was Universal Greeting Time. Created in #mipslinux, it is a rule that states that whenever somebody enters an IRC channel it is always morning, and it is always late when the person leaves. The local time of any other people in the channel, including the greeter, is irrelevant. http://www.total-knowledge.com/~ilya/mips/ugt.html
<DocScrutinizer>
duh, useless effort, she's on your /ignore iirc
<whitequark>
nope
<whitequark>
I'm not wolfspraul or whoever here hates bots
<DocScrutinizer>
lindi-: :-D
<lindi->
well you just filled my entire screen yes :(
<DocScrutinizer>
sorry
* DocScrutinizer
shuts up and wandes off
* DocScrutinizer
...while wondering about lindi- 's screen size
<whitequark>
DocScrutinizer: > Resistance is futile. Your ass will be laminated.
<whitequark>
I prefer my ass in its current state...
<wolfspraul>
I read on the kicad list that they have committed the new board/layout file format
<wolfspraul>
let's see how that goes
<wpwrak>
whoa ! let's see what they write ...
<wpwrak>
okay, write-only so far. but it seems that they plan to keep both formats around for now. that's good.
<wpwrak>
btw, one of the nice things in recent versions of kicad is that metric grids now work without weird rounding issues. didn't check if it's in fact an internal change (i.e., the switch to nanometers) or if the artefacts of using an internal imperial-based unit are simply covered up. may be the latter. but it still helps.