User: Password:
|
|
Subscribe / Log in / New account

Recently posted comments

Adding strlcpy() to glibc

Posted Jul 21, 2017 0:41 UTC (Fri) by kmeyer (subscriber, #50720)
In reply to: Adding strlcpy() to glibc by JIghtuse
Parent article: Adding strlcpy() to glibc

It's a shame it is 2017 and the function still hasn't made it in. Just to reduce code duplication and improve portability from the BSDs, if not for any other reason.


Network acceleration with DPDK

Posted Jul 20, 2017 23:20 UTC (Thu) by unixbhaskar (subscriber, #44758)
Parent article: Network acceleration with DPDK

Cool ! Thanks Rami for the detailed info...interesting.


Security quotes of the week

Posted Jul 20, 2017 23:12 UTC (Thu) by magnus (subscriber, #34778)
Parent article: Security quotes of the week

Would it count as a fleet-wide hack, if all Teslas would start to play Fleetwood Mac?


I'll Do It

Posted Jul 20, 2017 22:57 UTC (Thu) by ewen (subscriber, #4772)
In reply to: I'll Do It by linuxrocks123
Parent article: Ideas versus implementation

That was my impression too -- using named tuples instead of tuples seems conceptually simple to implement given a bit of C/Python knowledge and some time. At a guess finding the locations to change, writing the tests and going through the submission process would take more time than the actual code changes.

It seems like a good idea to me too, and the sort of thing I could also put on my (long) todo list. Possibly there are enough of us with some C/Python knowledge, some interest, and some small bits of time to JDI (Just Do It) that pooled together it can actually get done?

Ewen


Ideas versus implementation

Posted Jul 20, 2017 22:24 UTC (Thu) by karkhaz (subscriber, #99844)
In reply to: Ideas versus implementation by farnz
Parent article: Ideas versus implementation

You're right, it's a hard problem. The only solution I can think of is vaguely creepy: each installation of Krita records how many times it has been run (or for how many hours it has been run in total), and people who are heavy users of Krita (after 1,000 hours of use) get a dialogue box with a unique code that can be "redeemed" for a feature-vote :)


Emacs and Magit

Posted Jul 20, 2017 21:46 UTC (Thu) by jreybert (guest, #117717)
In reply to: Emacs and Magit by walkerlala
Parent article: Emacs and Magit

Actually, there is! It is called vimagit

For the moment, it is mainly focused on the stage/commit feature, with a lot of actions possible (e.g. stage by file/hunk/line/word). And it is very stable.

It does not as much as magit because:

  • fugitive does an awesome job for Gblame, Gdiff, Gread...
  • There are features like interactive rebase, push, stash (by file/hunk/line/word) I'd like to add, when I can find some time :)

  • User space

    Posted Jul 20, 2017 21:06 UTC (Thu) by corbet (editor, #1)
    In reply to: The ORCs are coming by Sesse
    Parent article: The ORCs are coming

    That's a question that came up in the conversation; I didn't manage to work it into the article, sorry. There is definitely interest in doing that, and it seems possible, but nobody is working on it at the moment.


    The ORCs are coming

    Posted Jul 20, 2017 20:58 UTC (Thu) by Sesse (subscriber, #53779)
    In reply to: The ORCs are coming by corbet
    Parent article: The ORCs are coming

    A related question; will this eventually seep down into userspace, so that we can get reliable perf backtraces without frame pointers? (Yes, there's --call-graph=dwarf, but it requires dumping the entire stack to the perf trace, since DWARF is too slow to trace in realtime. So it makes for slow, huge traces.)


    Safety issues vs. incompetent programmers

    Posted Jul 20, 2017 20:52 UTC (Thu) by smurf (subscriber, #17840)
    Parent article: Development quotes of the week

    > Robert O'Callahan

    This assertion routinely happens in PHP space, by people who are otherwise good enough programmers that they should know better.


    Ideas versus implementation

    Posted Jul 20, 2017 20:51 UTC (Thu) by farnz (subscriber, #17727)
    In reply to: Ideas versus implementation by karkhaz
    Parent article: Ideas versus implementation

    The complexity all comes in if you want to serve your users well (which boudewijn & co seem to, as doing so has led to Krita's success). For me €10 towards a feature I'd like is not a sacrifice, €100 might need discussion with my family, while €1,000 or more would need some form of return on investment to allow me to justify the spend. Further, I'm already a C++ developer, and I've some experience of Qt; thus, for simple features, I can do it myself in a reasonable amount of time, and complex features are "just" a matter of me wanting to put enough time in.

    In contrast, an up-and-coming artist might have to decide to skip a meal or three to save up €10 for a feature; more than that involves skipping more meals. They don't have the programming skills (and developing good enough skills to be a useful Krita contributor would take away from developing their art skills that they're passionate about), so they can't easily put in the time and effort that way. Yet, because (unlike me), they're trying to make their living from their art skills, their insight into what would make Krita more productive is a lot more valuable than mine.

    Hence this being a hard problem - how do you ensure that the high value contributions from people without much money (yet) are rated above those of rich dilettantes?


    The ORCs are coming

    Posted Jul 20, 2017 19:57 UTC (Thu) by corbet (editor, #1)
    In reply to: The ORCs are coming by jhoblitt
    Parent article: The ORCs are coming

    ORC will track neither of those things; it just provides the information needed to make sense of the kernel stack. The kallsyms mechanism can associate symbols with addresses, as always.


    User=0day considered harmful in systemd

    Posted Jul 20, 2017 19:54 UTC (Thu) by flussence (subscriber, #85566)
    In reply to: User=0day considered harmful in systemd by welinder
    Parent article: User=0day considered harmful in systemd

    Soon we'll be rid of the /etc/passwd menace and replace it with systemd's much better documented and modern DBus+XML API!

    Just kidding. You meant TCB, didn't you?


    The ORCs are coming

    Posted Jul 20, 2017 19:53 UTC (Thu) by jhoblitt (subscriber, #77733)
    Parent article: The ORCs are coming

    I haven't tried to grok the pathset... Will ORC track file/lineno or just symbol name?


    32-Bit x86 support in Fedora

    Posted Jul 20, 2017 19:25 UTC (Thu) by smoogen (subscriber, #97)
    In reply to: 32-Bit x86 support in Fedora by chder
    Parent article: 32-Bit x86 support in Fedora

    The default download is 64 bit with lines on the right for 32 bit downloads. The reason is that i386 downloads have been dropping in requests with ~95% of the users for F25 using x86_64.


    Why not involve the boot loader

    Posted Jul 20, 2017 19:05 UTC (Thu) by flussence (subscriber, #85566)
    In reply to: Why not involve the boot loader by nix
    Parent article: Waiting for entropy

    >This does then mean that the kernel has to get randomness somehow, but surely *it* is better able to get some randomness from somewhere on the disk than the bootloader? It already has tested, working filesystem access code, after all.
    There's another alternative: store and load the entropy seed via pstore. Works on EFI, KVM and a few other platforms, no block device necessary. (and with the recent addition of in-kernel TLS, that opens the door to horrible ideas like netboot over HTTPS)


    Security quotes of the week

    Posted Jul 20, 2017 18:57 UTC (Thu) by SiB (subscriber, #4048)
    In reply to: Security quotes of the week by rriggs
    Parent article: Security quotes of the week

    The value of the speed of light carries no physics at all, like all other physical constants that require units. The universe does not care about the value. The speed of light is defined by law, not by physics already. The value of these physical constants only give meaning to the units attached to the value. Real physical constants have no units, and those define the behaviour of the universe.


    Ideas versus implementation

    Posted Jul 20, 2017 18:10 UTC (Thu) by flussence (subscriber, #85566)
    In reply to: Ideas versus implementation by niner
    Parent article: Ideas versus implementation

    I plead guilty :-)

    I was one of a few people who regularly griped that, for all of Perl 6's amazing Unicode support, it barely did anything interesting with it. I tried making a half-baked external module for things like the latin-1 arithmetic and unicode set operators many years ago that didn't work too well (there weren't even Set types back then!)
    Today all that stuff is built in and super-polished. My favourite is actually the smart quote pairs: they were only added because someone's IRC client kept mangling them, but they also make shell one-liners a million times less painful than other languages which suffer from leaning toothpick syndrome, and the parser errors are more helpful too.


    32bit have a couple of advantages for VMs

    Posted Jul 20, 2017 17:21 UTC (Thu) by excors (subscriber, #95769)
    In reply to: 32bit have a couple of advantages for VMs by epa
    Parent article: 32-Bit x86 support in Fedora

    I suspect a kernel-based emulator would be around three orders of magnitude slower than hardware - e.g. an SSE2 instruction can perform 16 8-bit additions in a third of a clock cycle (on modern CPUs), or 4 float additions in half a cycle, whereas trapping into the kernel and performing all those operations serially and saving the results in an emulated register file in memory is going to take forever. Even a non-performance-intensive application that only spends 10% of its time dealing with floats could run 100x slower with emulation.

    For users, an application running 100x slower may be nearly as unusable as an application crashing with an "instruction not supported" error, and is much harder for the application's developer to debug from a bug report. In both cases the developer would probably just switch their compiler flags from SSE2 to x87 once they recognise the problem.

    Applications that do lots of number crunching and want to support a wide range of users will already provide both x87 and SSE2 code paths, and select one based on CPU capabilities, so the emulation won't improve compatibility there (and might confuse the capability detection code).

    The only case where emulation would really help is code that uses a non-zero but tiny amount of SSE2, so it would improve compatibility and nobody would care about the performance cost, and that doesn't sound common enough to justify a substantial effort.

    There is an Intel Software Development Emulator <https://software.intel.com/en-us/articles/intel-software-...> that emulates recent SIMD instructions etc, but that's for developers to test them before hardware support is available, it's not intended for users. (It seems to do a sort of JIT translation that can replace certain instructions with calls into the emulator, which is much faster than reacting to illegal instruction exceptions.)


    Ideas versus implementation

    Posted Jul 20, 2017 16:21 UTC (Thu) by niner (subscriber, #26151)
    In reply to: Ideas versus implementation by hkario
    Parent article: Ideas versus implementation

    Given that Python has a 24 years head start, I'd say that it's a bit early to draw conclusions based on usage :)


    Ideas versus implementation

    Posted Jul 20, 2017 16:18 UTC (Thu) by hkario (subscriber, #94864)
    In reply to: Ideas versus implementation by niner
    Parent article: Ideas versus implementation

    Given that vastly more people use Python and look for Python programmers, I'd say that the Python approach won. However unintuitive that sounds like.



    Copyright © 2017, Eklektix, Inc.
    Comments and public postings are copyrighted by their creators.
    Linux is a registered trademark of Linus Torvalds