[libre-riscv-dev] Introduction

[libre-riscv-dev] Introduction

[Anais Poirier]

Hello All,

My name is Anais, I'm a third year electrical and computer engineering
student at the University of Toronto, and I am Cole Poirier's sister! I'm
most interested in gaining knowledge and experience working on a hardware
project. I have limited experience with Assembly and Verilog as well as
extensive experience with c/c++ but I am excited to learn Nmigen and hope
to contribute to the Power Core. I am also the one who created the visual
slides for the pitch last week and would like to help with the Elm
Kanban/bug tracker visual front end for Bugzilla.

I have read and agreed to the charter.

Anais
_______________________________________________
libre-riscv-dev mailing list
libre-riscv-dev@lists.libre-riscv.org
http://lists.libre-riscv.org/mailman/listinfo/libre-riscv-dev

Re: [libre-riscv-dev] Introduction

[Yehowshua]

>  I have limited experience with Assembly and Verilog as well as
> extensive experience with c/c++ but I am excited to learn Nmigen and hope
> to contribute to the Power Core

Hello.

I’ll let Luke follow up a bit, but also do subscribe to the LibreSOC misc mailing list below[1].
Reason being is that I and others can help newcomers with more specific FPGA, RTL,
and nMigen concepts allowing us to keep the main dev mailing list lower traffic.

And as always, Welcome!

Yehowshua

[1]: http://lists.libre-soc.org/mailman/listinfo/libre-soc-misc
_______________________________________________
libre-riscv-dev mailing list
libre-riscv-dev@lists.libre-riscv.org
http://lists.libre-riscv.org/mailman/listinfo/libre-riscv-dev

Re: [libre-riscv-dev] Introduction

[Luke Kenneth Casson Leighton]

On Mon, Jun 15, 2020 at 9:13 PM Anais Poirier <anais.shiraz@gmail.com> wrote:
>
> Hello All,
>
> My name is Anais, I'm a third year electrical and computer engineering
> student at the University of Toronto, and I am Cole Poirier's sister!

hi, lovely to hear from you.  Cole mentioned you a couple days ago
when i had a monster 3 hour call with him and he took 10 pages of
notes, bless 'im.  that his head didn't explode or steam come out his
ears is a good sign.


> I'm most interested in gaining knowledge and experience working on a hardware
> project.

ya picked a Monster, you do realise that, right? :)

> I have limited experience with Assembly and Verilog as well as
> extensive experience with c/c++

oo, good.  this will come in real handy, there are 3D drivers to do,
we need a c/c++ simulator for SimpleV (on top of an existing POWERPC
simulator), there's linux kernel drivers and blah blah.


> but I am excited to learn Nmigen and hope
> to contribute to the Power Core.

excellent.  well Cole's been through the process already, we threw him
in the deep end and he hasn't sunk yet :)  i find it hilarious that he
knew nothing about gate-level design so we found (or wrote) some
tutorials and he went through them, came back and said, "ok now what?"
:)

i recommend reading this - it will give you some background and insights:
https://libre-soc.org/3d_gpu/tutorial/

you've done verilog, that's a really good start.  try this one, it's
very good - an introduction to nmigen:

    https://github.com/RobertBaruch/nmigen-tutorial

basically jump to the end of this page and go through them one by one
https://libre-soc.org/HDL_workflow/

once you've done *that*, then there are two *relatively* simple
pipelines that need work:
https://bugs.libre-soc.org/show_bug.cgi?id=348
https://bugs.libre-soc.org/show_bug.cgi?id=325

and - jacob's working on DIV, so hypothetically MUL is free:
https://bugs.libre-soc.org/show_bug.cgi?id=323


> I am also the one who created the visual
> slides for the pitch last week

niiice :)

> and would like to help with the Elm
> Kanban/bug tracker visual front end for Bugzilla.

this was just an idea which Cole and i sort-of went "hmm that would be
useful" and i'd honestly forgotten about - if you can raise a
bugreport about it on bugs.libre-soc.org under the "website" product
that would be really useful.  ask Cole for help, there.


> I have read and agreed to the charter.

excellent.

ok so you've probably patiently read this https://libre-soc.org/HDL_workflow/

and Cole either already has the dev-environment set up on his dev
machine: if you have your own machine _great_, do ask him to help you
get set up.  also if you dare be awake at 6am on Wednesday it would be
good to have you also on the Marketnext call, we will do some
introduction then and go over things that you should also be aware of.

great to have you on board.

warmest,

l.

_______________________________________________
libre-riscv-dev mailing list
libre-riscv-dev@lists.libre-riscv.org
http://lists.libre-riscv.org/mailman/listinfo/libre-riscv-dev

Re: [libre-riscv-dev] Introduction

[Yehowshua]

Also, I believe Cole had mentioned that you’re using a Mac?
If this is the case, use home-brew - it makes things notably easier.

