coreboot March 2017

coreboot@coreboot.org

79 participants
267 discussions

Re: [coreboot] How come the community meeting is hosted by proprietary software?
by Martin Roth 18 Mar '17

18 Mar '17

Additionally, the meeting software needs to work well for everyone, pretty much anywhere in the world. The coreboot community is an amazingly diverse group. So the meeting method needs to have a way to work well in pretty much any OS you can think of, or there needs to be an alternate method of connection - like a telephone bridge. However, as I said in my last email, I'm not interested in changing again right now. We just went through an extensive evaluation process roughly 5 months ago, and we picked bluejeans. If someone wants to help us evaluate tools again in November, that would be the time. Until then, let's stick with bluejeans for the community meeting. Let's stop second guessing our decisions every few months. Since it seems like people missed my last post about this, here's the link: https://www.coreboot.org/pipermail/coreboot/2017-March/083582.html Martin On Sat, Mar 18, 2017 at 2:02 PM, ron minnich <rminnich(a)gmail.com> wrote: > Nobody is stopping anyone from implementing and letting us try something > open. I think it's great. I would love to be able to use it. > > But some rules apply: > > o a lot of us have full time jobs and (in my case at least) a skill set that > does not include competence/interest in hacking on meeting software. It has > to work for me as EASILY as what we are using today. > > o it has to work at least as WELL as what we're using today. So far, every > single open source alternative has not come close to meeting that standard. > > o And, to reiterate, no single points of failure. It seems to me that > anything that depends on one person providing 24x7 availability has a > single point of failure by definition. And, in at least one case, we went to > have a meeting and the (non-redundant) person running the (non-redundant) > server connected to the (non-redundant) network was not around. No meeting > occurred. That's a failure. > > > > > -- > coreboot mailing list: coreboot(a)coreboot.org > https://www.coreboot.org/mailman/listinfo/coreboot

1 0

Re: [coreboot] How come the community meeting is hosted by proprietary software?
by Peter Stuge 18 Mar '17

18 Mar '17

Stefan Reinauer wrote: > > > > I never tried the web interface. > > > > > > We did, it failed us. > > > > What problems did people have with mumble-web, and where was the > > websockets server running, relative to the mumble server? > > It was actually your mumble server. I didn't have mumble-web. I asked about the web interface, which has failed us at some point, as Patrick wrote. > We used it for one or two meetings, and the sound was choppy and it > was basically impossible to have a conversation. I knew that my mumble server was used, but this feedback only reaches me now. Thanks for letting me know! Ron once said something completely different; that he couldn't run the (native) client software on his ChromeOS system. That made me interested in getting feedback from mumble-web. Since I use the server for various meetings with great success I'm interested in investigating what caused the issues for us in coreboot. If anyone can remember having problems and would like to do some testing with me at some point then please get in touch off-list. Thanks! tturne(a)codeaurora.org wrote: > Just because I work with OSS doesn't automatically make me a zealot > for OSS as the only way to go. Of course not; it's just the best way to go. > think of the contribution to Coreboot source code this energy could > generate instead of spending it on fixing a problem that doesn't > need fixing? I think it's an important problem. I agree with Stefan that it's not a problem for the coreboot community, but I want to not lose our user experience. ron minnich wrote: > Unfortunately, the free software meeting systems have not worked out. Suboptimal solutions need to be re-evaluated, once every few years seems easy. > It can't depend on one person managing the server, or the connection, > or the setup. I think a one person argument is silly, but I agree with the general argument about avoiding single points of failure. > portability in the Linux world seems to mean "works on Ubuntu AND Arch". Daring extrapolation. Sorry that you've had such bad experience. > We have to see it work everywhere. A big part of which is to be active. It makes no sense to push a burden of demonstration for "every possible client" to a single point; that's setting up for failure and sending the message that nothing should improve. > There's also an issue with the premise: .. > What does it really mean To keep trying. //Peter

2 1

Conventions for describing flash memory layouts
by Sam Kuper 18 Mar '17

