Okay, great. So welcome everybody to the 2018 edition of the Debian Electronics Buff. This is meant to be an opportunity for us to share information about what's happening with packages that are used for electronics design and related tasks that are in Debian. It's a little bit different than last year. I asked for a Debian Electronics Buff because we were sort of in what I thought was a slightly desperate situation with not enough people working on the electronics packages to even sort of maintain the status quo and I'm very pleased that several folks have sort of popped up since the session last year and as a result I personally think things aren't in too bad a shape at the moment but very much the same as in the past. I think there's a real value in our sort of talking as a team and as people who are interested in these packages. So I was going to propose that maybe a good way for us to spend the time today is to talk a little bit about progress that's been made since last year. I'm happy to talk about a little bit of that but then others of you that have been working on things are using various electronics packages that know more about those packages than I do. I hope we'll chime in. I assume there's got to be, it looks like there are a couple of mics down there we can pass around to one in front here and one there on the table. So when the time comes we can pass those around. I have one open question about packages that I'm helping to maintain in the electronics team that I'd love to talk about just a little bit and if there are other open questions with other packages within the electronics realm it seems like a great chance for us to talk about those and if there's any decisions we can help drive towards that's great and then generally what can we do going forward to do an even better job of maintaining the various electronics tools that are packaged in Debian. For those of you who don't know I went ahead and stuck the URL on the slide here so it would be quite visible in the video and so forth as to where you can sort of find the root of pointers to follow about things that are happening in the electronics team. So I think for lots of teams in Debian not just electronics one of the big things that's happened in the last year was we moved a bunch of package repositories over to the new Salsa infrastructure within Debian and in the process there was a little bit of sort of name shuffling and cleaning up of the group name so electronics dash team is where you'll find all the electronics related packages within the Salsa infrastructure. I looked earlier today and as of this morning we have 15 current members identified in the electronics team on Salsa which is pretty cool. I don't know that all of those are actively working on stuff but we've had a couple of folks join just I think in the last few days and hopefully we see continued interest going forward and more people wanting to join the team. I think I counted about 26 source packages that are currently in the electronics team group there. There are I think other pieces of software they're flagged as being in the electronics section in Debian that are not currently on Salsa under electronics team and there's of course nothing wrong with that but I would certainly encourage anybody who's maintaining electronics related software in Debian that's not already inside the electronics team to at least consider the idea of joining the team helping to maintain the collective set of packages that are useful for electronics stuff and maybe getting some help maintaining the pieces that they're working on outside of the context. And then sort of the last thing that I think I can do reasonably effectively because I am sort of in the middle of it is talk a little bit about what's going on with the particular schematic capture and printed circuit board tool set that I use the most which is the GPL EDA or GEDA suite and so let me just rattle through a little bit. The sort of main design capture tool sort of schematic level capture tool is this thing called GEDA GAF which produces the schematic tool GSCAM and various related stuff. There have been some minor packaging updates in the last year but we're still on upstream stable version 1.8.2 there has not been an upstream stable release in a really long time and I will tell you that I personally see crashes in GSCAM from time to time and there's a really weird rendering bug where every once in a while it's like text rendering just goes berserk and if you refresh the screen or change the scaling or something it fixes itself and so there are clearly things that even as a regular user of the tool I stumble over all the time but just haven't been motivated to try and track down and part of the reason for that is that upstream is now up to something like version 1.9.2 which they explicitly tag as an unstable release. On the other hand when you ask questions about things it's not unusual on the list to have it pointed out that oh that's fixed in current head in the repo and so one of the things that I find myself scratching my head about is if slash when it would make sense for us to package the upstream unstable 1.9.2 if in fact it turns out to fix some of the known bugs in 1.8.2 but I haven't sort of gotten enough enthusiasm or momentum towards doing that to actually do something there's anybody else here that is using GSCAM and friends and has an opinion about that I'd love to hear it if there's nobody in the room that's using the stuff and folks who are watching the stream or see this video later want to send me email and give me thoughts that would be great I'm one of multiple people who helped to maintain that sort of packages in Debian so I'm not the only person with an opinion does anybody have something they want to throw out right now about that or is everybody kind of not caring whatever I do is just fine yeah yeah smiles around the room okay the second thing I'll mention is I mentioned last year that the GEDA GAF package was being forked by another upstream community to create a set of tools called Lepton EDA Lepton as a name is a little bit unfortunate because there is already a Lepton for a totally unrelated thing packaged in Debian but you know that's our lives it appears to me though I haven't really been following it super closely that 1.9.4 is the latest Lepton release they forked I think late in 2016 and have been working I have not seen anybody actually package that for Debian I guess one of the things that we could consider is whether that's worth packaging and bringing in either in addition to or in parallel to packaging the 1.9.2 version of GEDA GAF my only concern about that has to do with sort of the extent to which either or both of those teams is paying attention to the PCB R&D fork of PCB which I'll get to in a second with respect to the tool PCB which is the printed circuit board design tool in this particular suite in the last year that's been updated from version 4.0. something to 4.1.2 mostly bug fixes a few changes in the way units are recorded in design files so if you use the current version of PCB you want to be a little careful about thinking that you could go back to previous versions and not have a little bit of a data issue with the file format being tweaked but right now 4.1.2 is working just fine for me and all the things that I do however there was this project I talked about some last year that's a fork that's been going on now for at least four maybe five years of PCB which is now essentially a completely new tool called PCB-R&D some really dramatic percentage of the source code has now been replaced a lot of internal data structures and code structures have been reworked PCB-R&D is interesting to me because it allows me to sort of carry forward all of the designs I have in PCB and all of the effort that I've put into library parts for both schematics and printed circuit board work and in general the same process flow for moving from schematic capture to printed circuit boards and so on that we have with PCB but PCB-R&D has a new file format it now encapsulates the concept of pad stacks within footprints and sub-circuit support exists and one of the things that there's really no easy way to do with a footprint in PCB that you can do in PCB-R&D is have features in the outline layer which means things that printed circuit board shops need documented in the outline layer for creating things like slots for tabs on a part don't have to be quite as hackishly handled as they were in the past with PCB so I'm personally actually looking at moving some or all of my designs over from PCB to PCB-R&D in the next year starting with a design that I'll probably be moving you know next week as a result I've been personally packaging PCB-R&D and tracking upstream quite closely and that's currently at version 2.0.0-1 which is the latest upstream release and then I was just, people ask all the time so I put one of the examples of a board that Keith and I did in this tool chain that circuit board is about, I don't know, yay big, it's a whole lot bigger on the screen than it is in real life but for those that are watching the stream and trying to figure out what electronics tools are all about it's to allow you to design things like this so with that the stuff that I feel like I have to contribute to the buff is much done. Things that I think would be really interesting to hear from somebody else about are the status of the key cad tool chain for doing printed circuit board designs and that other major tool set if there's anybody here that wants to talk to that Noodle's I know that you've been doing work on things like open OCD that are also in this space it'd be really cool to sort of hear what's going on there and what the status is and anybody else that has stuff that you'd like to offer sort of some status reports since this time last year that would be really great there's a couple of microphones down here if we could kind of, if anybody that wants to add some additional progress stuff would jump in, let's do that and then we can open up and take questions Yeah so open OCD wasn't in great shape last year I've pulled it to the latest upstream release and sort of triaged a bunch of the bugs we had one particularly embarrassing security issue this year that involved me having to do back ports to pretty much every release that we currently had out there at the moment I think the main thing about it is I'd like to see a new upstream release it doesn't actually have ARM64 support it's like 0.10 is the current open OCD release and it's from January 2017 and they've done a lot of work upstream on getting ARM64 support working in it and that would be nice to see I don't really want to get involved in doing a back port of upstream work on that because there's just been so many changes to that but I've had a few interactions with upstream so I might poke them and go hey, any odds the other piece I've been working on is the whole SIGROC toolchain so that's LodgeGanalyzer again upstream is actually a Debian developer but just didn't have time to look after it so I took over from that and again it's up to date that's actually been quite useful for me because it's now working in ways that it wasn't previously I got a question in terms of electronic design we cover in the team we've got some tools that are about electronic tools such as JTAG and LodgeGanalyzer the other piece that I know you and I have discussed BDLR compiler toolchains for embedded devices so I did a rather cac-handed NMU of SDCC this week but it seems like a tool that is useful for embedded devices that very much fits in the embedded space today I've been spending some time on a full GCC toolchain for the ESP266 which again doesn't fit into anything that runs Linux it's an embedded space processor now SDCC is small enough I can say right I think that should be part of the team a full GCC port seems a little bit too heavy but I wondered what anyone else's opinions on the whole matter were actually Keith if you wanted to jump in and talk a little bit about the GCC ARM for embedded things that you did I know you and I are planning to talk about that in more detail tomorrow but the part of it that might be relevant here about you know where's that package in the archive and where does that stuff live and is this relative to it yeah we have a wow so the GCC GCC can obviously be compiled for a bazillion different targets one of the targets that we have for ARM right now is obviously the regular Linux ARM compiler what we need what I needed instead was GCC compiled without any libc dependency so that I could use GCC in a library less embedded environment that turns out to actually be impossible GCC requires a libc but you can compile it without any operating system requirements it doesn't depend upon any operating system infrastructure so there is in the archive a GCC ARM none which is to say it doesn't depend on any operating system interface and it uses the EABI and for an embedded environment you don't care what the EABI is because there is no library there one of the big problems that I've had with embedded systems is finding a libc to use in the GCC AVR world there's an AVR a special libc for that tool chain STCC comes with a libc for STCC GCC ARM none EABI depends upon nanolib nanolib actually requires a POSIX operating system under it in the default compilation mode so we actually don't have a good libc for embedded systems yet I've been hacking around with a nanolib that replaces the standard IO bits from nanolib with the standard IO that comes with the AVR libc and that's almost a good idea it's really a very nice little embedded standard IO library that I'm pretty fond of obviously it's not high performance but in my embedded environment standard IO is used for debugging only so it would be great if we had some standard mechanism, common mechanism across platforms for a libc that was used for embedded systems nanolibs as close as we have right now but it's not quite there the way that I initially packaged the GCC ARM was our standard libc our standard GCC source had a set of patches on top of that so it had a build dependency on the GCC source package which is not a source package it's a binary package in the repository that actually installs the source code to GCC in your system so when you install the GCC source package you get the sources to GCC installed in a machine in a way that you can then build a compiler from them so our usual GCC targets use that package as one of their build dependencies and then just compile it with the appropriate options that's what I did with the original port of the GCC ARM non-EABI compiler right now another person who's maintaining that package, August I'm not sure Augustin has decided to instead incorporate the sources to GCC the package I'm not quite sure why, I may go re-investigate that but it's really useful if you're building an embedded GCC toolchain to use the standard Debian GCC sources that way you get a common upstream set of somebody else is maintaining the bulk of your compiler which is awesome so you get security fixes, you get upstream integration you get back ports, that kind of thing so that's a really great way to start and I think I'm going to go fix the ARM EABI non-1 I know Charles has been doing that for his toolchain so it makes a really small source package, you literally have a build dependency on our GCC source package a small set of host-specific patches which could eventually get integrated into our shared GCC source package and then just here's the target architecture go build a compiler so I guess there's two detailed questions one is what section of the archive should that package live in and is it something that sounds like it would be appropriate to put under the electronics team on Salsa or does it just live somewhere else and we don't care and more precisely to help answer Noodle's question of what should he do with the ESP version of this if he ends up building something he wants to put in the archive I don't know what area it should live in yeah good question I'm not really sure I know either and this is one of those things where it's like okay who's going to care for this well it's unclear to me that anybody outside of electronics team space is really going to be wildly enthusiastic about embedded systems programming which is where these compilers really get used but maybe I'm wrong maybe different and I have no answer for these embedded systems but different question is we have a lot of electronics packages maintained in Debian science team and we have a lot of packages maintained by non-team do you intend to try to get this same under your same policy in your same Salsa group because I think this would make perfectly sense to collect the electronics people Do you have an example or two of the package you're sharing on? The page of Debian science electronics and you can show and all people can see I have a lot of stuff I can pronounce the all should I put it in ILC the link I'm not on IRC at the moment I will tell you it's blends.debian.org Hang on one second We could actually to a browser and I need to shove it over there Hang on Hey that actually almost worked Wow but I can't see it now Oh I get too complicated sometimes Sorry people Okay so where is it? Blends Blends Blends.debian.org Slash Science Slash tasks Slash electronics Electronics as in C missing Yeah if only I could see what I was doing What I was doing Yes enter There you see a list of all those packages which somebody most probably not you considers electronics relevant Yeah so it's interesting the Arduino stuff is another kind of weird example in this space right because it's also like I guess it depends on GCC AVR or does it I don't know it certainly provides on top of that And you have a lot of packages maintained by Debian Science maintainers, private people and there are only a very few the minority is maintained by the Debian Electronics team and my question is would it make sense to invite those people like Milan Kutcheri to package AVR in the Debian Electronics team to the same policy and enable all maintainers doing something Sounds like so much work I'm pretty relaxed about it actually I mean I love the fact for example that AVR dude is packaged in Debian but I don't as to where it happens Do you have a sense one way or the other would you love to see some of these things go away or I did this with the Debian Meet stuff because it was the only way to make sure that we have all package maintained in kind of the same quality and makes them up to date and so I'm not sure how it was with the electronics stuff but we also So there's an interesting overlap here because the GEDA stuff I mean it's mentioned here but that is actually that's the GEDA GAF package in the electronics thing GCC AVR is showing up here yeah that's another I even don't know who is maintaining this plans tasks are maintained by Debian science people and the only thing what you give is depends package name okay so this is a I get it so this is a task which contains a list of packages that people think are relevant to science slash electronics okay so there's no particular so this is the same problem I identified before that there are a lot of things electronics people care about that are not actually within electronics team and I don't you know what I care about is that they're actually being attended to and if they're being well maintained and nobody's stressed about it I don't care if it's under electronics team or not I would certainly invite anybody whose package shows up somewhere like this what I mean yeah you know if anyone who maintains a piece of software that's in science task electronics wants to come you know put that package on salsa under electronics team and collaborate with the rest of us that probably be just fine one one further I want to respond to one of your points I think you have a well either I'm not aware of it or we just don't have one but there's no coherent policy between the team about how the packages are maintained it's a central point where people are maintaining packages but we don't have a team why this is how you do things there's some advice that goes on the list but don't put too much stock in that it's a convenient place to put packages that I think are often used as tools for the thing you want to get done rather than the end of themself and therefore having lots of people who are potentially interested able to work in them with the benefit the team offers yes we don't have like one grand unifying how we're going to package things policy we are very much loosely organized in that I there are many packages of the 26 ish source packages and electronics team that I've never looked at or used much less work on so it's yeah I don't think we have a really simple answer but I would certainly invite anybody maintaining a package that's on this list to consider whether joining electronics team would be helpful my point is that electronics team is not widely known under the deviant maintenance it had almost completely vanished this time last year and so what we're trying to do is kind of get things back up to speed and honestly if someone came to me at some point and said you idiot why aren't you doing it some other way I think you know we would all smile and go thanks for educating us but right now those of us who are actually working on the packages that are in the electronics team repos don't know of anywhere else to put them so I think I have quite a good overview about all this kind of topic related stuff and electronics was kind of escaping of my so and the other thing I want to say is would one of the team mind about maintaining this task inside the deviant science team because this is probably quite often and at some point in time somebody said down what's electronic relevant and put on this list but this is probably we have more packages that are relevant for electronics and not mentioned here and maybe there is some stuff inside which is questionable this would be really cool if somebody from the team who knows the stuff would check this task I'm curious enough to at least take a look at it one time I don't know that I'm willing to commit to trying to help maintain this it's not about you but if you have 15 people that's part of the answer though I personally am interested enough I will take at least one look at it maybe some of us can sit around on a hack lab or something and scroll through and see what's interesting in particular if there are things that pop out as not being well maintained that we ought to try and suck in and you know rescue the packages as was being discussed this morning then maybe that's a way to identify some potential targets did you have something else you wanted to throw in or just the right so is there anybody here that uses or helps maintain the key cad toolchain Carson do you want to talk about that a little bit what's happened in the last or any of you I'm not maintaining the key cad library but our company use key cad to develop electronics devices so we are trying to make some patches for new features for key cad maybe we can push that package push that patch into the upstream this is what we are going to do that would be great that would be great yeah my name is Carson I am packaging the key cad package for two years I think just to mention patches welcome plus please go upstream that's the best way to do I don't want to add patches that just exists and there we are and other people and users are also useful in Apple and I don't want to diverge much from upstream so yeah key cad 5 is alive now for three weeks yeah this was a little bit yeah difficult sometimes not from the Debian side more from the upstream side people are happy to get new contributors and to new maintainers and it's a little bit sometimes say at a chaotic but okay we've done it I've got some communication with Jean Renaud I think it's the name he's doing the PPA for Ubuntu and we got some common sense how to do the package layout and so we mostly found now given packages or living packages so we can live in Debian and Ubuntu as well and if people using the PPA it's not that big hassle for users so it's just an upgrade of packages and if we go down we don't use PPA I also got some conversations to upstream as well and mainly I do also with German localizations if I got time in the past few months I got not that much time to update the documentation for the e-schema and all the tools inside so I mainly get the focus on updating the documentation of the LTNN and yeah, ngspice is still living in UQ if someone wants to poke with FTPMAS those are living since two months now and I would be happy to enable also some simulation stuff once ngspice is enabled accepted into main because upstream was very friendly and communicate also to me and take a big advantage to just with version 28 get rid of all the non-free stuff yeah, I was excited to see that but it was quite easy more or less so that's still sitting in what kind of stuff would be needed to be done and say what okay, we will do it so that's still sitting in the NMQ right now okay, maybe we can poke somebody here while we're there just don't want it poke then we are and it has such a complicated history I can completely understand why it might put the fear in someone to want to deal with it but yeah do you want to jump in? yeah, so because you asked for users so we are also using Kiket with the pocket science lab maybe some of you might have seen it we have put it on the table on the ground floor yeah, and we are moving now to production, to producing more so we have a few feature requests I don't know if you have good relationships to upstream let's talk later more in details for example like commercial producers have some specific requirements for example some different formats and so on so yeah, it's pretty exciting to see like completely open hardware, free hardware to move to production here with Kiket so the whole chain yeah, all layers are free yes, yes and by the way those who haven't noticed Keith and I will be doing a talk tomorrow I don't remember what time on how we are using entirely free stuff in the design development of the electronics and the actual rockets that we find are a rocketry hobby so that's sort of a use case example and why we do all that and the various ways we have ended up contributing back to Debian as a result so yeah, so other thing you've got, what do you want to jump in on? yeah I'm packaging GHDL which is the GHDL simulator I've been doing that for a while I already all uploaded in February but the package was rejected because of a problem and that was the 035 the last latest stable the latest release at least and so the libraries got a bit different and so I've been redoing the packaging because including the external libraries changed and actually got better but yeah, I wasn't working that much over the month I hope to upload it before today and didn't manage it but it'll be soon it's a bit of a complicated package because yeah, it's a compiler and it supports internal backend, it supports LLVM and GCC and I decided to put them all in and yeah, so the support that comes with it which is free software is GHDL93 and it needs the official IEEE libraries for GHDL2008 support which I then will have the package as a non-free binary which is which will come later and since I had to integrate that somehow it's been it's been a bit longer but it'll come soon Is it all feeling good or are there things various of us could try to help you with while we're all here at Dubconf? No, I've been working with myself and there's a lot of decisions in how to organize it and well, I'm finalizing on something and I think once I got it uploaded I think I can share some of it. Okay, very cool yeah, certainly while we're here at Dubconf if there's things that we can do to help each other out that would be great but yeah other people that are, yeah you want to jump back in, noodles? Are there other things people are maintaining or working on or want to talk about? Let's just dive right in. I have a question about the pocket science stuff you're using a PIC24 chip do you have an open tool chain for that or are you using the horrendous MPLAB stuff? So actually yeah we're using a PIC24 it's not open because like we base it on a previous project so we actually created it from there step by step and then also we moved to so we're moving like making it open step by step the idea is like maybe a next version move to but like actually there are always a lot of small things to improve and at some point you have to decide to make a version, maybe go into production because we're also developing software for it so we want more developers who can work with the device and use the software and so on and get it out into the education from making the hardware to getting like free education materials for schools or have startups use it or whatever that's our idea but as you say and the chip itself is also not being open right so anyone who wants to provide us with a free chip that's a big challenge right? Yeah I hear PICs the ecosystem is terrible in particular I play with the bus pirate which actually ties into some of the logic analyzer stuff and it's a lovely device and it compiles stuff for it because it's a PIC24 it's a complete PN Yeah and Keith and I had this interesting experience that we had a device that we built around an AVR at one point and then we kind of went and looked when we were talking about maybe manufacturing some and realized that we could buy 32 bit ARM core SOCs for less money then we could get either AVRs or PICs for that's not always true it depends on how much IO and what capabilities you need and so forth but I've been really impressed at how much the price on the ARM stuff has come down and since that does have a really great free and open toolchain available for most of it and we figured out how to do source debugging on most of them with open OCD and other things that seems to be a pretty good place to land right now. I'm personally really really interested in risk 5 and I'll be showing up at the risk 5 buff tomorrow with a couple of toys we can talk more about that in that context that is sort of peripherally related to electronic stuff but or at least to me it is because to me it's all about getting chips designed but you know yeah, whatever. Other folks have things they want to talk about? Questions? I've started a project which is which is all using free software and free toolchains to make some electronic devices so my keyboard here is all designed by KeyCAD and the program the chip on it is STM32 I use ARM9E BI-GCC for source code compiling and so it's a pretty free hardware I think. That's cool. I think the development in Linux is getting better and better pretty optimistic for risk 5 I already got one but I've not started the risk 5 development yet. Since you mentioned if we have questions, for instance I'm currently developing well, I guess you could call it a peripheral in the sense that it supports that it's meant to be attached to a regular Linux machine preferably a Debian one and I was wondering do you think it makes sense to do things like actually packaging the firmware for the devices in the archive so that people can actually just get an already built version of the firmware from Debian instead of from me? So putting binary firmware into Debian is something we've talked about at various times in the past. I meant putting the source firmware in the archive so that people can get the right image built by Debian. The products that Keith and I build are all supported by binaries that are built from the Altos source package which is in Debian and we ship the binary firmware for all of our products in the Debian binary package so at least in our case for example of where we're already doing that I know that if we start talking about really huge firmware images then the archive maintainers might have questions about how important it really is to put that on all of the mirror network but I really like being able to just apt install Altos anywhere and have all the stuff I need so I've actually been we've been talking about at some point maybe if I ever get around to it refactoring so that instead of delivering a single binary package from our growing in size source package we might split it up because there's really no reason for all those firmware binaries to be rebuilt on all of the architectures auto builders but compared to some of the really large packages in Debian that take forever on the auto builders it's really not a huge big deal so we just haven't worried about it for much yet but I would think as long as we're not sort of abusing that network I can't imagine why it would be a real problem I certainly hope it's not a problem because I'm doing it anybody else sorry you said you said the source package was Altos ALTOS okay I'm cloning it right now it's big sorry well I don't know maybe it's not related to most of the people here but actually I discovered that there's a completely open source torture from successes maybe I just need to put up some background there is a brand a manufacturer of APJA that is called LATIS and they have a series of APJA board that is called IC40 and they have the open source torture and actually I have tried the open source the lens that is pretty awesome and actually I have burned the RISC-5 core on it and it works like charm so I'm pretty optimistic that one day we all have a completely open source torture to educate our maybe college student or graduate student to do their development so thank you so you've actually burned a working RISC-5 implementation using an entirely free tool chain into a LATIS part oh dude I hope you show up at the RISC-5 and talk about that a little bit tomorrow for sure and I think that it is simple because the example itself is work out of all of the bugs right okay that's cool I did not know you could do that with stuff that's in Debian right now so I'm actually quite excited to hear more about that okay I will take the actually I forgot to bring it here and just show you right away yeah that's quite okay well there's a RISC-5 buff sometime tomorrow I think or no it's Saturday sorry it's on Saturday and if you if somebody is not going to be here and has RISC-5 things to talk about you know feel free to come find me because RISC-5 is something I find quite exciting and would love to do more with okay time wise I think we're getting relatively close to the end of the time that was allocated you've got one more thing I want to throw out I mean I'm happy to hang around but I know the video folks would like to wrap up here in another minute or so I just want to mention that there is a new electronic simulator package Simul IDE which is most appropriate for educational purposes okay so you can check it out I haven't seen it okay thanks for letting us know what's the name of it again Simul IDE Simul IDE S-I-M-U-L-I-D-E got it excellent thanks for letting us know about that okay with well with all with that thank you all very much for your time and your attention