The first thing I would do to get started is try 
 section 5.1 here: https://libre-soc.org

Yehowshua
_______________________________________________
libre-riscv-dev mailing list
libre-riscv-dev@lists.libre-riscv.org
http://lists.libre-riscv.org/mailman/listinfo/libre-riscv-dev

Re: [libre-riscv-dev] Introduction

[Luke Kenneth Casson Leighton]

On Mon, Jun 15, 2020 at 9:28 PM Yehowshua <yimmanuel3@gatech.edu> wrote:
>
> Also, I believe Cole had mentioned that you’re using a Mac?

ah.  right.  okay.  we're not supporting macs, and we're not going to
do development on macs.  there are two aspects to this:

1). when it comes to the ASIC layout, it is absolutely critical - and
is Industry Standard Practice - to have full reproducible builds.  not
even the username is different.  everyone doing the builds sets up
carbon-copy machines, where you could literally do a file-system
byte-level comparison and find absolutely everything is the same.

this is abbbsolutely essential when you are about to drop USD $5m on a
chip tape-out... oh but the last person who checked the build used
some totally different library and now "it doesn't work", finding the
discrepancy results in time lost, you miss the tape-out window
entirely, and the company loses a USD $100 million dollar deal because
of it.

so it's actually *really serious* not to be using the exact same
development workflow as everyone else.

2) applying this same underlying logic to the actual HDL development
is not an unreasonable step.

also we are a small team and do not need the hassle of "i have a Mac,
i can't get it to work, what do i do, what do i do" and because it's
not something that everyone has, and the problem turns out to be
something related to homebrew, or the native mac tools, we literally
*can't* help you... and at a crucial moment for a deadline *may not
have time*.

at that point you become a liability to the team, not an asset...
because you arbitrarily chose not to respect and follow Industry
Standard practices.


therefore - really - please do not use MacOSX for development.  the
lowest common denominator OS which everyone has access to is debian,
and we chose (specifically) debian 10 because its default version of
python is reasonably close enough to what nmigen requires.


you do not have to install debian 10 native: you can install homebrew,
followed by installing qemu, followed by installing debian 10 under
qemu and then using remote terminal login (using the Mac OS as a
"conduit"), or network loop-back filesystem so that you can use quotes
favourite quotes editors under the lovely nice pretty MacOS but
actually run the unit tests entirely under debian 10... *not* native
on the mac and *not* under homebrew.

however you will quickly find that this is really quite painful, slow
and inconvenient, particularly when it comes to setting up yet
*another* virtualisation - chroot within qemu - and that installing
ReFIT (or ReFIND) and actually dual-booting the mac will be much
easier.

OR

as you're in the same house, Cole has a development machine, which is
running debian native: ask him nicely and you can set up a 2nd login
on it.  whilst doing that, you can look at getting set up,
independently, and yet still be productive.

i actually use an 8-year-old Mac downstairs.  i ssh in to my laptop
upstairs, run 3 "screen" commands, one in each window, and thus if the
WIFI goes down i can get back to each of the three terminals, exactly
where they were disconnected.

hilariously i also installed an openssh client on my Samsung N9005 and
do the same trick: run "screen" and then if i am particularly tired or
if it is late, i do not have a bright LCD screen to stare at, just a
small hand-held one.

l.

_______________________________________________
libre-riscv-dev mailing list
libre-riscv-dev@lists.libre-riscv.org
http://lists.libre-riscv.org/mailman/listinfo/libre-riscv-dev

Re: [libre-riscv-dev] Introduction

[Cole Poirier]

On Jun 15 2020, at 1:49 pm, Luke Kenneth Casson Leighton <lkcl@lkcl.net> wrote:

> On Mon, Jun 15, 2020 at 9:28 PM Yehowshua <yimmanuel3@gatech.edu> wrote:
>>  
>> Also, I believe Cole had mentioned that you’re using a Mac?
>  
> ah.  right.  okay.  we're not supporting macs, and we're not going to
> do development on macs.  there are two aspects to this:
>  
> 1). when it comes to the ASIC layout, it is absolutely critical - and
> is Industry Standard Practice - to have full reproducible builds.  not
> even the username is different.  everyone doing the builds sets up
> carbon-copy machines, where you could literally do a file-system
> byte-level comparison and find absolutely everything is the same.

Don't worry Luke, I set up her development machine, running native
debian 10.3 on bare-metal, like mine, when I set up my own. She has a
mac that she will most likely do part of the Elm work on, but she's not
planning on using her mac for HDL work as I have already set up the
proper development on a dedicated desktop.

Cole

_______________________________________________
libre-riscv-dev mailing list
libre-riscv-dev@lists.libre-riscv.org
http://lists.libre-riscv.org/mailman/listinfo/libre-riscv-dev

