We're sorry but this page doesn't work properly without JavaScript enabled. Please enable it to continue.
Feedback

FireCRaCer: The Best Of Both Worlds

00:00

Formal Metadata

Title
FireCRaCer: The Best Of Both Worlds
Title of Series
Number of Parts
542
Author
License
CC Attribution 2.0 Belgium:
You are free to use, adapt and copy, distribute and transmit the work or content in adapted or unchanged form for any legal purpose as long as the work is attributed to the author in the manner specified by the author or licensor.
Identifiers
Publisher
Release Date
Language

Content Metadata

Subject Area
Genre
Abstract
CRaC (Coordinated Restore at Checkpoint) is an OpenJDK project for the coordination of Java applications at checkpoints which leverages the CRIU (Checkpoint/Restore In Userspace) library for process snapshotting. This talk will briefly introduce Firecracker, an open source virtualization technology based on KVM, explain how CRaC can be used with it and compare it with CRIU. The second part of the talk will introduce some new tools based on Userfaultfd and DAMON which allow fine grained analysis of of the JVM's memory access patterns during restore and end with a discussion on how the JVM could be optimized to improve them.
Level (video gaming)Multiplication signDisk read-and-write headDiagramComputer animation
EmailGraph coloringData managementMeasurementProduct (business)1 (number)Virtual machineProjective planeMereologyBitData structureSoftwareCombinational logicDigitizingCASE <Informatik>Bus (computing)AreaComputer animation
Standard deviationSlide ruleLevel (video gaming)Computer animation
EmailFreewareCodeDatabaseData managementVirtual machineLevel (video gaming)Multiplication signComputer animation
Perspective (visual)Multiplication signData managementSpacetimePerspective (visual)SoftwareExpressionComputer animation
Software maintenanceElectronic visual displayComputer hardwareProjective planeSoftware developerComputer hardwareCore dumpCodeVirtual machineMobile appData managementGraphical user interfaceCuboidSlide ruleStability theorySoftwareLine (geometry)Module (mathematics)Electronic mailing listCompilerFront and back endsFormal languageServer (computing)Video gameSet (mathematics)Endliche ModelltheorieOnline helpMultiplication signMetreDifferent (Kate Ryan album)CASE <Informatik>QuicksortComputer animation
Point (geometry)Server (computing)Virtual machineNumberCore dumpInterface (computing)Numbering schemePhysical systemProcess (computing)Matrix (mathematics)Different (Kate Ryan album)Goodness of fitComputer fileConfiguration spaceMultiplication signAuthorizationData loggerInformationSoftware testingSoftware engineeringMereologyUniform resource locatorModulare ProgrammierungData modelData managementCircle2 (number)Gastropod shellSelf-organizationFreewareSoftware developerProjective planeAuthenticationBulletin board systemMetric systemPresentation of a groupPlotterBuildingSpacetimePrice indexCausalitySummierbarkeitQuicksortEndliche ModelltheorieRight angleBlock (periodic table)Data structureDigital electronicsWebsiteChainSoftwareProfil (magazine)Semiconductor memoryComputer animation
Program flowchart
Transcript: English(auto-generated)
The stage is yours. Thank you. I'm here for a quite short time. My head may not have switched completely to English. So if that happens, maybe someone of the audience can help me out. So my talk is about fat access.
And then the last time I had a talk, after the talk, people said to me, you need to tell more about fat access. So that's what I'll be doing. And first things first, wake up, some color. What is fat access? For fat access, I'm a manager of a workshop
in Berlin in a university. And some people call me the product owner or the father of fat access. It's not really the case. I'll tell later why. Switching machines in a workshop sounds easy.
You switch one bit on, the machine is on. Switch one bit off, reset the bit, and the machine is off. But it's not that easy. First thing, why do we need to switch off machines? In a workshop, you have two kinds of machines, the one who tear off parts of the body of the users
if they do not know how to use the machine. And the not so interesting ones who are not hurting people. And there are two kinds of people in your workshop. There are the ones who know how to clean up their place
after they leave the workshop. And there are the ones who leave the mess to you. And if you need to get along with this combination of people and machines, you need to get some structure in the workshop. And I'm the only one working aesthetically in that workshop.
So I'm not enough people to get structure. And 30 people are using the workshop. So I need support. And I need the wonder of digitalization. So I do not like good luck, have fun. That's why we began to work in fab access in 2019.
I won't read all of that. These are requirements which are coming into software if you want to switch on machines and off machines. That's why it wasn't that easy. And next thing is we saw a lot of projects
who began working in that area. But when we realized there are a lot of these projects,
I think most of you know that XKCD, we tried to avoid that by becoming modular and switch some slides back and getting more than works for me. Technology readiness level nine, maybe some of you know what that means.
And that's one more thing we wanted to reach. We wanted to reach the technical gruntlang for federation in the future. Not right now. We'll get there in September of this year maybe. That's what is fab access.
In the last talk, they talked about what is fab access. That's it. We have machines. We have users. And the machines can be switched on by the user, not by the manager of the fab lab. But the manager of the fab lab has the user database and the machine database and can
say who was allowed to switch on which machine. And in the next step here, can see which one of the users switched on which machine in the last time. And that's it. We do not follow our users or make surveillance of what they are doing.
We want to know who left that mess. And that's it. There are in the time. Well, there are some perspectives which need to be implemented in such software. First is the workspace manager.
I won't read because time is running. For the workspace manager, the software we are implementing should fit into his workspace and not press his workspace into our software. That's one of the most important things for us. And for the user, it should be easy to use.
And that's as fast and clear as at a, no, English word's missing. So that's how we approached to a, well, you know what I mean.
Sorry. How to consider the wishes of the Fab Lab manager. Yes, of me. I think it's too much text for nine minutes.
Are there some questions for that slide? I think the most important is the last one. Attaching new machines is easy. Well, patent and bash because we are not able to implement as a project each and every machine in each and every workshop. So we need to enable the workshop users
and managers to work as a community project. In the middle, there is GUI would be great. If there is anyone in the audience who is willing and able to build a GUI which takes machines and throws out tomelet and all files, feel free.
That's some things in the back end that are important. It's written in Rust. So the language and the compiler guarantees some sort of stability.
And in between the back end and Rust, there is the Captain Proto API, which enables the guys who are not working in the back end and in the core of the server to get a stable API where they can throw against with Python or, I think, easier languages, which
are there are more people who can write code in these languages. We have two to three core developers who are having a guarantee a very, very stable API.
And this is also important because the Fab Lab Manager does not want to take care of software updates.
They should happen without any effort. Accessibility is for the users. The app which we have, I showed in the slides before, should be really accessible for the users because if you have a workshop, it doesn't help you. A third of your users say, sorry, I can't access the app.
I can't use your workshop machines. And the last line there is one more step to accessibility because not everyone has a mobile phone, and not everyone wants to take his mobile phone
and get the app. And when he wants to just use a machine, so NFC is a thing in that case. Well, supported hardware devices out of the box. This is what the core developers have been working at right now.
And the accessibility, it are not only the core developers developing modules for Fab Access. That's where the community comes in. I think the list on the top will grow with time,
but the developers have an eye on stability, so it's not growing that fast as the community wishes. So it gives community unrights. I don't know the English word, sorry. That's where we are right now. We're in the beta, and I think at the beginning of March,
there's a deadline for 1.0, which will be the first release which can be used by a workspace without having software engineering
guys in the background. These are targets which will be addressed in 1.0 of my connectors, which by a lot of guys in the community, as most of the German workspaces in the Verbünde of Neuwerkstätten
switched to a key cloak in the background. I'm good on time. And the federation, I already talked to the people of Matrix, and I think there will be some interfaces
between Fab Access and Matrix to a realized federation. So coming to the end of the presentation, we are a team. The most important are the community members. We have 64, a number growing. We have a community manager. Thank you.
We have four people in Berlin, first of the three core developers, then me, sorry, and one guy in Bohol who is doing a really good job in alpha testing and documentation because if developers create documentation, it's better when there is someone outside
of the developer circle. Nobody in the team does anything with blockchain. These are organizations who supported us and are carrying the project. And yes, the lower even spent some amounts of money.
Thank you. And these are the URLs you'll need to get involved and give it a try. So I think we have three minutes. Are there questions? Yeah.
Do you guys think about interoperating with all the existing authorization schemes like free IDA, for example? Yes, of course. And right now, they are implementing a summer, and there will be many, many more. It's part of the modular design of FABXS
because we do not want to press you into what we are using. If there are authentication systems which are in the market, we will implement them one after the other. But if you have wishes, feel free to talk to us.
But how do you stop people from just unplugging the shell and all that? Very good question. Thank you. You are not able to solve social problems with technology. Unplugging plugs which switch on and off the machines, for me, it's a part of a social problem,
but there is a technical aspect. Of course, the shellies say, I am here, I'm here, I'm here. They have a heartbeat. And if that heartbeat is away, the core of FABXS realizes all that shelly is unplugged. So it's a technical and social problem.
Inside the kernel, yes. Inside the backend, yes. It throws out in the normal configuration into the memory, so it's gone in the time it's thrown out a log file. And if you need to follow what your users are doing,
then you may take that log file and configure FABXS, give me the log file, and push that log file to ERP systems or whatever you want. But that's not in the scope of FABXS. Any more questions? One and a half minutes?
Yeah? Do you have the possibility to also get a signal from the machine to say it's working or it's voicing? Next good question. Thank you. It depends. It's a, sorry. Sometimes if the information from the machine
is important for FABXS to switch on and off machines, then we're taking the data into FABXS. Normally, when there are data from the machine which are not needed to switch on and off machines, because the core point of FABXS is switching on and off machines, and that's what we are doing good.
If there are any other data in our package, there is a MQTT server, and it may be far-righted by the MQTT server. And FABXS does not need that data, yeah? 37 seconds.
But you wrote down, like, I used it for like one minute and 30 seconds. Yeah. This is something you can do with the log file, which is coming out of FABXS and your own software. You writing, or maybe ODOA, or any other ERP system
which needs to be filled with structured data from that log file. No, we are not an ERP system. We are not gaining money from people using our machines. That's in the scope of different software packages.
Yeah? Thanks.