IRC channel logs


back to list of logs

<janneke>OriansJ: wow, that's *interesting*
<OriansJ>because if someone could build tinycc or pcc with one of those or an extended version of those. I could manually implement one of them in assembly
<rekado>OriansJ: that’s very cool!
<janneke>ACTION adds pointers to mes
<OriansJ>rekado: any C program that sticks to structs, pointers, ints, bytes and strings can be manually converted to assembly by me
<bavier>all these people with their c compilers, and I'm still just getting mine started
<civodul>noooo? :-)
<OriansJ>bavier: just please don't bother to implement the full C syntax
<janneke>oh my...are we going to have a smorgosbord of C compilers
<bavier>OriansJ: yeah, I'm targeting tcc or 8cc
<OriansJ>bavier: I'd love to see what you have
<OriansJ>janneke: the problem is that most of them require a preprocessor and I don't know a single person who is willing to write one in raw C
<janneke>OriansJ: Nyacc includes a C processor :-)
<civodul>oh the new license box at github is not bad:
<civodul>ACTION is positively surprised
<janneke>It's only dependency is a decent Mes ;-)
<rekado>civodul: I also like it. Its terseness might be a problem in some cases, but it does a much better job than their license chooser.
<OriansJ>janneke: dumb question but would it be possible to strip Nyacc down to just a C preprocessor and minimize the level of lisp required?
<rekado>ACTION —> zzZZ
<janneke>OriansJ: I would really like to get Matt Wette involved in [our] bootstrapping discussions
<janneke>Nyacc has quite heavy Scheme dependencies, like syntax-case, R7RS ellipsis, fluids, regexps even
<janneke>ACTION possibly forgot some
<janneke>that makes sense when you don't have bootstrapping in mind, of course
<OriansJ>janneke: hence the question of just the preprocessor part of Nyacc. Aka we use lisp to function as a C preprocessor and then can use a stripped C compiler
<janneke>OriansJ: I think that should be possible...not sure though why you wouldn't [want to] write the rest of theh C compiler in LISP/Scheme too?
<janneke>Having cpp available in Nyacc (it's not finished but Matt has worked very hard on it the past months) is of course a great start!
<OriansJ>janneke: it is always easier to implement a C preprocessor and a single file C compiler than a single step C compiler
<janneke>OriansJ: ah, I see. You just want to have the option of having a separate cpp
<janneke>that makes sense; we'll have to ask Matt!
<janneke>ACTION added a roadmap to Mes:
<OriansJ>janneke: exactly, and it should really simplify the problem
<OriansJ>no need for #define, #include, or any conditional compilation logic at all
<janneke>OriansJ: sure, that's how Mes's c compiler (Mescc) works; Nyacc simply provides an AST; cpp stage is handled implicitly by nyacc
<janneke>ACTION -> zZzz
<gazon>"Please only recommend the GNU Guix distro, and stop recommending other distros that cannot ship security updates promptly."
<buenouanq>ACTION thumbsup
<CharlieBrown>gazon: Parabola?
<CharlieBrown>gazon: I can't see that page.
<gazon>CharlieBrown: I don't know. The speaker (that link is a presentation slide) was talking about FSF endorsed distros being the most resource constrained link in a chain of security updates from source to user. Those distros are less secure as a result.
<CharlieBrown>gazon: Oh. I DL'd that vid earlier.
<buenouanq>Knowing GuixSD exists and how great and beautiful it is, I can't in good conscience recommend anything else to anyone anymore.
<gazon>CharlieBrown: that presentation slide thing is javascript driven
<CharlieBrown>gazon: Is it libre?
<gazon>CharlieBrown: what, the javascript?
<gazon>CharlieBrown: I don't really know. Some of it is MIT licensed ( and some has no license (
<gazon>buenouanq: I am close to replacing Trisquel with it, but, as a non-scheme literate software dev, I am trepidatious.
<CharlieBrown>gazon: Welp. It's nonfree, then. Could you contact the maintainer?
<CharlieBrown>gazon: Guix for daily computing? !!
<CharlieBrown>gazon: Also, which MIT license are you speaking of? The Expat license, or the X11 license?
<gazon>CharlieBrown: Expat probably. It just says MIT which, given it's hosted on github, means expat.
<buenouanq>gazon: You don't have to know any scheme to use GuixSD as your primary OS.
<buenouanq>Granted, you'll be missing out.
<buenouanq>You're missing out as is though just for the mere fact that you don't know Scheme ┐( '~')┌
<gazon>buenouanq: true on both counts, but I still need to be able to build software, fire-up virtual machines, etc. and it seems to me that if I need a package in a hurry then I need to known guile to get one made.
<gazon>which I am beginning to learn.
<CharlieBrown>Hey, where's that vid where someone completely hardens an X60 and it becomes nearly useless?
<CharlieBrown>No USB, no ethernet, etc.
***Piece_Maker is now known as Acou_Bass
<kadintrooper>Hey Guix :)
<kadintrooper>Anyone know if someone has a package description for tdesktop laying around anywhere? I'm having difficulties importing it from nix
<CharlieBrown>Sigh... I need to make a multiboot flash drive with all the libre distros on it.
<CharlieBrown>GuixSD, Dragora, Parabola, Trisquel, gNewSense...
<kadintrooper>Whenever I try using guix import nix I get a stack overflow
<kadintrooper>ice-9/boot-9.scm:68:2: Throw to key `vm-error' with args `(vm-run "VM: Stack overflow" ())'.
<kadintrooper>error: stack overflow (possible infinite recursion)
<reepca>Which of the GSoC suggestions would you recommend for a sophomore computer science student who's been learning lisp (specifically common lisp) in their free time?
<janneke>reepca: the one they like best! ;-)
<reepca>Hm, unfortunately they aren't quite certain where the balance between "too hard" and "can't fill a summer with it" lies. Both because they aren't certain of their skills and because they aren't certain of the difficulty of the tasks.
<reepca>The build tool seems like it would require the least specialized knowledge, but I don't have a very good idea of the scope of the project.
<reepca>Specifically regarding the build tool, it says "... should ultimately be able to run complex workflows on multiple servers and...". What exactly is meant by that? That the build process should be able to be distributed across servers?
<janneke>reepca: I guess, but better ask later when more of GMT+1 is awake ;-)
<reepca>Alright, I've just got myself in a bit of a pinch here with delaying so long getting this stuff figured out.
<janneke>but esp. wrt to your remark of striking the balance, I believe that if someone chooses a project that they really want to do, they can accomplish amazing things -- whereas when it's `just work' they will `probably do okay'
<janneke>and there are mentors to help with any questions, of course
<ofosos>hi guix
<janneke>hi ofosos
<rekado_>hi janneke, hi ofosos!
<rekado_>even the rebuilt icecat crashes whenever I load up any web page.
<rekado_>segfault and sigpipe, dependent on which URL.
<janneke>rekado_: when oh when do we get a sensible browser built in emacs
<rekado_>heh, it just moved up a couple of steps on my TODO list :)
<janneke>i've been using conkeror for a while now, and it's a fair prototype of what is possible
<ofosos>rekado: hmm, seems to be a general problem, should i hit submit crash report or is this going to /dev/null?
<rekado_>ofosos: I’m using icecat from core-updates. I don’t have these problems with icecat from master.
<rekado_>I don’t think the crash report thing actually works.
<rekado_>ACTION installs conkeror
<ofosos>grml, i'm having constant crashes
<rekado_>ofosos: in about:config search for “cairo”
<rekado_>ofosos: do you see any entries that match?
<rekado_>if so, you can try to change the values to “skia”
<ofosos>yep, it's
<ofosos>ok, i'll change these and see
<rekado_>changing this to “skia” has solved the problems for me
<rekado_>(just not on core-updates)
<ofosos>thanks for the info :)
<catonano>the linux libre 4.9.x has a wrong hash
<catonano>what does this mean ?
<janneke>catonano: do you notice the sha256 mismatch?
<catonano>I do
<catonano>I don't understand hhow that is possible. I was trying to bild a vm image
<catonano>the hash declared in the linux-libre-4. definition is 19x6hasx7...
<catonano>and the downloaded tarball has 1864sbq2r...
<catonano>how iis that possible ? Wasn't the kernel package checked ? Or is the tarball changed ?
<rekado_>efraim: it seems that the change in wxwidgets from the old webkitgtk to the latest webkitgtk broke the webview, webkit, and webviewwebkit features.
<rekado_>efraim: this causes aria-maestosa to fail.
<catonano>yes the tarball is changed
<catonano>it's 4.9.19, the definition is for 4.9.18
<janneke>catonano: i also get hash: 1864sbq2r5y7fi26hla9k4avzs6sprkpgwpq8gi0sr39i58z6hnz
<catonano>janneke: I downloaded and hashed it locally and I get the same hash
<catonano>I don't understand
<janneke>we'll have to ask mark_weaver about this commit
<janneke>commit f62acf1eb7ae9f3a582e897abbbfb229f112b31e
<catonano>anyway, I just moved to "linux-libre" and it works. It ust built an image
<catonano>in the aternoon I'll try to run that image
<catonano>janneke: thanks, anyaway
<janneke>catonano: sure; good to bring this up; possibly post to guix-devel
<OriansJ>janneke: have you considered the idea of a lisp compiler written in lisp?
<janneke>OriansJ: paroneayea mentioned that to me; i briefly looked at preScheme
<janneke>in fact, that's one of the most difficult things about full source bootstrapping/Mes: there are somany possibilities
<janneke>which to choose, which to do first?
<OriansJ>janneke: Why not choose what looks easiest?
<paroneayea>rekado_: glad to keep the boring dreams going :)
<paroneayea>rekado_: and yeah I've thought of maybe adding something CLIM like to emacs w/ EIEIO
<OriansJ>janneke: literally the most trivial single step solution. Then we can work on the step before that
<janneke>OriansJ: why not indeed? That's exactly why I chose Mes...
<[df]_>hard to tell what's easiest without trying, but that I think that's what janneke's doing
<janneke>[df]_:'s the `looks' in OriansJ's `looks easiest'
<janneke>it very depends upon who is looking, and what things are already there to see
<OriansJ>indeed janneke
<janneke>i can easily imagine that nothing of current Mes will remain one year from now
<janneke>I's just: writing a scheme interpreter seemed easier to me than a lisp compiler
<janneke>and that I figured: we need a C compiler, and if I'm to write one it will be in scheme
<[df]_>it's great that someone's putting in the effort to explore it though :)
<janneke>indeed, we have several someones, which is even much better
<OriansJ>janneke: that is because writing a compiler is 20 times harder than an interpreter
<OriansJ>for example, someone could write a C interpreter much faster than they could write a C compiler
<OriansJ>Hell with some creativity, anyone willing to hand write a C parser could convert my lisp interpreter into a C interpreter with a couple weeks of work
<OriansJ>[df]_: what is great is that our trusted binary only needs to contain this: [Which I hand converted to hex in a couple hours of work]
<OriansJ>[df]_: With stage0, one only needs to audit 2792 bytes for a full assembler
<jmi2k>How can I use qemu kvm without sudo?
<[df]_>OriansJ: nice
<[df]_>will have to look into it more when I'm more awake
<OriansJ>[df]_: This might be helpful
<OriansJ>The hex0 files are just pure hex (any hex compiler can build them), the hex1 have 1 character labels and hex2 have long label support
<[df]_>is this for x86 (32)?
<janneke>OriansJ: so if we use stage0->lisp; we only need to trust ~3kB
<OriansJ>[df]_: it is completely portable, produces identical results on PowerPC, MIPS and x86
<OriansJ>janneke: less than that actually (280 bytes)
<OriansJ>everything else has full source and comments relating each line of hex to its assembly code with a direct 1:1 relationship that makes auditing easy
<janneke>it should be quite easy to translate mes.c scheme interpreter into your lisp
<janneke>but i worry a bit about performance
<OriansJ>stage0 even has a hand written text editor for those wishing to do a complete hardware level bootstrap with no other sources
<OriansJ>janneke: performance, would only matter if we needed to run that code often
<janneke>OriansJ: sure
<janneke>it would be nice if we could build tcc in less than a week or so, though ;-)
<OriansJ>janneke: I agree :D
<OriansJ>However, stupidly simple code is written faster than code that runs fast
<OriansJ>I'd rather waste CPU cycles than programmer cycles
<[df]_>bootstrapping is worth taking time over
<OriansJ>We can always go back and improve the performance after it is working
<janneke>quite agree
<janneke>ACTION has nailed two problems running Nyacc's cpp on mes
<OriansJ>good job janneke
<janneke>thanks OriansJ!
<janneke>looking at your you have some example programs that it can run?
<janneke>what are the features/restrictions?
<OriansJ>janneke: I broke out the lisp interpreter here:
<OriansJ>I took a couple liberties but here are some examples:
<OriansJ>and I can add primitives pretty easily
<janneke>beautiful -- so much fun to read your take on minimal list!
<ZombieChicken>Anyone else notice how guix system reconfigure's tab completion is broken out of the box and you can't tab complete the config file?
<OriansJ>janneke: why thank you :D
<OriansJ>janneke: You might like the exact garbage collector , I later simplified it further ;-)
<janneke>OriansJ: that's mark and sweep?
<janneke>wow, that looks actually like code i could understand -- need a bit more time
<OriansJ>janneke: yep and it perfectly collects everytime
<OriansJ>took about a couple hours of thinking but only about 20 minutes to write.
<janneke>OriansJ: wow
<janneke>took me two weeks or so to write mine (well, an afternoon to write, rest to remove bugs)
<OriansJ>janneke: the benefit of trying to solve a simpler problem
<janneke>the current version has some workarounds and ifdefs for mescc, this is last clean version:
<OriansJ>janneke: I like it, probably runs faster than mine too
<janneke>the up/downside is that mes uses index-based cells, you are using pointer-based car/cdr right?
<janneke>OriansJ: it's actually stop-and-copy `straight (cough)' from SICP
<OriansJ>janneke: bingo and my has a fixed number of cons cells that never move
<OriansJ>garbage_init literally just takes a chunk of memory and says here is all of the cons cells you will ever need.
<OriansJ>using free_mem, you can see exactly how many cons cells your expression consumes
<OriansJ>toss it at the end of a begin and you'll see how many cons cells your expression evaluation requires.
<OriansJ>Which means (minus the memory space consumed by input/code) the memory space is constant
<ZombieChicken>Is there any way to get to a terminal when using X? It's just dropping me in a login screen w/o any apparent way to get a terminal
<OriansJ>ZombieChicken: you can use tty1 or tty2 and run xfce4-terminal --display :0 to spawn one
<ZombieChicken>I was trying to get to a TTY. The problem is I don't have a terminal installed for root, and would prefer to just not use X for root anyways
<OriansJ>ZombieChicken: Ctrl+Alt+F1 or Ctrl+Alt+F2
<ZombieChicken>and su is, as far as I can tell, entirely broken.
<ZombieChicken>OriansJ: Thanks. I can't test that because I'm in a VM and it switches my host system's terminal.
<janneke>ZombieChicken: what about sudo -i
<OriansJ>ZombieChicken: what virtualization software? because you could leverage key capture
<ZombieChicken>OriansJ: qemu w/ -usbtablet so I don't have to deal with input capture. I know why the problem is a problem, so I'll just avoid it for the time being
<ZombieChicken>janneke: I don't have sudo setup?
<ZombieChicken>that actually works. Huh
<ZombieChicken>Great. sudo -i works, then my "L" key no longer works in the terminal...
<ZombieChicken>Had to kill the term then start a new one to get that back...
<OriansJ>ZombieChicken: You know you can tie keyboard capture release to a single key (like mod4) right?
<ZombieChicken>That would clobber other keybinds
<ZombieChicken>For instance, I use Mod4 for my window manager
<ZombieChicken>I'm dding the .img to a USB and I'm going to reboot to test it in a few
<OriansJ>ZombieChicken: mod4 was just an example, you could do things like F12 or Caps Lock
<ZombieChicken>Well, like I said I know why it doesn't work
<ZombieChicken>so it's somewhat of a nonissue for me
<ZombieChicken>I'm just using it to test a liveusb img anyways
<OriansJ>Wow, I am dumb. I just realized I implemented line comments for my lisp in assembly but didn't bother to add it to the C version >.<
<ZombieChicken>OriansJ: For the sake of everyone, think about implementing docstrings. They can be really useful
<ZombieChicken>It's one thing Scheme lacks that I kind of miss from CL
<ZombieChicken>or is that just a toy implementatin
<OriansJ>ZombieChicken: It is a lisp written in assembly that is only 6320 bytes large
<ZombieChicken>so picopicolisp?
<OriansJ>Think stage0, everything one needs from a 280 byte hex monitor to fully working forth, lisp and eventually complete C able to compile gcc
<ZombieChicken>Maybe I havn't had enough coffee this morning, but are you saying you're wanting to build GCC w/ this lisp of yours?
<OriansJ>ZombieChicken: No, I am wanting to help others build GCC using a minimal bootstrap binary and a complete chain of trust
<OriansJ>making a lisp and a forth are just attempts at helping others in the achieving of this goal
<OriansJ>I'll even do interpreters and compilers for other languages if they would help in that goal. (I even wrote a text editor in assembly for those doing bare metal bootstraps)
<ZombieChicken>OriansJ: x86/x64?
<OriansJ>ZombieChicken: PowerPC, MIPS, SPARC, x86, AMD64, RISCV, 6502, z80, etc
<CharlieBrown>Mm... RISC-V...
<ZombieChicken>I'm waiting for a good ARM desktop
<ZombieChicken>maybe running one of those new fangled FPGA+ARM chips
<OriansJ>ZombieChicken: good at what exactly?
<ZombieChicken>Gaming, ideally
<ZombieChicken>Honestly, anything other than x86/64 would be good today. We need a new arch that isn't insecure by design
<ZombieChicken>OriansJ: Do you know anything about binary translation?
<OriansJ>ZombieChicken: yes but please understand nothing of use is 100% secure. It is only about how expensive it is to compromise the system
<ZombieChicken>I'm aware, but crap like Intel ME is just flat broken by design
<OriansJ>ZombieChicken: Then buy an IBM x200 and install Libreboot
<OriansJ>It doesn't have Intel ME
<ZombieChicken>OriansJ: Old, unsupported, and outdated Thinkpads? Again?
<ZombieChicken>When I get the money I'm probably going to look at getting a Novena
<ZombieChicken>and maybe see if a software-defined radio works for wifi
<rekado_>(I have an x200 and it’s not the best machine to be constantly compiling software; but other than that it’s fine.)
<ZombieChicken>Having run Gentoo on a 2.5GHz P4 once upon a time, I'm here to say you can compile software on almost anything with enough patience and proper nice levels
<OriansJ>ZombieChicken: then buy the Vikings D16 Mainboard
<ZombieChicken>OriansJ: I'm unfamiliar with that board. What CPU does it use?
<ZombieChicken>Nice. Yet more outdated hardware...
<OriansJ>ZombieChicken: What is wrong with 32 core and 256GB of Ram for a desktop?
<ZombieChicken>and for the low, low price of 833 Euros...
<ZombieChicken>OriansJ: My desktop already predates the ME-style backdoors, and supporting obsolete hardware does no one any good
<braunr>uh i disagree with that
<ZombieChicken>nor does endorsing outdated hardware
<braunr>it actually does
<ZombieChicken>Mind explaining?
<braunr>well i have, and have seen, lots of old hardware in use
<braunr>especially in companies
<OriansJ>ZombieChicken: Some people actually value their freedom, even if it is inconvient or costs more
<braunr>besides, the x200 is 300 eE
<braunr>which is reasonable for what it is
<ZombieChicken>OriansJ: Yes, but suggesting a constantly dwindling supply of outdated systems doesn't help matters. Better to spend the money on open hardware and non-x86 systems than sinking it into old, refurbished hardware
<OriansJ>ZombieChicken: That is why RISC-V Systems are being developed
<braunr>if that non-x86 system is actually more advanced than the old refurbished hardware
<ZombieChicken>I understand why old hardware is suggested, just stating that the money is better put in other places
<braunr>people seem to severely underestimate all the research put into that old and quirky total-store order architecture in order to make it that fast
<janneke>ZombieChicken: won't that take some time?
<ZombieChicken>OriansJ: As I understand it, RISC-V isn't there yet, and I'm not aware of a production-ready system that's using it
<OriansJ>ZombieChicken: Some people want freedom now and that might consume some money that might be better invested for freedom later but that is their choices
<ZombieChicken>janneke: Time and money, but I'd hazard a guess and say that money is one of the bigger problems
<janneke>aren't those the options: spend money to get freedom now, invest money to get freedom later?
<ZombieChicken>braunr: Are you refering to x86?
<OriansJ>ZombieChicken: New hardware is expensive and takes time
<OriansJ>exactly janneke
<ZombieChicken>OriansJ: and won't be developed if there isn't a market for it, thus putting off the time when it's actually viable
<janneke>ZombieChicken: money is a means, there's plenty of it if you have a good plan
<braunr>i think time matters more actually
<OriansJ>ZombieChicken: there already is at the low end
<braunr>and most people don't do things that require true high end hardware ..
<ZombieChicken>janneke: Yes. I'm just suggesting we're better off looking for new systems than sinking money into old.
<OriansJ>ZombieChicken: You can buy a high end Power System right now if you wanted
<ZombieChicken>braunr: Define "true high end hardware". Are we talking gaming rigs here, supercomputers, or massive clusters ala Roadrunner?
<braunr>gaming yes
<braunr>most people don't play
<ZombieChicken>OriansJ: I'm aware. I'm also aware of the cost of those systems.
<braunr>or play games that don't need the latest stuff
<braunr>and considering the very low quality of game code, don't expect it to be ported to arm without lots of accidents
<ZombieChicken>braunr: "most", maybe. I've argued for some time that most people would be happy with a 1ghz p3 and half a gig of RAM if software wasn't bloated
<braunr>we agree then
<braunr>what's the problem with the old vikign stuff ?
<OriansJ>ZombieChicken: There are no "Clean" solutions, only a community trying things together
<braunr>OriansJ: i don't mean to be harsh, but i really don't see how those proverbial answers could help anyone :/
<ZombieChicken>1) it's already outdated, so if something goes wrong finding a replacement will become steadily harder, 2) unless you're unfortunate enough to have a "modern" ME-included system, you're better off spending the money on something with a future, like ARM or whathaveyou
<braunr>1/ is countered by the fact that lots of those are still around, well supported
<braunr>they're actually reference platforms for "outdated"
<braunr>2/ no, the future is full of bugs, if you want something that works, you want old
<braunr>and i insist again on total-store order
<braunr>x86 by design makes parallel code less buggy
<braunr>most programs just explode when ported to smp arm
<braunr>and finding those bugs can take a _huge_ time
<braunr>where x86 is already much faster, with the increased guarantees
<ZombieChicken>As OriansJ pointed out, there is more than just ARM out there
<braunr>so again, what's the problem
<braunr>what's the subject of the discussion ?
<braunr>is it system managment mode ?
<ZombieChicken>I think it was whether it's better to spend money on old hardware or x86/64 alternatives
<OriansJ>braunr: I think the problem is that we need a better sales pitch in regards to hardware to win the mass consumer market
<braunr>"win the mass consumer market" ?
<ZombieChicken>That won't happen unless Intel, AMD, MS, et al basically blow up
<braunr>well i'd definitely go with old x86
<braunr>like, _definitely_
<ZombieChicken>On a somewhat related note, is there a working RISC-V system out there, or is it still an acedemic research project?
<braunr>i don't know what your job or experience is, but as a "real-time embedded engineer" (yeah the full blow J2EE-arrogant like label), i've seen lots of things
<braunr>and x86 just beats them all
<braunr>the only real problem for "freedom" or rather, security, is sms
<ZombieChicken>I've heard arguements to the contrary from Big Iron sysadmins
<OriansJ>ZombieChicken: Yes, I have one that I got for $55
<braunr>ZombieChicken: i don't know what to tell you
<braunr>i program operating systems, and i've been working with a friend on performance monitoring for some time
<braunr>i'll stick by my numbers
<ZombieChicken>braunr: Honestly? It may just come down to the difference in needs between mainframe needs and embedded needs
<braunr>uh no, i'm not talking about embedded needs
<braunr>that's just my job, but i've seen all kinds of things
<ZombieChicken>OriansJ: Mind sharing specs?
<braunr>and i'm certainly not talking about "embedded x86"
<braunr>i'm talking about low-to-high end processors
<ZombieChicken>braunr: Regarding your previous comment about x86 parrellel code blowing up on ARM, is that absolutely a flaw in ARM, or a flaw in execution (either from the compiler, interpreter, or programmer)?
<braunr>software flaw
<braunr>because arm has a very relaxed memory model, the most relaxed after alpha
<braunr>whereas x86 has the most restrictive
<braunr>which should make the arm perform better
<braunr>and somehow x86 (actually more intel) processors are orders of magnitude faster
<OriansJ>braunr: Sounds like lazy developers with bad hardware assumptions
<braunr>(for the arm implementations i've seen though)
<braunr>uh, no
<braunr>i wouldn't say "lazy developers"
<braunr>well yes they're lazy :)
<braunr>but that doesn't explain it all
<braunr>schools don't teach properly, specs are very, very hard to understand, and very permissive because they aim at "performance"
<ZombieChicken>Considering the difference in funding and difference in age between ARM and x86, I'm not suprised x86 is faster
<OriansJ>braunr: The reason Intel has top performance is simple Marginal_R/D * Unit_Volume
<braunr>and the industry demand is so high that low quality just does the job
<braunr>OriansJ: what do you mean ?
<braunr>ZombieChicken: i'm surprised that it *can* be faster
<ZombieChicken>braunr: "low quality just does the job" unless it doesn't, in this case...
<braunr>yes, but we're not there yet
<OriansJ>braunr: 1M chips * $50 of research per chip equals $50M on design.
<ZombieChicken>What you described sounds like a compiler issue as much as a developer problem
<braunr>all my years have been filled by "what the fuck" moments where a torvlads-like manager would have fired everyone
<braunr>OriansJ: money alone doesn't make everything possible
<ZombieChicken>"Torvalds-like manager"? Is that some kind of antiPHB?
<braunr>phb ?
<ZombieChicken>Pointed haired Boss, ala Dilbert
<braunr>no i mean someone who says "shit" every three sentences and is extremely demanding
<ZombieChicken>I've just never heard of "Torvalds-like manager" before
<braunr>oh i see :)
<braunr>well he is one :)
<OriansJ>braunr: right but it generally pays for very smart people to do lots of hard work to create something the market place wants
<ZombieChicken>Yeah. I was assuming such a manager would swear constantly
<braunr>it's easy to see how he handles management, even if it got a little better recently
<braunr>OriansJ: yes, that's the real metric
<ZombieChicken>From what I've seen, Torvald's management skills are similar to a pack of hyenas. Screw up and they eat you alive
<braunr>some people argue that the c spec is too permissive
<braunr>but it's generally agreed that c is meant for system programming
<OriansJ>braunr: Intel flat out spends more money than any other Company on the planet for CPU Design.
<ZombieChicken>C really needs to die in a fire
<braunr>for c++, i'm not sure what the general idea is
<braunr>ZombieChicken: no you need to die in a fire :p
<braunr>to rid yourself of your sins :P
<braunr>including what you just said hehe
<braunr>why don't you like c ?
<ZombieChicken>When I need to reimplement half the standard library to get something secure, there is a problem
<braunr>that's not c
<braunr>that's people
<braunr>c is secure
<braunr>but as with any language, you gotta do things right
<OriansJ>ZombieChicken: braunr: C is just a winner because of its relationship to Unix.
<braunr>in particular, when the language gives you sizeof, you gotta use it
<braunr>i strongly disagree
<braunr>c is a winner because it's a thin layer above the processor
<ZombieChicken>braunr: The problem with C is that there are so, so many ways to do things wrong
<braunr>which means there are only a few ways to do things right
<ZombieChicken>and worse, subtly wrong
<braunr>which should be easy to teach
<braunr>i would use your argument against c++ and other "multi-paradigm" languages
<braunr>c closely matches what the hardware can do
<OriansJ>braunr: There are other thin layers that do a better job like Fortran, PL/m, Oberon, etc
<ZombieChicken>As you said before "low quality does the job"
<braunr>if you don't like c, you don't like the hardware
<braunr>ZombieChicken: which is why people are moving to java and c#
<braunr>OriansJ: no they're not
<braunr>they're not thin layers
<OriansJ>braunr: Have you used them?
<braunr>enough to know that
<ZombieChicken>Isn't PL/M an old IBM language from the 60's?
<braunr>maybe they are now
<braunr>i know fortran evolved a lot since 77
<braunr>but i didn't bother with the new stuff
<braunr>i'd suggest ada over it any time
<braunr>but even then, c really wins
<ZombieChicken>or Lisp Machine Lisp...
<braunr>maybe, but i'm not sure about the hardware of such a lisp machine
<braunr>anyway, we're drifting
<ZombieChicken>FINALLY! Copying a 15Gb of data over USB2 is painful
<braunr>oh :)
<ZombieChicken>Came to the realization that my desktop is utterly broken this morning
<ZombieChicken>so I'm having to look at reinstalling it ASAP
<OriansJ>braunr: PL/M was always much better for writing low level software. Lisp was better for high level and dozens of others have better fits all over the place but C was the one which was made by Unix.
<ZombieChicken>Never a good sign when I run a command and it fails, then rerun it instantly afterwards and it works fine
<braunr>OriansJ: i don't know pl/m enough to agree on that
<ZombieChicken>braunr: Lisp Machine Lisp was basically JIT compiled iirc.
<braunr>but i don't see how you could write a better glue than c honestly
<ZombieChicken>Update the standard library to offer secure options, implement a reasonable garbage collector...
<OriansJ>braunr: that is because Unix made it the Glue
<slyfox>or at least strings? :)
<ZombieChicken>Maybe an OO layer if one is so inclined
<braunr>ZombieChicken: you don't want "security" to stand in the way
<braunr>same for garbage collection
<braunr>OriansJ: notwithstanding that, show me what would make a better glue
<braunr>slyfox: the hardware doesn't know what a "string" is
<braunr>actually x86 does, but x86 strings are just vectors
<ZombieChicken>braunr: Fairly sure some past hardware did
<slyfox>c is quite far from nowaday's hardware
<braunr>ZombieChicken: did what ?
<braunr>slyfox: ??
<ZombieChicken>Understand strings
<braunr>ZombieChicken: but c-style strings
<braunr>i think slyfox wants true strings
<OriansJ>braunr: Not withstanding x86 has string support.
<braunr>18:07 < braunr> actually x86 does, but x86 strings are just vectors
<braunr>look guys
<braunr>i've started a flame war
<braunr>and i'm sorry for that
<braunr>my final point was simply
<ZombieChicken>I seem to recall some arch from Way Back When that could read a plaintext file and execute it. It never went anywhere because it was SLOW, but still
<OriansJ>I honestly enjoy the exploration.
<braunr>x86 is like java/c#, it makes mistakes less likely
<ZombieChicken>I don't see this as a flamewar
<braunr>but unlike java and c#, it's the fastest thing around
<ZombieChicken>"Portable Assembly"
<OriansJ>braunr: Hand tuned assembly always wins
<braunr>no it doesn't
<ZombieChicken>Depends on the skill of the tuner, I'd imagine
<braunr>more on his time
<braunr>for most cases he could die before finishing
<braunr>or the universe :p
<ZombieChicken>If it's a complex enough program, yes
<braunr>even simple ones
<braunr>compilers are amazingly good nowadays
<braunr>well, gcc/clang
<braunr>and the intel icc too
<ZombieChicken>intel icc when using an intel chip
<OriansJ>braunr: Take the best assembly made by the best C compiler, it can be hand tuned by knowledge that the compiler can't have.
<braunr>OriansJ: but you can give the compiler than knowledge
<ZombieChicken>I would like to point out that JIT can outrun precompiled in some cases
<braunr>you know, -mtune= .. :)
<ZombieChicken>braunr: -march. -mtune is more generalized
<braunr>march is about the isa
<braunr>mtune is about the specific target
<slyfox>C (or a platform it runs on) has it's own random semantics that hinder optimisations
<braunr>1/ they're not random
<braunr>2/ they're specifically aimed at performanced
<OriansJ>braunr: not always, lithographic imperfections is a great example
<braunr>which is why c code can get so buggy
<slyfox>-fsemantic-interposition is a recent addition to gcc
<braunr>OriansJ: that would be specific to single processor right ?
<OriansJ>braunr: that is where hand tuning makes sense.
<ZombieChicken>AFK. gotta test this LiveUSB out and see if the noveua driver actually works for this system
<braunr>and when does a single processor make sense ?
<braunr>slyfox: taht's about runtime linking right ?
<slyfox>this flag changes code generation
<slyfox>it removes an indirection during function call to disable symbol interlosition with LD_PRELOAD or similar
<OriansJ>braunr: Knowing the number of execution units is another example used in super computers all the time.
<braunr>OriansJ: ok that's one case, i would still rather teach the compiler
<braunr>slyfox: so that it doesn't need to expose some symbols ?
<slyfox>so it could (say) inline "local" functions
<braunr>yes i see
<braunr>that's not a good example imo
<slyfox>something that JITs do routinely
<braunr>not in the current discussion
<braunr>you're talking about an option here
<OriansJ>braunr: VLIW has a very similar problem and ultimately no one has figured out how to implement that correctly.
<slyfox>you said C is a thin layer on top of hardware
<slyfox>i said it's not :)
<braunr>how is it not ?
<braunr>i don't see the point of your example
<braunr>OriansJ: ok that's another
<slyfox>when you call a function you don't see amount of indirections runtime has to go through
<braunr>you actually do
<braunr>you have that kind of control
<braunr>the very existence of the option proves it
<slyfox>it's not C, but a random compiler's flag
<braunr>ok, then it's not c
<OriansJ>braunr: When optimal performance is required, hand tuned assembly custom to the hardware being used is the only option.
<braunr>then why use something that is not about c, as an argument against c ?
<braunr>OriansJ: no it's not
<braunr>OriansJ: it may be in some cases
<braunr>OriansJ: for current processors, it usually isn't
<braunr>you gave a few very specific example
<slyfox>it's an example where C does not provide enough control over things that happen in hardware
<braunr>i could give you the code your machine is running right now as a counter example
<braunr>slyfox: i have no idea what you mean
<ZC-wuz-hur>well, it boots
<ZC-wuz-hur>and glxgears works
<braunr>welcome back
<slyfox>ok, i'll shup up then :)
<braunr>slyfox: :(
<ZC-wuz-hur>now to find a 3D game to try out...
<OriansJ>braunr: Most of the time, no one cares about a 5to 7% performance difference but when it matters, asm is usually embedded in C.
<braunr>again i have to disagree
<braunr>and i'll use linux as an example, where 1-2% performance increases are regularly measured for some patch series
<CharlieBrown>Can GuixSD be installed on a 16 GB flash drive?
<braunr>and the patch usually consist entirely of c code
<ZC-wuz-hur>CharlieBrown: I'm running from a 15G drive atm
<OriansJ>braunr: Linux has a shitload of hand tuned assembly
<ZC-wuz-hur>CharlieBrown: and I'm only using 3.1GB
<braunr>OriansJ: which is a shame
<ZC-wuz-hur>How much of that assembly is simply legacy code?
<braunr>much of it is historical, or target-specific
<OriansJ>braunr: NO, it is what helped Linux Win performance
<braunr>i don't know, it's too big for me
<braunr>OriansJ: no it's not
<braunr>absolutely not
<CharlieBrown>ZC-wuz-hur: Cool. I have three 16 GB flash drives: one for data, one for ISOs, one for an installed play system.
<braunr>the performance-critical assembly is .e.g. memory barrier code, which is target-specific
<braunr>sting/bit functions, again, target-specific
<ZC-wuz-hur>CharlieBrown: What I did was run dd and copy the drive image to my hard drive, use qemu to install to the resulting .img, then dded it back onto the flashdrive
<braunr>and the rest is of course system management instructions, not the role of the compiler
<braunr>what helped linux win performance is its dcache
<OriansJ>braunr: target-specific is where performance is critical
<braunr>or rcu and its lockless page cache
<braunr>OriansJ: no you don't understand
<braunr>i mean that the compiler couldn't do it
<ZC-wuz-hur>Hasn't linux almost always outperformed Windows?
<braunr>with c11 atomics, it could
<braunr>yes but not bsd
<ZC-wuz-hur>Fairly sure Linus won't use anything other than ANSI C
<braunr>he uses gnu c a lot actually ..
<OriansJ>braunr: correct
<ZC-wuz-hur>Well, some GNU extentions, yeah. Only way to get assembly in the resulting binary
<braunr>and some of his swearing is about standard c not having some gnu extensions
<braunr>ZC-wuz-hur: ?
<braunr>powerful inline assembly, yes
<braunr>otherwise no
<ZC-wuz-hur>braunr: Unless I'm mistaken, ANSI C has no way to embed assembly in it for those "performance-critical" internal loops and whatnot
<braunr>no it doesn't
<OriansJ>braunr: llvm had to add GNU extensions to support linux
<CharlieBrown>ZC-wuz-hur: I can't VM.
<braunr>lots of compilers support many gnu extensions
<braunr>they just make sense
<braunr>c11 made it slightly better though
<ZC-wuz-hur>CharlieBrown: Well, it's what I did. Do what works for you. I was just making a suggestion
<braunr>so, i have to go :p
<ZC-wuz-hur>l8er. It's been fun
<braunr>i'll just say that, in order to really beat c, you need ..
<braunr>artificial intelligence
<braunr>and that's it !
<braunr>bye !
<OriansJ>braunr: Ha, have fun
<ZC-wuz-hur>Nothing shows how dirty a monitor is like a BRIGHT WHITE terminal...
<ZC-wuz-hur>Every spec of dust is just magnified...
<ZC-wuz-hur>Oh wow. I just installed extremetuxracer, and the symlink isn't in .guix-profile/bin/ ...
<ZC-wuz-hur>Ah, found it
<ZC-wuz-hur>apparently it's named "etr", not "extremetuxracer"
<ZC-wuz-hur>Anyone have any suggestions for a good program to test 3D performance?
<xkapastel>does guix have tumiki-fighters ?
<xkapastel>that's a simple 3d game that'll let you know if your stuff is working
<xkapastel>not very taxing though
<OriansJ>xkapastel: warzone2100
<ZC-wuz-hur>I need something taxing
<ZC-wuz-hur>glxgears worked fine, and extremetuxracer worked
<OriansJ>ZC-wuz-hur: just turn up warzone2100's settings
<ZC-wuz-hur>I'm installing minetest, chromium-bsu, and warzone2100 atm
<ZC-wuz-hur>If this works, I just need to figure out RAID and LUKS and I should be set
<ZC-wuz-hur>and hopefully everything else I want to run with play nicely
<CharlieBrown>I'm trying to put GuixSD on a multiboot ISO but the installer image is not an ISO and IDK how to extract it and look at the grub.cfg.
<ZombieChicken>yay. apparently the open-source nVidia driver won't work for me
<reepca>Regarding the build tool in the GSoC suggestions, it says "... should ultimately be able to run complex workflows on multiple servers..." - what exactly does that mean? That the build process should be able to be distributed across systems?
<lfam>reepca: You might have better luck starting the discussion on the mailing list; the Guix developers interested in that project may not be on IRC right now
<marusich>CharlieBrown, if you want to examine the grub.cfg which got generated for the installation image (which, as you correctly pointed out, is not an ISO-9669 file system image), one way you can do that is to mount the image as a loopback device, and then examine its file system like any other.
<marusich>I think the incantation goes like this:
<marusich>sudo losetup -P /dev/loop0 disk.img
<marusich>sudo mount /dev/loop0p1 /mnt
<marusich>Where, of course, the exact device and directory to use in your mount invocation depends on what actually exists.
<marusich>Refer to 'man losetup' for details.
<marusich>If you plan on using GuixSD in a multi-boot situation, you should be aware that changes which update the grub.cfg file might blow away any customizations you have made to accommodate the multi-boot setup.
<marusich>(i.e., 'guix system reconfigure' and the like)
<roelj>It seems that when I try to compile Guix with Guile 2.2, it cannot find the gnutls guile module.. Is this a known problem?
<janneke>roelj: yes you need to install guile2.2-gnutls (or gnutls/guile-2.2)
<kadintrooper>If I wanted to symlink python3 to python how would I go about that
<lfam>kadintrooper: If you are asking about doing that within the context of Guix packaging, use the package python-wrapper
<kadintrooper>Thank you L)
<lfam>Or python-minimal-wrapper; it depends on what you need
***jonsger1 is now known as jonsger