Re: [libre-riscv-dev] Introduction

[Yehowshua]

> ah.  right.  okay.  we're not supporting macs, and we're not going to
> do development on macs.  there are two aspects to this:

Dang. I’ve been using a Mac this whole time.
Not really keen to switch unless I have to do Coriolis stuff.

Yehowshua
_______________________________________________
libre-riscv-dev mailing list
libre-riscv-dev@lists.libre-riscv.org
http://lists.libre-riscv.org/mailman/listinfo/libre-riscv-dev

Re: [libre-riscv-dev] Introduction

[Luke Kenneth Casson Leighton]

On Mon, Jun 15, 2020 at 9:55 PM Cole Poirier <colepoirier@gmail.com> wrote:

> Don't worry Luke, I set up her development machine, running native
> debian 10.3 on bare-metal, like mine, when I set up my own.

staaaar.  whew.

On Mon, Jun 15, 2020 at 9:58 PM Yehowshua <yimmanuel3@gatech.edu> wrote:
>
>
> > ah.  right.  okay.  we're not supporting macs, and we're not going to
> > do development on macs.  there are two aspects to this:
>
> Dang. I’ve been using a Mac this whole time.

it _is_ in the HDL workflow.

> Not really keen to switch unless I have to do Coriolis stuff.

i know - however think it through.  it's not the same software.  there
could be compilation-level bugs introduced by different compile-time
switches actually in /usr/bin/python, due to a different gcc compiler.

this could result in something incredibly important being missed, and
we have to become OS debugging experts to find out why.

jacob and i experimented with pypy3 about 18 months.  it didn't go
well :)  although the tests that did run, they did run faster, it's
just... it's far too risky.

if we were doing something that was a GUI app, for some "open"
project, there would be no problem - not least because you have to get
the GUI app working for Macs anyway.

but this?  this is *literally* USD 100 million territory, and using a
"personal preferred OS" is just... you just don't do that.  sorry!

l.

_______________________________________________
libre-riscv-dev mailing list
libre-riscv-dev@lists.libre-riscv.org
http://lists.libre-riscv.org/mailman/listinfo/libre-riscv-dev

Re: [libre-riscv-dev] Introduction

[Yehowshua]

> 
> this could result in something incredibly important being missed, and
> we have to become OS debugging experts to find out why.

When I can afford a desktop, I’ll use Debian.

Mac doesn’t have much storage for now so don’t want to do QEMU or dual boot.

Yehowshua
_______________________________________________
libre-riscv-dev mailing list
libre-riscv-dev@lists.libre-riscv.org
http://lists.libre-riscv.org/mailman/listinfo/libre-riscv-dev

Re: [libre-riscv-dev] Introduction

[Yehowshua]

Actually - I can do testing in Debian docker.
Share the filesystem with docker mount.
Fair enough!

Yehowshua

_______________________________________________
libre-riscv-dev mailing list
libre-riscv-dev@lists.libre-riscv.org
http://lists.libre-riscv.org/mailman/listinfo/libre-riscv-dev

Re: [libre-riscv-dev] Introduction

[Luke Kenneth Casson Leighton]

On Mon, Jun 15, 2020 at 10:08 PM Yehowshua <yimmanuel3@gatech.edu> wrote:
>
> >
> > this could result in something incredibly important being missed, and
> > we have to become OS debugging experts to find out why.
>
> When I can afford a desktop, I’ll use Debian.

biggest amount of RAM you can get.  i know someone (Rudi) who last
year bought 128 GB of DDR4 RAM, a USD 1000 motherboard, and then spent
USD 2,000 on the actual processor.  he said getting it into Thailand
was a real nuisance: it's so powerful that it's export-restricted (!)

> Mac doesn’t have much storage for now so don’t want to do QEMU or dual boot.

ahh yeh that's a pain.  ah well, we work with what we have.

l

_______________________________________________
libre-riscv-dev mailing list
libre-riscv-dev@lists.libre-riscv.org
http://lists.libre-riscv.org/mailman/listinfo/libre-riscv-dev

Re: [libre-riscv-dev] Introduction

[Hendrik Boom]

On Mon, Jun 15, 2020 at 09:49:05PM +0100, Luke Kenneth Casson Leighton wrote:
> On Mon, Jun 15, 2020 at 9:28 PM Yehowshua <yimmanuel3@gatech.edu> wrote:
> >
> > Also, I believe Cole had mentioned that you’re using a Mac?
> 
> ah.  right.  okay.  we're not supporting macs, and we're not going to
> do development on macs.  there are two aspects to this:
> 
> 1). when it comes to the ASIC layout, it is absolutely critical - and
> is Industry Standard Practice - to have full reproducible builds.  not
> even the username is different.  everyone doing the builds sets up
> carbon-copy machines, where you could literally do a file-system
> byte-level comparison and find absolutely everything is the same.
> 
> this is abbbsolutely essential when you are about to drop USD $5m on a
> chip tape-out... oh but the last person who checked the build used
> some totally different library and now "it doesn't work", finding the
> discrepancy results in time lost, you miss the tape-out window
> entirely, and the company loses a USD $100 million dollar deal because
> of it.
> 
> so it's actually *really serious* not to be using the exact same
> development workflow as everyone else.