The next crypto bull market is likely to kick off as soon as next year without preparation you risk missing out on this chance or worse losing a lot of money. In this video I've got your back. I'll explain how to prepare for the next crypto bull run in five simple steps. Plus we'll have veteran trader Eric Crown dropping some knowledge. Before we dive in I want to stress that this video was made exclusively for educational purposes and does not constitute financial advice. I'm Giovanni, your host. Let's get into it. First things first. How do we even know if the bull market will happen next year? The truth is we can't be sure. But if we look at bitcoin's past performance it seems pretty likely. Previous crypto bull markets followed a four-year cycle. They usually kick off with the bitcoin halving event where the supply of new bitcoins being created gets cut in half. The next halving is said to happen sometime next spring and could be a major catalyst for the next crypto bull market. Besides the halving there is another potential catalyst to consider. The approval of a spot bitcoin ETF could spark increased demand from institutional investors. Now assuming this cycle unfolds as expected we need to understand where we are in it. The low point of the last crypto bear market was in November 2022 marked by the FTX collapse. Since then the price of bitcoin has surged by over 100 percent which many believe is a sign that the bull market might already be underway. However professional trader Eric Crown has a different view. This would still be sort of the pre-having rally that bitcoin's in the midst of right now. I think that the overwhelming majority of this rally is likely done. I think what's maybe a little more reasonable is bitcoin puts in one more explosive move into the low forty thousand dollar territory and then we spend the rest of the next you know I would say three to six months playing out of sideways and downside move. If Eric's assessment is proved correct it's good news because it suggests it's still early for you to join the market before the actual bull run starts. Typically that occurs in the months following the bitcoin halving. If history repeats itself we can expect the most significant movements to happen in the second half of 2024 or during 2025. So how far could bitcoin go in the next big jump? Over time the gains in each bull market have been decreasing. That is a natural consequence of bitcoin maturing as an asset. In 2017 it went from about one thousand dollars to just below twenty thousand dollars which is 20x. In 2020-2021 it moved from ten thousand dollars to just below seventy thousand dollars which is seven x. Predictions suggest this time we might see a three x four x increase possibly taking prices beyond a hundred thousand dollars. Now that we got a sense of where we are in the market cycle let's pick our crypto portfolio. I think every good crypto portfolio should include bitcoin and Ethereum. They are the most trusted cryptos and have been around for a while making them the safest choices. But keep in mind they are unlikely to increase tenfold or a hundredfold. The chance for the biggest gains is in smaller altcoins. Many of them could shoot up but the downside is they might crash hard so be careful. To figure out how much an altcoin can grow during a bull market look at its market cap. Smaller market caps mean the coin's price can move more easily in both directions. So the percentage of smaller altcoins in your crypto portfolio depends on how much risk you are comfortable with. I would do probably 70 to 80 percent bitcoin, 10 to 15 percent Ethereum and then the rest could kind of gamble on altcoins and maybe one of them you know goes absolutely insane. When it comes to alts your choices should align with the crypto sector that excites you whether it's gaming, DeFi, meme coins or NFTs. My advice is simple do your own research and be aware of the risks. Crypto bull markets attract hackers and scammers looking to snatch people's funds. That is why before jumping into the bull market you must set up a safe way to store your cryptocurrency. When you invest in crypto it's on you to keep your money secure you become your own bank. The safest move is to take control of your crypto by using a cold wallet. Don't keep your crypto on an exchange. Learn from the recent bear market if a crypto exchange runs into trouble getting your money back might be really hard maybe even impossible. So only use exchanges for buying and selling not for holding on to your crypto for the long term. Without a solid strategy you could end up losing money even in a bull market. A simple and safe strategy is called DCA or dollar cost averaging. It means buying a certain amount of crypto regularly like every month or week. This is good for people with limited money to invest all at once or who don't want to keep track of the market every day. Whatever plan you go for having one is super important by sticking to your strategy you avoid getting swept up in FOMO or the fear of missing out. FOMO is a big reason why people make impulsive decisions and end up losing their gains. Social media are a major source of FOMO so be aware of that. Understand that when you get tied into a lot of these social media channels they they are incentivized to play with your emotions. When you start to feel yourself feeling really like you're missing out really like you need again this next thing because it can be the next Bitcoin or whatever it's probably not. It's best to really tune out and tune down the social media sphere during these times because it can usually lead you more straight than lead you closer to the point. And lastly always keep in mind the golden rule of crypto investing. Never invest money that you cannot afford to lose. In the realm of crypto markets are unpredictable and black swan events are always a possibility. At the end of the day the market owes you nothing. The entitlement that we deserve x y and z as far as the market goes because you sat through a bear market is just it's just asinine it doesn't exist the market does not care the market doesn't love you it also doesn't hate you it just is what it is. Remember in the world of cryptocurrency investing the ultimate goal is to take profits at some point during a bull market many fall into the trap of holding onto their position for too long driven by greed only to lose everything in the inevitable downturn. The gains you see on the charts are just numbers until you lock them in by selling crypto for fiat or stablecoins. That is why having an exit strategy becomes essential it could be a predetermined price target or a set percentage of profit that you commit to for instance you might aim to increase your initial investment by 30 percent 50 percent or even 100 percent you don't have to sell everything at once consider a gradual approach like selling 25 percent at one price target and another 30 percent at a different price and so on. Also don't forget to set up similar price targets for a potential market downturn these are called stop losses it's also a good idea to have a clear purpose for your gains whether it's buying a car or making a real estate investment having a goal can guide your decision on when to cash out again stick to the plan in the volatile world of crypto discipline is your best ally and that wraps up today's video guys i hope you are now feeling more confident about navigating the upcoming crypto bull market if you found our insights valuable a thumbs up and a subscription to our channel would mean a lot i'm Giovanni your host thanks for watching and i'll catch you in the next video


