Slashdot Mirror


User: jcdr

jcdr's activity in the archive.

Stories
0
Comments
905
First seen
Last seen
Profile
(view on slashdot.org)

Comments · 905

  1. Re:I used to do kernel dev.. on Linux Kernel Dev Sarah Sharp Quits, Citing 'Brutal' Communications Style · · Score: 1

    A quarter of century of uncontested leadership on a worldwide project could change the mind of almost everyone.

  2. Re:Can't Take the Heat........? on Linux Kernel Dev Sarah Sharp Quits, Citing 'Brutal' Communications Style · · Score: 2

    Most of the time when someone ask comment on an approach on a Open Source project he got no useful response. Later when he submit his patches he got brutal responses. It's the "let's the other do a mistake to show my power" scenario. It's only a hidden way to conserve leadership, even if it's unconscious.

  3. Re:Can't Take the Heat........? on Linux Kernel Dev Sarah Sharp Quits, Citing 'Brutal' Communications Style · · Score: 4, Insightful

    I agree.

    Shara himself wrote that the same people act nicely in person. It's the most interesting point: why someone can be nice with someone else in person and brutal with the same person on a open mailing list ? It inconsistent and probably a sign of immaturity.

  4. Re:Issue is more complicated on Linux Kernel Dev Sarah Sharp Quits, Citing 'Brutal' Communications Style · · Score: 1

    Exactly. And it's not only in a professional environment. There is a lot of situations in society and family that require to have some emotional control. Ironically most modern society have the biggest difficulties to pass the messages from a generation to next one. Maybe different humans need different experience without emotional control to understand why it's so important to have it. I used to think that's something we all learned while we was children. I now think I was wrong.

  5. Re:Issue is more complicated on Linux Kernel Dev Sarah Sharp Quits, Citing 'Brutal' Communications Style · · Score: 1

    I am sorry to say that Linus is completely wrong on this. He was always the uncontested leader of the project since almost a quarter of century, making her unable to understand the point of view of peoples not close to his position. I am as old as Linus, I also sitting in my home office (somethime) wearign a bathrobe. This don't allow me to expose any of my emotions to my professional contacts. Inability to communicate a disagreement without harsh words is immature and unprofessional. Linus has simply no one he respect enough to accept a limit on how he communicate. If I do the same, I will lost all my clients.

  6. Re:Issue is more complicated on Linux Kernel Dev Sarah Sharp Quits, Citing 'Brutal' Communications Style · · Score: 2, Insightful

    There is others places debating very technical question without using brutality, for example Stackoverflow.

  7. Re:Issue is more complicated on Linux Kernel Dev Sarah Sharp Quits, Citing 'Brutal' Communications Style · · Score: 1

    Shara doing shit code ? Have you some evidence ?

  8. Re:Issue is more complicated on Linux Kernel Dev Sarah Sharp Quits, Citing 'Brutal' Communications Style · · Score: 1

    +1000
    Some peoples need to travel a bit more outside touristic places to test there ability to communicate.

  9. Re:Issue is more complicated on Linux Kernel Dev Sarah Sharp Quits, Citing 'Brutal' Communications Style · · Score: 1

    How do you talk to your clients ?

  10. Re:Issue is more complicated on Linux Kernel Dev Sarah Sharp Quits, Citing 'Brutal' Communications Style · · Score: 1

    The problem is maintainers that don't understand that in a open community there is by definition all the possible perception. The only solution is to be professional and careful at the highest possible level with the others.

  11. Re:Issue is more complicated on Linux Kernel Dev Sarah Sharp Quits, Citing 'Brutal' Communications Style · · Score: 1

    Your post is a complete joke that serve your only ego. In a technical discussion there absolutely no valid reason to show your feeling.

  12. Too many maintainers don't care of the users on Linux Kernel Dev Sarah Sharp Quits, Citing 'Brutal' Communications Style · · Score: 0

    Time to time I try to fix bug in open source projects I use, including the Linux kernel. Compared to 15 years ago, it's now an extremely difficult task. Most of the time there is no reaction at all, even for critical bugs. When there is a reaction it's usually to deny the analysis and pretend that the problem is into an other layer (so an other maintainer) without giving any explanation. There is also the other method of perpetually demanding more and more information, and when all are there, the thread end without response. Sending patch is a nightmare, even if the code is signed-off by some, there is extremists that always complain on futile details in comments, asking to redact very long commit comment for a few very simple and obvious change in a few lines. And if after 3 to 4 weeks the patch go right, it is usually just ignored.

    Open Source is an effective model when used by maintainers that take care of the users. Today there is too many maintainers that are at this position payed by companies, making then acting for the company only. The fact that the project is open source is for this kind of maintainers just a opportunity to show there ego. There view contribution as a open contest between developers for there role. Real users that want to contribute only have basic knowledge and need support to make a patch, not to be destroyed for weeks in there voluntary effort trying to fix something.

  13. Aviation industrie do it incrementally on Philosophical Differences In Autonomous Car Tech · · Score: 1

    And require constant monitoring from human in charge.

  14. Re:Nature of open source on "Father Time" Gets Another Year At NTP From Linux Foundation · · Score: 1

    I was more thinking about something like the International Telecommunication Union allocating some financial support to the Linux Foundation core infrastructure initiative that already try to make a descent future for the NTP protocol.

  15. Re:not just NTP on "Father Time" Gets Another Year At NTP From Linux Foundation · · Score: 1

    In the case of NTP there is a even bigger problem: the definition of UTC is done by international organisations that have trouble finding a consensus.

  16. Re:Bus Factor on "Father Time" Gets Another Year At NTP From Linux Foundation · · Score: 1

    Hope this effort will continue.

  17. Re:Nature of open source on "Father Time" Gets Another Year At NTP From Linux Foundation · · Score: 1

    NTP is just a tool to disseminate UTC time. As today international relation so deeply rely on the UTC time, I believe that the best solution would be to find a international solution to finance the support of the tool. In this case, an open source solution will be critical to ensure that the project will not be sink under a Vogon style administrative layer.

  18. Re:Nature of open source on "Father Time" Gets Another Year At NTP From Linux Foundation · · Score: 1

    Precise time dissemination over a long period is a hard problem, unless you use TAI that NTP sadly do not provides...
    Fact is that humans use a local timezone defined and redefined by each governments on a (almost) spherical planet with a physically unpredictable rotation rate variation.

  19. Re:Nature of open source on "Father Time" Gets Another Year At NTP From Linux Foundation · · Score: 1

    Various operating systems NTP is designed for are evolving so it have to be modified to take advantage of new syscall, libraries, or API.

    The protocol itself must be urgently improved to include TAI, leap second table, and timezone database update, because in his current state any precise time computation crossing a possible leap second slot or a timezone change is unreliable for the past (and impossible for the future because of the unpredictable Earth rotation physics).

  20. Re:Simple on "Father Time" Gets Another Year At NTP From Linux Foundation · · Score: 2

    The very basic idea of the NTP protocol is to disseminate the time using a hierarchical layers of stratums: https://en.wikipedia.org/wiki/...

    So by design all nodes that are not a leaf need to be both client and server. This is common to all hierarchical protocols like for example DNS, and proved as an effective solution to reduce the bandwidth of the upper part of the hierarchy.

    If you have a better idea, please publish an RFC for an more effective protocol.

  21. Re:Too bad on Toshiba, SanDisk Piloting 3D NAND That Doubles Previous Capacity · · Score: 1

    Maybe, maybe not. Detailed specification of a xpoint 3d final component has still to exists, while the 3D NAND is the continuity of a well know technology. I am particularly curious at the temperature effect on the xpoint 3d cells, because others "innovative" memory that exists today are not very good in this area.

  22. Re:Not efficient on Reasons To Use Mono For Linux Development · · Score: 1

    1) We didn't know that Mono was the wrong tool for that job before doing the experiment.
    2) The install size is very large compared to almost anything you can actually install with a Debian Jessie main packages.
    3) The performance is way slower compared to Node.js.
    4) The memory footprint is a least twice the memory footprint of Node.js.

    Given the results, I doubt that Mono is the right tool for any new projects. It could maybe allow to run historical C# code on Linux that rely on some .NET infrastructure, but this outside of that purpose I don't see any advantage.

    Node.js has a clear and big advantage in term of installation size, processing performance and memory footprint. In addition Node.js has the sweet advantage to use the same Javascript language than on the browser client. Even if this is not simple to measure, this feature drastically reduce some kind of "brain footage" needed to deliver a project.

  23. Not efficient on Reasons To Use Mono For Linux Development · · Score: 4, Informative

    I work on a embedded Linux system running Debian Jessie armhf on a Cortex-A5 processor. At some point someone programmed a Web user interface for the system using Mono for Linux. The installation of Mono was difficult, requiring several hundred Mo of space on the filesystem and some trick to get the last package revision. Then the application was started and take all the processing load for almost 4 minutes. At his point it was eating near half the memory available on that embedded system. This was socking, especially for me that like to use qooxdoo for WebUI because it's basically a static file that need no compilation and have a very minimal memory footprint. Finally the guy switched to node.js for the WebUI on that system. The installation was easy, the startup compilation last now less than a single minute and the memory footprint is below 20%, all of that with a more complete demo that with Mono.

  24. Re:x86 on Xilinx and AMD: an Inevitable Match? · · Score: 1

    The agreement is fairly bidirectional and this was a big win for AMD, a kind of life insurance. Even if something go wrong with AMD, there still have the unique value of the cross license granted by the agreement. And given the massive market involved, there will be investors seeking for this kind of value. This is a open gate to a big market. No other open gate to this market exists at this moment.

  25. Re:Slow news day on Xilinx and AMD: an Inevitable Match? · · Score: 1

    Yes, and some insanely overpriced Itanium descendant chip to get some 64-bits capabilities with a completely incompatible instruction set.