Any chance the Mac might find problems the Debian doesn't?

-- hendrik


_______________________________________________
libre-riscv-dev mailing list
libre-riscv-dev@lists.libre-riscv.org
http://lists.libre-riscv.org/mailman/listinfo/libre-riscv-dev

Re: [libre-riscv-dev] Introduction

[Luke Kenneth Casson Leighton]

On Mon, Jun 15, 2020 at 10:13 PM Yehowshua <yimmanuel3@gatech.edu> wrote:
>
> Actually - I can do testing in Debian docker.

cool!

> Share the filesystem with docker mount.

yes :)

you only actually need around... 3-4 GBytes, if that.  a full OS is
*not* needed.  no GUI, no window manager - nothing.  run Cole's
scripts and you should be up and installed very rapidly.

https://git.libre-soc.org/?p=dev-env-setup.git;a=blob;f=hdl-dev-repos;hb=HEAD
https://git.libre-soc.org/?p=dev-env-setup.git;a=blob;f=install-apt-reqs;hb=HEAD
https://git.libre-soc.org/?p=dev-env-setup.git;a=blob;f=yosys-et-al;hb=HEAD

l.


l.

_______________________________________________
libre-riscv-dev mailing list
libre-riscv-dev@lists.libre-riscv.org
http://lists.libre-riscv.org/mailman/listinfo/libre-riscv-dev

Re: [libre-riscv-dev] Introduction

[Luke Kenneth Casson Leighton]

On Mon, Jun 15, 2020 at 10:15 PM Hendrik Boom <hendrik@topoi.pooq.com> wrote:

> > so it's actually *really serious* not to be using the exact same
> > development workflow as everyone else.
>
> Any chance the Mac might find problems the Debian doesn't?

given that it's python - and the tools (yosys etc.) that are
generating the HDL, and running the simulations on python (etc.) - not
in the slightest.

the only way that a mac would be actually useful is if it was a POWER9 core.

l.

_______________________________________________
libre-riscv-dev mailing list
libre-riscv-dev@lists.libre-riscv.org
http://lists.libre-riscv.org/mailman/listinfo/libre-riscv-dev

[libre-riscv-dev] using debian on a mac

[Jacob Lifshay]

On Mon, Jun 15, 2020, 14:09 Yehowshua <yimmanuel3@gatech.edu> wrote:

> >
> > this could result in something incredibly important being missed, and
> > we have to become OS debugging experts to find out why.
>
> When I can afford a desktop, I’ll use Debian.
>
> Mac doesn’t have much storage for now so don’t want to do QEMU or dual
> boot.
>

One thing you could do is run debian on an external USB drive -- when
installing debian maybe put the /boot partition on the mac's internal
storage and the / partition on the USB drive. That's what I'm doing for my
home server, since it's an Odroid XU4 that boots off a (slow) sd card then
uses a much faster external USB 3 128GB flash drive as the root filesystem
-- it's worked just fine for several years. It also has a 6TB hdd attached
to it.

One consideration is you will probably want to spend a bit more to get a
faster USB drive -- maybe just get a USB to 2.5" sata drive adaptor and a
cheap SSD.

Jacob
_______________________________________________
libre-riscv-dev mailing list
libre-riscv-dev@lists.libre-riscv.org
http://lists.libre-riscv.org/mailman/listinfo/libre-riscv-dev

Re: [libre-riscv-dev] Introduction

[Jacob Lifshay]

On Mon, Jun 15, 2020, 13:13 Anais Poirier <anais.shiraz@gmail.com> wrote:

> Hello All,
>
> My name is Anais, I'm a third year electrical and computer engineering
> student at the University of Toronto, and I am Cole Poirier's sister! I'm
> most interested in gaining knowledge and experience working on a hardware
> project.


Glad to have more people helping out!

I have limited experience with Assembly and Verilog as well as
> extensive experience with c/c++


You may want to learn Rust since it's being used for Kazan (the Vulkan 3D
graphics driver), as well as an IEEE 754 reference floating-point
implementation, an algebraic numbers library (basically computing using
exact real numbers using *lots* of number theory magic; the reference FP
implementation uses it to do arithmetic), and a few other parts of our
project.

Also, I find Rust to be awesome coming from a background in C/C++. No more
mysterious SIGSEGV or buffer overflows! (had quite a few of those in the
old C++ version of my Minecraft-like game.) Also, Rust makes it easy to
manage your source code when building a project since it has an awesome
package/build manager named cargo. It's the #1 most loved language on
stackoverflow 4 years in a row for a good reason! (I'll just leave it at
that for now, I could go on for pages)