All right, so we have an interesting little question to ask everyone. Is Six Flags Great Adventure getting a coaster in 2019? A lot of people don't have that high of hopes for Great Adventure getting a coaster, but we are starting to see evidence that this may be one of the Six Flags parks that are getting a coaster. In fact, is this one of the Six Flags parks getting a custom coaster? Or is it just going to get a copy and paste coaster? That is a big question for 2019 at Six Flags Great Adventure. In fact, that's a big question for a lot of the Six Flags parks. And we're going to dive in a little more into which parks could be getting customs and which parks won't get customs. And then also which parks are going to get a coaster and which parks aren't. So in our first Six Flags park, we're going to talk about Great Adventure because so far they actually have the most signs of construction next to Six Flags Magic Mountain. In fact, we have objects showing up that resemble that to parks like Canada's Wonderland and Carolin's. We have a crane, a heavy duty crane designed for lifting track off of flatbeds and lifting support columns and bringing them to the construction site that showed up at Six Flags Great Adventure. This could be a good sign, it could be nothing. It could just be other construction activity but we're also seeing markers around the park. So I'm going to leave this question up to you guys and for you to decide, do you think Great Adventure is one of the parks getting a custom coaster or even a coaster in general? We could be a giant discovery. It could be a, I mean, an RMC Raptor. We're going to see a couple of those, I think, in our announcements for Six Flags or it even could just be a copy and paste attraction like other Six Flags parks. It's up in the air and it's very hard to figure out what Six Flags parks are going to be announcing on August 30th. They are making some pretty bold statements on some of their posts and websites claiming that so far on the announcements announced for 2019, Six Flags is going to blow it out of the water, something along those lines. Now that's a really big bold statement. That's a big statement coming from Six Flags in general. I'm left a little skeptical on if that's going to be true or not because Six Flags has a tendency to announce these copy and paste attractions. I will say the giant discoveries are really impressive. The Raptor is a very impressive attraction. So it's not that bold but with that bold of a statement, I'm actually predicting Six Flags may be dipping their toes back into custom coasters and maybe Six Flags Great Adventure and Magic Mountain are going to be like the start of that other than RMCs. What do you guys think? I want to hear from you down below. Which Six Flags parks do you think are going to get a custom coaster and is it going to be great adventure? Anyways, hopefully you enjoyed this video. Give it a like, subscribe if you haven't and share this video for others to enjoy. Have a good one.


