Everything said in this post is based on my half-understanding of how memory works, especially in Linux. There are certainly going to be parts in this post that are misunderstood by me. Don’t rely on this post for your homework and take everything in this post with a grain of salt. However, I hope to continue to refine the content in this post as I understand more about how a computer works. Consider this as a disclaimer. That said, let’s begin!
In my university, we mostly have only-Windows computers. What I mean by “only-windows computers” that the computers have Windows as the only operating system installed on them. Now, I always like to be accompanied by a terminal with everything I do (even writing this post in a TUI on Linux) and avoid proprietary software whenever possible. By the way, cmder is a pretty good project that adds the missing flakes (like wget, curl, etc.) to the command-prompt but it doesn’t change the fact that Windows itself is still closed-source (atleast as of writing this). Me, being an avid supporter of open-source cannot back down here.
Synchronizing clocks of different computers in the order of milliseconds can be pretty daunting. This is what is mostly stopping me from doing same stuff on two different machines at the same time without huge latency issues, stuff that could get pretty interesting.
In the last post - I talked about how one can
share input event devices available as
/dev/input/event*. Lately, I’ve been also wanting to share my
MIDI keyboard (Yamaha P-45 Digital Piano) so that I can receive and send MIDI events to my Linux machine
without using a cable.
In Linux machines,
/dev/input/event* are special files known as devices files. These files act
as a middle man between an application software and the kernel to interact with the hardware input
devices connected to the system. To know what devices are connected to your system, run:
$ cat /proc/bus/input/devices ... I: Bus=0011 Vendor=0002 Product=0007 Version=01b1 N: Name="SynPS/2 Synaptics TouchPad" P: Phys=isa0060/serio1/input0 S: Sysfs=/devices/platform/i8042/serio1/input/input5 U: Uniq= H: Handlers=mouse0 event5 B: PROP=1 B: EV=b B: KEY=e520 xxxxx 0 0 0 0 B: ABS=66080001100xxxx ...
My christmas holidays have just begun and I’ve been trying to play some media files on Kodi. This blog post is mainly a result of frustruation where some media files just won’t play on two of my low-cost computing devices (Raspberry Pi 2 Model B and Amazon Fire TV Stick) and in hope that this blog post will be a good partner to me if someday I in the future decide to tinker further.
With my now four-year old Pi 2, I’ve noticed a static spark-like noise coming out from the 3.5mm audio jack for as far as I can remember. This noise wasn’t the kind of usual constant white noise buzzing from the speakers. Instead, my connected speakers would make a crackle noise at regular intervals and then remain perfectly noise-less for the remaining period. This periodic noise only appeared when the speakers were connected to the Pi and didn’t happen with any other device.
It’s that time of the year when students are supposed to submit their final evaluations. As Google expects students to put up their final reports somewhere in a stable location and as there is always a chance that I might mess up something on my blog, so I also made a Gist wrap up of this blog post of how we progressed in these few months and all the great stuff that happened in our community.
Oh, there we go! Time for GSoC’s pre-final blog post.
During this period, nothing big happened except we’re able to get merge a new Plasma subclass supposed to work with OpenPMD Datasets #500! It still isn’t very efficient to work with larger datasets and should rather be considered a prototype at the moment. It currently supports reading only mesh data from an HDF5. It also reads the complete record into memory, which is certain to cause problems with big datasets. In the real world, heavy datasets can go into dozens of GBs. In the future, we’re going to have to provide a way to read stuff directly from disk or provide someother way instead writing all of it to memory.
We’re currently working on developing a new Plasma subclass. It is supposed to read HDF5 files that are based on OpenPMD standard and we have a sort of prototype ready in #500. It should be ready to merge once we figure out how we are supposed to handle the example datasets for our tests. It probably isn’t a good idea to ship them with the main PlasmaPy codebase. I guess we’re going to settle downloading them on the fly when running our tests.
As we all (probably) know now, our Plasma factory implementation got finished much sooner than expected. So, I’ve been mostly lurking around since my last blog post adding features in our plasma pie, discovering bugs under our plasma bed, reviewing plasma requests, gazing at stars made of plasma, etc.
We’re mostly done with structuring our Plasma factory. The PR (#459) just got merged yesterday! I’d have to say we weren’t expecting this to work out this quickly.