https://stackoverflow.blog/2020/01/20/what-is-rust-and-why-is-it-so-popular/

but I am excited to learn Nmigen and hope
> to contribute to the Power Core. I am also the one who created the visual
> slides for the pitch last week and would like to help with the Elm
> Kanban/bug tracker visual front end for Bugzilla.
>

That would be really helpful, currently we don't have a very good solution
(manually updating pages on the wiki when we remember).

Jacob
_______________________________________________
libre-riscv-dev mailing list
libre-riscv-dev@lists.libre-riscv.org
http://lists.libre-riscv.org/mailman/listinfo/libre-riscv-dev

Re: [libre-riscv-dev] Introduction

[Luke Kenneth Casson Leighton]

On Mon, Jun 15, 2020 at 11:51 PM Jacob Lifshay <programmerjake@gmail.com> wrote:

> That would be really helpful, currently we don't have a very good solution
> (manually updating pages on the wiki when we remember).

on everybody's home page i've dropped a link to bugzilla with
"assigned bugs".  your one is there, too, jacob:
https://libre-soc.org/programmerjake/

the homepage is how we keep track of who did what and consequently
whether they'll receive donations.  consequently it's kiiinda in
everyone's interests to follow the protocol of keeping it up-to-date.

that way i don't have to do it.  or, let me put it another way: if i
do, i'll consider it "administrative tasks" and allocate myself 10% of
the donation! :)

l.

_______________________________________________
libre-riscv-dev mailing list
libre-riscv-dev@lists.libre-riscv.org
http://lists.libre-riscv.org/mailman/listinfo/libre-riscv-dev

Re: [libre-riscv-dev] using debian on a mac

[Luke Kenneth Casson Leighton]

On Mon, Jun 15, 2020 at 11:20 PM Jacob Lifshay <programmerjake@gmail.com> wrote:

> One thing you could do is run debian on an external USB drive -- when
> installing debian maybe put the /boot partition on the mac's internal
> storage and the / partition on the USB drive. That's what I'm doing for my
> home server, since it's an Odroid XU4

i love those!

ReFIND / ReFIT should allow booting from an external USB drive,
absolutely no problem.

l.

_______________________________________________
libre-riscv-dev mailing list
libre-riscv-dev@lists.libre-riscv.org
http://lists.libre-riscv.org/mailman/listinfo/libre-riscv-dev

Re: [libre-riscv-dev] Introduction

[Cole Poirier]

> On Jun 15, 2020, at 3:51 PM, Jacob Lifshay <programmerjake@gmail.com> wrote:
> 
> You may want to learn Rust since it's being used for Kazan (the Vulkan 3D
> graphics driver), as well as an IEEE 754 reference floating-point
> implementation, an algebraic numbers library (basically computing using
> exact real numbers using *lots* of number theory magic; the reference FP
> implementation uses it to do arithmetic), and a few other parts of our
> project.
> 
> Also, I find Rust to be awesome coming from a background in C/C++. No more
> mysterious SIGSEGV or buffer overflows! (had quite a few of those in the
> old C++ version of my Minecraft-like game.) Also, Rust makes it easy to
> manage your source code when building a project since it has an awesome
> package/build manager named cargo. It's the #1 most loved language on
> stackoverflow 4 years in a row for a good reason! (I'll just leave it at
> that for now, I could go on for pages)
> 
> https://stackoverflow.blog/2020/01/20/what-is-rust-and-why-is-it-so-popular/

Hehe Jacob I’m a kindred spirit. While she was writing a google maps clone for school in c++ I tried to help her once or twice and she got annoyed at how many times I got frustrated at simple things like “cout << endl” and said “this would be so much easier in rust!”

> That would be really helpful, currently we don't have a very good solution
> (manually updating pages on the wiki when we remember).

Yes that’s precisely what inspired this idea, Luke and I were talking about Kanban and I started to think of ways we could enhance it to use all of the data from the bugzilla rest API. Too many emails are currently being sent that don’t get raised as bug reports and the whole structure of bugzilla while very useful for discussions, is not good for keeping track of things from a high level. This should eventually help cover budgets and road maps as well. I’ll just be cloning different functionality from various kanban/planner type online services, and adapting them to precisely fit our needs.

Cole
_______________________________________________
libre-riscv-dev mailing list
libre-riscv-dev@lists.libre-riscv.org
http://lists.libre-riscv.org/mailman/listinfo/libre-riscv-dev

Re: [libre-riscv-dev] Introduction

[Jacob Lifshay]