Hi everyone! Before we begin this video today, we just want to say thank you for helping us reach the big 6 zeros and over 70 million views. We will continue to do our best to provide consistent quality videos. Our vision is to make psychology accessible for everyone, at the same time as raising awareness on mental health. Hope you guys continue to support us! We also now have a Patreon launch to put more money back into our content, team members, and outreaching initiatives. Stick around for the end of the video to see how you can be involved. And without further ado, let's get right to it. Pop artist Andy Warhol states, people should fall in love with their eyes closed. In this quote, he's referring to the magic people feel when they start to mean something to one another. It sounds ideal and spectacular. But what if the person we fall for isn't who we think they are? That's when it's important to keep our eyes open and watch out for what can put us in danger. Here are 7 early signs you may be in a toxic relationship. 1. Your partner has heavy ex baggage. Timing plays a major factor on relationships that can either make it or break it. If you find yourself constantly consoling your partner as they mourn over their ex, then it's a sign they haven't moved on yet. They need time to grieve and heal over the loss of their ex before they are ready to enter a relationship again. But when you're in love, it's easy to get hopeful and become blind to the fact that your partner isn't emotionally invested in you when their heart still belongs elsewhere. Ultimately, you'll end up being the one getting hurt. Recognize that your role isn't solely to be a shoulder to cry on. You deserve love just like anyone else, but you can't receive that if you're busy being someone's rebound. 2. Your partner often lies to you about nearly everything. There's no harm in telling an occasional white lie if it comes from a selfless place. But if you find your partner constantly telling you lies, even over small matters, then it's time to reevaluate how much you can trust them. A healthy relationship is built on honesty, understanding and open communication. But your partner is only holding you back from going in that direction if they choose not to tell you their true feelings and intentions. 3. Your partner love bombs you. Love bombing is a technique emotional manipulators use to get what they want. It involves offering you intense attention and bombarding you with many compliments. When your partner tries to win your heart over, they will purposely put you on a pedestal to make you feel reliant on them. They do this so they can be your only source you go to that makes you feel good about yourself. But this dangerously develops into a codependent relationship that makes it toxic for the both of you. In fact, we even made a video on the different types of emotional manipulation that you can check out later. 4. Your partner frequently monitors you. Checking in is important to make sure you and your partner are on the same page.  Examples of frequent monitoring include asking to see your text messages, phone calls and emails, and constantly calling or texting you throughout the day to ask where you are or what you're up to. This stems from insecurity and a need for them to feel in control, which leaves you very little room to breathe and have a life outside of your relationship, which is important to have in order to maintain your individuality. Before we move to the next point, we want to also thank our sponsor BetterHelp for making this video possible. BetterHelp is an affordable and reliable online counseling platform for everyone of all ages. If you're interested, we left a referral link in the video description below for you to use. 5. Your partner isolates you. If you always feel like you need to ask for permission before attending events with friends or to hang out with family, then your partner may be possessive. Although it's sweet if your partner is protective of you, there's a difference between being caring versus being clingy. Abusers have a tendency to isolate their partner to prevent others from helping them escape. They may also try to stir up drama between you and your family and friends so you no longer feel as close to them. This only helps them maintain their power and control over you. 6. Your partner blows hot and cold on you a lot. Abusers use the hot and cold technique in order to keep you on their leash. If your partner withdraws from you when you upset them, but comes running back to you at full speed after you've done something to make them happy, then this is their way of getting what they want. The hot and cold treatment acts as a reinforcement for you to behave by their own terms and regulations. This is how relationships turn into ownership instead of equal compromise. 7. You constantly find yourself starting over with your partner. Fighting is normal and expected in any relationship, but if you have a common pattern of starting over with your partner frequently, then maybe it's time to examine why. Giving up often has a negative connotation associated to it, but sometimes it's also the right choice. We usually hold on longer to something that's not working because we're afraid no one else will love us, but this is how your fears ruin your chances of finding something real. Love is always worth it if it means setting yourself free from the wrong people. Are you experiencing these signs? We want you to know that you're not alone and there are ways to seek help and safety. As you guys might have noticed, this week we've been focusing a lot on topics related to toxic dynamics. Do you want us to make more videos on toxic situations that haven't been covered yet? Please share your thoughts with us below. Also, don't forget to subscribe for more content from Psych2Go and check out our Patreon. Thanks for watching! If you want to see more, give this video a thumbs up or check out our Patreon. Thanks for watching!