18 Mar '17

The page https://www.coreboot.org/index.php?title=Board:lenovo/x201&oldid=24709#Flas… says: > The flash memory in the X201 is divided into roughly 4 parts: > > - Descriptor (12K) > - ME firmware (5M-12K) > - Rewriteable flash (3M-96K) > - Locked bootblock (96K) I guess that "K" refers to kibibytes and that "M" refers to mebibytes. I also guess that the values in parentheses refer to the sizes of the corresponding occupants of the flash memory, with the "-" symbol representing "minus". This was not my first guess, but is the one that seems to make the most sense. Are my guesses correct? If not, what do the values in parentheses mean? Thanks!

1 0

Re: [coreboot] coreboot community meeting minutes for March 16th, 2017
by Peter Stuge 18 Mar '17

18 Mar '17

Thanks for sending out minutes! Martin Roth wrote: > * How do we feel about changing the coding style to move constants in > comparisons to the left side? if (0 == x) instead of (x == 0) > - The argument for doing this was that this style finds errors in any environment > - Ron is very opposed. Oh Ron, don't be so lazy. ;) It's a fantastic way to avoid errors. I have adopted this style and it's one of those rare things which is annoying for maybe a week, but goes on to benefit both you and everyone else forever after. I encourage everyone to adopt it. You know, try it out for a week on personal projects; challenge yourself to get used to it. Hope you're having a good weekend! //Peter

2 1

Re: [coreboot] RYZen single APU design
by Taiidan＠gmx.com 18 Mar '17

18 Mar '17

On 03/16/2017 06:05 AM, qma ster wrote: > As far as I know, AMD does not have any "evil brother" of Intel ME. It only > has AMD PSP (Platform Secure Processor) that is built-in to CPU. So, I > don't think that cutting a PCH from AMD CPU has any practical value: even > if the platform will boot after such a radical change to computer's > hardware, you'll lose a lot of essential stuff like USB ports "only has" huh? PSP and ME do literally the same thing and have the same capabilities, they're a like for like with implementation details being the only difference.

2 1

Re: [coreboot] How come the community meeting is hosted by proprietary software?
by Peter Stuge 18 Mar '17

18 Mar '17

Patrick Georgi via coreboot wrote: > 2017-03-17 13:17 GMT+01:00 Dumitru Ursu <dima(a)ceata.org>: > > I never tried the web interface. > > We did, it failed us. I wish someone would have mentioned that sooner. What problems did people have with mumble-web, and where was the websockets server running, relative to the mumble server? //Peter

7 7

Re: [coreboot] GNU11 and C11
by Paul Menzel 17 Mar '17

17 Mar '17