On Mon, Jun 15, 2020 at 6:09 PM Cole Poirier <colepoirier@gmail.com> wrote:
>
>
> > On Jun 15, 2020, at 3:51 PM, Jacob Lifshay <programmerjake@gmail.com> wrote:
> >
> > You may want to learn Rust since it's being used for Kazan (the Vulkan 3D
> > graphics driver), as well as an IEEE 754 reference floating-point
> > implementation, an algebraic numbers library (basically computing using
> > exact real numbers using *lots* of number theory magic; the reference FP
> > implementation uses it to do arithmetic), and a few other parts of our
> > project.
> >
> > Also, I find Rust to be awesome coming from a background in C/C++. No more
> > mysterious SIGSEGV or buffer overflows! (had quite a few of those in the
> > old C++ version of my Minecraft-like game.) Also, Rust makes it easy to
> > manage your source code when building a project since it has an awesome
> > package/build manager named cargo. It's the #1 most loved language on
> > stackoverflow 4 years in a row for a good reason! (I'll just leave it at
> > that for now, I could go on for pages)
> >
> > https://stackoverflow.blog/2020/01/20/what-is-rust-and-why-is-it-so-popular/
>
> Hehe Jacob I’m a kindred spirit. While she was writing a google maps clone for school in c++ I tried to help her once or twice and she got annoyed at how many times I got frustrated at simple things like “cout << endl” and said “this would be so much easier in rust!”

At least C++ is type safe, printf is a security nightmare, especially
when using a dynamic format string.

Also, openstreetmaps is definitely the place to get data if building a
maps application. It's good enough that Apple used it to jump start
their maps app (unfortunately without giving credit -- they got into
deep trouble for that)

Jacob

_______________________________________________
libre-riscv-dev mailing list
libre-riscv-dev@lists.libre-riscv.org
http://lists.libre-riscv.org/mailman/listinfo/libre-riscv-dev

Re: [libre-riscv-dev] Introduction

[Cole Poirier]

> On Jun 15, 2020, at 8:04 PM, Jacob Lifshay <programmerjake@gmail.com> wrote:
> 
> At least C++ is type safe, printf is a security nightmare, especially
> when using a dynamic format string.

Yikes!


> Also, openstreetmaps is definitely the place to get data if building a
> maps application. It's good enough that Apple used it to jump start
> their maps app (unfortunately without giving credit -- they got into
> deep trouble for that)

Yeah it’s the standard 2nd semester 2nd year ECE project at the University of Toronto, and they use openstreetmaps. Oh apple!

Cole
_______________________________________________
libre-riscv-dev mailing list
libre-riscv-dev@lists.libre-riscv.org
http://lists.libre-riscv.org/mailman/listinfo/libre-riscv-dev

Re: [libre-riscv-dev] Introduction

[Staf Verhaegen]