Okay, first I would like to thank the organizer to give me an opportunity to present our work here. Today I'm going to be talking about our single molecule epistate for analyzing multiple tumor methalome sequencing data. The USC's on Hopkins team led by Peter Lea and Steve Bellin over last year have done the DNA methylation profile for about 10,000 samples, mainly by microarray platform. Today I'm going to be talking about a completely different platform, namely, Hosea known by suffice sequencing, which gives us the profile of 28 million single CPG with more sequence variation information. We complete the sequencing on 47 DCJ patient sample with on average 15-h sequencing per sample. And as you can see in the table here, we have a set of nine cancer types you can see in the table. Our group developing a method for identifying the recurrent, differentally methylated reasons, which I will refer DMR from now on across the multiple tumors based on the single molecule approach for the Hosea known by suffice sequencing. Hosea known by suffice sequencing offers a great but also challenging opportunity to test the tumor heterosanity is weak reflected in the by suffice converted sort rate. And you can see I have the example of three low side. Three low side consist of 8 CPG in the column here and X-ray represent a sort rate where you see the methylated CPG stay the same denoted by the red circle here whereas the un-methylated CPG was converted and denoted by the blue here. And if you just compute the red methylation, you're going to see all three low side have about 40% methylation. However, the nature of the data are very different as you can see. Amostanite group proposed a concept of epipolymorphism which measures the dynamic between the within read pattern in the set of the by suffice sequencing read. And you can see here the first low cost have no epipolymorphic because the read are the same. The second one have is highly polymorphic because the read are very different from each other whereas the first one have is somewhere in between. We propose to use epistate to summarize the difference between read by suffice sequencing pattern. You can see here in the first two low side we infer single epistate with different methylation levels and the first one we have two distinct epistate here. We use the method expectation maximization to learn the epistate mixtures which was successfully used to infer the allylic methylation previously. So when we have the epistate we are going to estimate the epistate frequencies for each individual sample and again using this example let's say we have a pair of colon samples one normal and one tumor. And if we pull the read we learn two epistate namely the epistate unfair and epistate beta here and you can see the epistate unfair is less methylated whereas the epistate beta is more methylated. The methods also give us the posterior probability of a read that being originated from either one of the two epistates and you can see here in the normal samples all the read are likely to be originated from the unmetallated epistate whereas most of the tumors read are from the methylated epistate. And then we compute the average of the probability we call it epistate frequencies and you can see here for the methylated epistate beta the normal sample have almost zero percent whereas the tumor sample have 83 percent. And then we use epistate frequency to identify the difference in methylated reasons. And here another example of two loci from six samples say from two TCO colons and lung here it cancer tie have one normal and two tumors. And using the epistate frequency we can identify the loci we have two epistate as the DMR loci. And the DMR reason can be the tumor specific epistate as you can see in the first locus because the methylated epistate only can be found in the tumor sample whereas the second locus is TCO specific epistate because the methylated epistate only found in the colon sample here. So in overview we develop a method called epistate that can pull the read from both normal and tumor sample. And then we use the window length of the read length like 200 ways to scan the whole genome. We ask whether this locus is have the two epistate or not and if so we determine whether it's tumor specific or TCO specific for further downstream analysis. And today I will present some of our results on the tumor specific analysis. First I want to present how we use epistate frequency to estimate the tumor purity. And here's one of the cancer specific loci we have. We have a locus of 170 base pair about 70 CPZ. And we infer two epistate the un-methylated epistate and methylated epistate you see here. And we found no methylated epistate in both leukocytes and osatine normals. And we look at two colon tumors as we saw the methylated epistate appear in the first colon tumor at the 76 percent whereas the second one have 30 percent. And in the whole genomes they have about 16,000 loci like that. And if we plot the scatter plot of the epistate frequency we will see three distinct cluster indicate either the loci is methylated in one of the two tumors or it can be methylated in both tumors. And if we plot the density plot it allows us to compute the mode of the frequency distribution. And from that we can compute we can estimate the tumor purity. For example the first colon tumor have about 80 percent and the second have about 40 percent purity. And in order to see whether we do a fair job we compare our result with absolute estimations. And as you can see here the acid is the estimation from our methods and the Y-acid is from absolute methods. And our result is highly correlated with the absolute estimation except for this sample which appear to have very few copy number of variation changes that may affect the accuracy of the absolute estimation. One of the advantages of our method is we can detect the epistate at very low frequencies. And here's one example I want to show you we estimate we inferred two epistates that locus only methylated in the colon sample. We have three colon samples here and this have 40 percent of the methylated epistate but the two last sample have very low namely 30 and 15 percent only 30 and 15 percent methylated epistate. And it have like almost no methylated epistate found in position normal as well as other tumor. The next and the last example I want to show you is the advantage of the sequencing approach over the array approach that we found a high amount of the DMR loci located at the distal element. And here one of the example we have 300 base pair locus we inferred two epistates we found no methylated epistate in both leukocytes and adjacent normals as well as in some of the tumors like colon here but we found the methylated epistate at the different frequencies in other tumors for example breast and endometrial sample. And we wonder where this locus is in the genome we look at the genome browser and we see this locus lie on 5,000 base pair upstream of the gene called SMAS3 and it's overlaid by the enrichment of the histone mark S3K27R situation which indicates this reason is active regulatory reasons. So it led us to check the activity the transcription activity of these genes where we found the nicely inverse correlation between the epistate frequency you can see in the eye assist here and the gene expression levels from RNA6 in the YR6 here 8.1 sample from 9 cancer ties which indicates these potentially enhanced reasons have player roles in regulating the function of this wind signal and cell cycle genes in a certain number of cancers. So it brings me to our summary we developed a single molecule epistate method for analyzing multiple hosinome bisulfide sequencing data and our methods can be applied to estimate the tumor purity as well as finding the interesting differentially methylated reasons such as regulatory reasons as the very low frequencies. And I would like to end my presentation by the acknowledgement to the people who are contributing to the work especially Ben, Peter and Huay and our work was sponsored by the TCJ grant and thank you for your attention. Thanks we have time for a question or two. I had a question when you're learning the epistates there's this you mentioned this EM expectation maximization step. Do you often find you'll converge to a you know a strong answer? Do you have to rerun this thing over and over again? Can you say a little bit about the method there? We when we run the EM we use the basic information contents to estimate the significance whether that locus have the two epistates or not and if it converts and then it has the because actually we run it for the we ask whether it have one epistate first and it will have the two epistates and we estimate its model using the BIC information and from that we will determine whether it have the two epistates or not. Do you find you have to rerun it though to get any different answers? Yeah, I mean we have the multiple starting solution and then we run it until it converts. Questions? Thanks Huay again, thanks.


Why am I in class learning past material when I could be searching through experiential Experiments. Yeah, find me on SoundCloud. My name is Kanye West. Yeah, can I have your autograph Kanye? Hi, my name is Jenna Falk here with Cal TV Entertainment I'm here on Sproul making a little arrangement. I'll ask these students to pick three words out of this very hat and freestyle wrap Let's hope they don't fall flat. You think you can do it up for the challenge? I've never rapped in my life.   Oh, no Drop me a beat. I can try my best Donald Trump is taking the dump cuz he says everything is fake news Freestyle what I I stutter when I speak Hey, my name's McCleet people get it wrong. They always say it's Mac Lin I'm always like, all right. All right.  All right I'm over here trying to get through haas.   That's running right there.   I'll make an exception. Okay, you have salty flame and lit. Let's see what you can do Yeah, a lot harder than it looks, huh?   Yeah, I hope we do in a well If we don't it'll all be it fine. Hey, hey swell. Yes Once again, my name is Jenna Falk here with Cal TV and has proven here today None of these Berkeley students are getting a free styling degree except for me Just kidding. I'm middle-aged.  Stay in college your whole life Okay, I think that's great. Thank you