Dear Ron, Am Freitag, den 17.03.2017, 22:51 +0000 schrieb ron minnich: > On Fri, Mar 17, 2017 at 3:32 PM Paul Menzel wrote: > > > I think there is > > no objection to move to C11, if somebody rewrites the code using GNU11 > > extensions. > > Paul, the discussion I read made it clear that there were lots of > objections to moving away from GNU11 extensions, viz. > > > There are many GNU extensions > > which are simply necessary to write sane, readable and performant code > > (e.g. to implement non-double-evaluating MIN()/MAX() macros, to > > cleanly control linking into particular sections, to get performant > > code generated for IO accessor functions, etc.). The C standard by > > itself is simply insufficient to support all systems programming use > > cases, and if we forbade GNU extensions we'd have to rewrite > > significant parts of coreboot in pure assembly and add weird, hardly > > readable workarounds for many code patterns. " > > Now, I don't actually agree with all this, but the decision was made to go > with GNU11, not C11. You quoted Julius’ reply [1]. Later he also replied [2]. > Yes, just to be clear (this has split into so many different threads > that I'm no longer sure what the latest decision is?), I only > (prematurely) objected to forbidding GNU extensions. Otherwise, I'm > totally in favor of switching to C11 and not aware of any difference > between the versions that would cause a problem for us. So I still believe, that the “move away from GNU11 discussion” didn’t come to a conclusion, as that wasn’t the topic of the thread. So no decision was made. At least not announced publicly. Thanks, Paul [1] https://www.coreboot.org/pipermail/coreboot/2016-November/082576.html [2] https://www.coreboot.org/pipermail/coreboot/2016-December/082588.html

3 2

Re: [coreboot] How come the community meeting is hosted by proprietary software?
by Stefan Reinauer 17 Mar '17

17 Mar '17

* Patrick Georgi via coreboot <coreboot(a)coreboot.org> [170317 16:05]: > 2017-03-17 15:50 GMT+01:00 Juliana Rodrigues <juliana.orod(a)gmail.com>: > > that I know uses jitsi: https://meet.jit.si > > It's MIT, but works very well. > Thanks for the pointer. > > We already tried jitsi, but I think without the bridge service (which > only seems to exist for about a year). > So, something to re-evaluate, but the last time we tried "works very > well" was the opposite of our experience due to bandwidth > requirements. To shed some light on this, there are several types of issues we have encountered with this sort of software: - some software works really great for 1:1 video conferencing but does not scale when you are trying to have 15-20 people on a call. So unless you ran 20 people meetings successfully, "It works very well" might just cover a really different use case. - The software has to work on a variety of misconfigured (ahem) open source OSes and distributions, mainly by knowing about quirks of the various OSes / distributions and working around them. We have tried a number of solutions that ended up with half of the people not hearing the other half for various reasons. If you folks are interested in working on deploying these types of systems or fixing these sorts of issues, please, I advise you to join one of the open source projects that aims at creating video / audio conferencing software in the free software realm. These projects are in desperate need of great engineers to make them usable for cross planet conferencing on a larger (10-20ppl) scale. Do we want to solve these problems in the coreboot project, or on the coreboot mailing list? No. This project is all about booting computers. So as others here have mentioned, please save your (and everybody elses) time and energy for exactly that. > Patrick > (note to all so I don't have to sound like a grumpy, broken record: Is > it FOSS and reasonably popular? Then it's rather likely that we > already tried it) Or, as a dear friend of mine likes to say: This ain't our first rodeo :-) All the best, Stefan

1 0

GNU11 and C11 (was: coreboot community meeting minutes for March 16th, 2017)
by Paul Menzel 17 Mar '17

17 Mar '17

Dear Ron, Am Freitag, den 17.03.2017, 20:48 +0000 schrieb ron minnich: > On Fri, Mar 17, 2017 at 11:30 AM Nico Huber wrote: > > The decision was to make explicit what was already needed for a long > > time (already last time Clang was working). Don't worry about Clang, it > > can digest -std=gnu11 as well [1]. > > If that works for this project, then I guess that's ok. Harvey, on the > other hand, also intends to use the intel compiler (ICC). -std=gnu11 is not > an option we would ever use. Currently, coreboot *does* use these GNU extensions. So the code would not built, when disallowing the compiler to use them. I think there is no objection to move to C11, if somebody rewrites the code using GNU11 extensions. Thanks, Paul

2 1

Re: [coreboot] coreboot community meeting minutes for March 16th, 2017
by Nico Huber 17 Mar '17

17 Mar '17

On 17.03.2017 18:17, ron minnich wrote: > This one surprised me: > > "Get Clang going again - what do we need to do to get it going?" > > So, as of a few months ago, after long discussion, the decision as I > understood it was to make us GNU11, not C11. I went back and reviewed the > discussion, and that was how it seemed to come out. The decision was to make explicit what was already needed for a long time (already last time Clang was working). Don't worry about Clang, it can digest -std=gnu11 as well [1]. Nico [1] http://clang.llvm.org/docs/UsersManual.html#differences-between-various-sta…

2 1

← Newer
1
...
14
15
16
17
18
19
20
...
27
Older →

Jump to page:

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

2004

2003

2002

coreboot March 2017