[-- Attachment #1.1: Type: text/plain, Size: 582 bytes --]

Cole Poirier schreef op ma 15-06-2020 om 18:09 [-0700]:
> 
> 
> Yes that’s precisely what inspired this idea, Luke and I were talking about Kanban and I started to think of ways we could enhance it to use all of the data from the bugzilla rest API.

Have you guys validated gitlab ?
It seems you guys are trying to reinvent the wheel. gitlab for example
has issue boards, supports check lists in issues etc.
gitlab the company may not be better the Microsoft but the source code
is free. You can host your own gitlab, like the LIP6 people are doing.

greets,
Staf.


[-- Attachment #2: Type: text/plain, Size: 177 bytes --]

_______________________________________________
libre-riscv-dev mailing list
libre-riscv-dev@lists.libre-riscv.org
http://lists.libre-riscv.org/mailman/listinfo/libre-riscv-dev

Re: [libre-riscv-dev] Introduction

[Luke Kenneth Casson Leighton]

On Tue, Jun 16, 2020 at 9:51 AM Staf Verhaegen <staf@fibraservi.eu> wrote:
>
> Cole Poirier schreef op ma 15-06-2020 om 18:09 [-0700]:
> >
> >
> > Yes that’s precisely what inspired this idea, Luke and I were talking about Kanban and I started to think of ways we could enhance it to use all of the data from the bugzilla rest API.
>
> Have you guys validated gitlab ?

yes we evaluated gitlab.

* from a security perspective it is a nightmare (vast amounts of code
and involving arbitrary code execution)
* from a code volume perspective there is extra cost involved in the hosting.
* the load average on my server jumped to a permanent 0.6 (60% cpu
utilisation) with *NO USERS*
* load time was well over 20 seconds due to the amount of javascript shit.


> It seems you guys are trying to reinvent the wheel. gitlab for example
> has issue boards, supports check lists in issues etc.

yes it does.  the hassle associated with it unfortunately has already
eliminated it from consideration.

> gitlab the company may not be better the Microsoft but the source code
> is free.

unfortunately the hosting, security audit, maintenance and hassle is
not monetarily zero cost.

> You can host your own gitlab, like the LIP6 people are doing.

they have employees specifically dedicated to that task, as do raptor
engineering.

l.

_______________________________________________
libre-riscv-dev mailing list
libre-riscv-dev@lists.libre-riscv.org
http://lists.libre-riscv.org/mailman/listinfo/libre-riscv-dev

Re: [libre-riscv-dev] Introduction

[Staf Verhaegen]

[-- Attachment #1.1: Type: text/plain, Size: 1218 bytes --]

Luke Kenneth Casson Leighton schreef op di 16-06-2020 om 11:59 [+0100]:
> On Tue, Jun 16, 2020 at 9:51 AM Staf Verhaegen <staf@fibraservi.eu> wrote:
> > Cole Poirier schreef op ma 15-06-2020 om 18:09 [-0700]:
> > > 
> > > Yes that’s precisely what inspired this idea, Luke and I were talking about Kanban and I started to think of ways we could enhance it to use all of the data from the bugzilla rest API.
> > 
> > Have you guys validated gitlab ?
> 
> yes we evaluated gitlab.
> * from a security perspective it is a nightmare (vast amounts of codeand involving arbitrary code execution)

What security implication are you considering for a fully open source project ?
You could not use the release feature of gitlab for example.

> > It seems you guys are trying to reinvent the wheel. gitlab for examplehas issue boards, supports check lists in issues etc.
> 
> yes it does.  the hassle associated with it unfortunately has alreadyeliminated it from consideration.

Isn't it time to reevaluate if people are planning to implement kanban boards and other things on top of the bugzilla REST API?
Developing, maintaining, auditing that code will also have cost implications.

greets,
Staf.


[-- Attachment #2: Type: text/plain, Size: 177 bytes --]

_______________________________________________
libre-riscv-dev mailing list
libre-riscv-dev@lists.libre-riscv.org
http://lists.libre-riscv.org/mailman/listinfo/libre-riscv-dev

Re: [libre-riscv-dev] Introduction

[Staf Verhaegen]

Luke Kenneth Casson Leighton schreef op di 16-06-2020 om 11:59 [+0100]:
> On Tue, Jun 16, 2020 at 9:51 AM Staf Verhaegen <staf@fibraservi.eu> wrote:
> > Cole Poirier schreef op ma 15-06-2020 om 18:09 [-0700]:
> > > 
> > > Yes that’s precisely what inspired this idea, Luke and I were talking about Kanban and I started to think of ways we could enhance it to use all of the data from the bugzilla rest API.
> > 
> > Have you guys validated gitlab ?
> 
> yes we evaluated gitlab.

Alternatively I played in the past with kanboard (kanboard.org). You can find a bugzilla plugin for it on the net but it does not seem to be official so needs to be tested.

greets,
Staf.


_______________________________________________
libre-riscv-dev mailing list
libre-riscv-dev@lists.libre-riscv.org
http://lists.libre-riscv.org/mailman/listinfo/libre-riscv-dev

Re: [libre-riscv-dev] Introduction

[Luke Kenneth Casson Leighton]

On Tue, Jun 16, 2020 at 1:33 PM Staf Verhaegen <staf@fibraservi.eu> wrote:

> What security implication are you considering for a fully open source project ?

one of NLNet's grant recipients was hacked via their (unfunded)
infrastructure being used to develop the (funded) code.

the hackers gained control of the git repositories and inserted
malicious code directly into the git repositories, as code commits,
pretending to be from one of the developers.

this was then downloaded by thousands of unsuspecting users interested
in privacy-respecting applications and trusting that the project -
funded by NLNet - would provide it.

NLNet-funded projects, by nature of them being directed towards
privacy, are *automatic* high-value hacking targets.


> You could not use the release feature of gitlab for example.

who is going to stop working on everything that they are doing and
focus solely and exclusively on the evaluation for fitness of purpose,
and perform the full security audit of the (massive) github codebase,
and work out its required configuration?

this has been discussed many times.  every time everyone says "why
don't you just use gitlab, it's so simple and has everything you
need", unfortunately not being aware of the time and resource
implications both from the initial install, migration, training,
resource utilisation and maintenance.   we simply do not have time or
resources to cover all of that.

the unix philosophy serves us extremely well: each tool shall do one
thing and do it well.

gitlab fundamentally violates that.

this is a perspective that can only really be fully appreciated when
you have tried to do simple web development tasks that pull in 250
megabytes of dependencies.


> > > It seems you guys are trying to reinvent the wheel. gitlab for examplehas issue boards, supports check lists in issues etc.
> >
> > yes it does.  the hassle associated with it unfortunately has alreadyeliminated it from consideration.
>
> Isn't it time to reevaluate if people are planning to implement kanban boards and other things on top of the bugzilla REST API?

there is existing kanban board code.   we do not have to write one at all
https://github.com/leif81/bzkanban

however Cole feels inclined to write something and i am not going to
say "no you can't do that".

> Developing, maintaining, auditing that code will also have cost implications.

my brother dan has a business need which happens to match precisely
with what we also need.

therefore we are not paying for it.

in addition it is a *focussed* and incremental enhancement, where we
get the opportunity to input and decide what *we* want.

not what gitlab says we need.

l.

_______________________________________________
libre-riscv-dev mailing list
libre-riscv-dev@lists.libre-riscv.org
http://lists.libre-riscv.org/mailman/listinfo/libre-riscv-dev

Re: [libre-riscv-dev] Introduction

[Cole Poirier]

On Jun 16 2020, at 6:13 am, Luke Kenneth Casson Leighton <lkcl@lkcl.net> wrote:

> the unix philosophy serves us extremely well: each tool shall do one
> thing and do it well.
> 
> gitlab fundamentally violates that.

Indeed. My application will be specific to our needs with regard to
organization and planning, without *any* extraneous things like managing
CI tests/builds/deployments.
 
> this is a perspective that can only really be fully appreciated when
> you have tried to do simple web development tasks that pull in 250
> megabytes of dependencies.

This is the reason I will be writing the application in Elm, all
dependencies are *compiled* into the application at *compile* time, the
resulting transpiled-to-js compressed binary is pretty tiny compared to
most javascript frameworks, or vanilla js applications that have
comprable functionality. But comes with the added benefit of
guaranteeing there will be *zero* runtime errors.
 
>> > yes it does.  the hassle associated with it unfortunately has
>> alreadyeliminated it from consideration.
>> 
>> Isn't it time to reevaluate if people are planning to implement
>> kanban boards and other things on top of the bugzilla REST API?
> 
> there is existing kanban board code.   we do not have to write one at all
> https://github.com/leif81/bzkanban
> 
> however Cole feels inclined to write something and i am not going to
> say "no you can't do that".

I will be effectively 'cloning' various different existing js projects
functionality, but while complex GUI apps are a very significant
undertaking in js, in Elm, a language built and designed from the ground
up to build high-performance single page web apps, cloning the
functionality of 1,000s of lines of javascript is a vastly simpler
though non-trivial undertaking.

> my brother dan has a business need which happens to match precisely
> with what we also need.
> 
> therefore we are not paying for it.
> 
> in addition it is a *focussed* and incremental enhancement, where we
> get the opportunity to input and decide what *we* want.
> 
> not what gitlab says we need.

Yes, I will implement only what we need from existing projects not take
all of the extraneous 'features' that various people have added over the
years. It should load very quickly and perform well even on low-bandwith
connections and low-spec devices. I am building the foundation of this
single-page web-app for Dan, and it will serve a dual purpose being the
foundation of our bug tracker's *additional* not replacement buzilla
frontend. But, as I have to work on bug/budget/time/etc. tracking
functionality specific to our projects needs, *some* money will be
needed for that.

Cole

_______________________________________________
libre-riscv-dev mailing list
libre-riscv-dev@lists.libre-riscv.org
http://lists.libre-riscv.org/mailman/listinfo/libre-riscv-dev

Re: [libre-riscv-dev] Introduction

[Lauri Kasanen]

On Tue, 16 Jun 2020 11:29:45 -0700
Cole Poirier <colepoirier@gmail.com> wrote:

> This is the reason I will be writing the application in Elm, all
> dependencies are *compiled* into the application at *compile* time, the
> resulting transpiled-to-js compressed binary is pretty tiny compared to
> most javascript frameworks, or vanilla js applications that have
> comprable functionality. But comes with the added benefit of
> guaranteeing there will be *zero* runtime errors.

How is the browser compatibility of what it generates? E.g. if it uses
some feature X that needs Chrome Y or FF unstable, and doesn't work in
FF LTS or other older browsers.

- Lauri

_______________________________________________
libre-riscv-dev mailing list
libre-riscv-dev@lists.libre-riscv.org
http://lists.libre-riscv.org/mailman/listinfo/libre-riscv-dev

Re: [libre-riscv-dev] Introduction

[Cole Poirier]

> On Jun 16, 2020, at 11:16 PM, Lauri Kasanen <cand@gmx.com> wrote:
> 
> How is the browser compatibility of what it generates? E.g. if it uses
> some feature X that needs Chrome Y or FF unstable, and doesn't work in
> FF LTS or other older browsers.

As far as I am aware it doesn’t require any other features than JavaScript being enabled in the browser, but I will be running compatibility checks as I develop the app.
Definitely a concern worth reviewing.

Cole
_______________________________________________
libre-riscv-dev mailing list
libre-riscv-dev@lists.libre-riscv.org
http://lists.libre-riscv.org/mailman/listinfo/libre-riscv-dev