Before you do anything else, if you haven't already, I'd advice you to see your physician and explain your situation - at the very least have a basic set of blood tests done. Vitamin B or D deficiencies, for instance, can both adversely affect concentration.
If that's already covered, is taking an extended break a possibility? I was having similar difficulties, and I'm much more productive again after a 2 month absence.
What _really really_ sucks is well-defined, reasonable, meticulously documented formats where all in-the-wild implementations stray from the spec in different ways :-/
byuu posted an article on his blog (byuu.org) just two days ago. His emulator was called bsnes, not bzsnes, maybe that's the source of confusion? bsnes has now evolved into higan, so that might also be why you can't find it. The higan source is mirrored on gitlab: https://gitlab.com/higan/higan
edit: sorry, wasn't aware of the (april fools) bzsnes release, realise now that I'm probably more confused than you are.
I found his comment relevant and interesting enough, and judging by his posting history SmartOS is far from the only thing he comments about. It certainly added more to the discussion than yours did.
An incredibly large percentage of Annatar's posting history is a misunderstanding of something about GNU/Linux, followed by a pitch about SmartOS. It's not the only thing they talk a out, but it's the only posts that stick in my mind. While I find the history of free operating systems fascinating, it's quite dismissive to pretend that all possible problems that GNU/Linux faces today were solved "10+ years ago by experts in the problem domain".
Misunderstanding? I develop on Linux day in and day out. Care to qualify that assertion?
it's quite dismissive to pretend that all possible problems that GNU/Linux faces today were solved "10+ years ago by experts in the problem domain".
As one of the principal kernel engineers of the FireEngine, yeah I think Sunay is the expert in the problem domain, having invented parallel enqueuing or what he terms "fanout", and Radia Perlman, who I believe collaborated with him on it invented the spanning tree protocol. If that doesn't make them the subject matter experts in the TCP/IP stack domain, then I have nothing more to add. And yes, some or the problems GNU/Linux is hitting today have been solved on Solaris more than ten, others more than twenty years ago. Solaris had large enterprises as paying customers throughout the nineties of the past century, and those customers both demanded and paid huge sums of money to have these types of problems solved, so in some cases illumos has up to 25 years of a headstart, and by the time GNU/Linux catches up, illumos will already be ahead, as the development is not standing still and it has professional kernel engineers working on the code base.
The most recent example I can think of is you posting about containers on GNU/Linux[1], claiming that they were implemented primarily using cgroups (and that the main purpose was resource restrictions). That is not true, and hasn't been true for a long time (if ever). Yes, the very first upstream "container" primitive was cgroups -- but that was very quickly replaced with namespaces and cgroups took on the resource restriction role. What most people call "containers" was always about virtualization (ie isolation), and the isolation primitive in the Linux kernel is namespaces.
There are almost certainly more examples, but I don't feel like going through any more of your comment history at the moment.
> And yes, some or the problems GNU/Linux is hitting today have been solved on Solaris more than ten, others more than twenty years ago.
Believe it or not, but constraints have changed in the past 20 years. I'm not saying that illumos doesn't have awesome technology (it does), but it is not a panacea. I get it, you're an advocate for alternative free operating systems. Good for you. Solaris does have a 25 year headstart -- on solving problems 25 years old. Modern computing has many more problems that weren't even concieved 25 years ago (cloud and distributed computing being the main ones, as well as embedded devices which is something that Solaris can't put a candle to GNU/Linux on). So it's very dismissive to claim that Solaris has solved all problems that may face GNU/Linux. Both operating systems have problems they need to fix.
> and it has professional kernel engineers working on the code base
since containers in Solaris existed before cgroups and before the entire Linux hype, and you specifically adress my "misunderstanding" (of hype), you compel me to correct on terminology:
containers are resource constraints, while technology like LXC and OpenVZ provide the lightweight virtualization and isolation, a very important distinction (full virtualization is achieved via XEN and KVM on GNU/Linux). Conceptually, as a resource constraint, containers are in that sense the same in Solaris as they are in Linux, with vastly different mechanism implementations, but neither provide isolation.
Again, and I corrected you on this before (this happens to be my problem domain), what you think of as containers are lightweight virtual machines, as zones in Solaris and LXC / OpenVZ in Linux, and equating cgroups and namespaces with a lightweight virtual machine technology is conflating two different things.
If you should have the inclination to point out my other "misunderstandings" of Linux, an operating system I very heavily use, develop on, and engineer for, I would be interested to learn of them.
> So does Linux, I'm missing your point here.
If they exist, I have not heard of them, read about them, or met them yet; at any rate, since Linux has so many architectural and performance problems, again I am compelled to conclude that those "Linux kernel engineers" are not of the same caliber as the ones working on BSD and illumos kernels. That an operating system, after almost twenty years of massive investment and literally armies of programmers still cannot get basic things like startup (init.d/systemd/other variants of startup), shutdown (trying to flush a filesystem buffer to an unmounted filesystem), or even TCP/IP performance right tells me it is missing kernel engineers. Enthusiasts and volunteers tinkering with the kernel do not professional kernel engineers make, as is evident by this entire topic of whether to bypass the kernel's TCP/IP stack with one's own implementation, because the stack cannot deliver sufficient performance. That is what one can call damning evidence, no matter how one slices or dices it.
> There is no isolation with cgroups in Linux
> containers are resource constraints
I'm going to say this one more time:
Linux containers use namespaces as the primary isolation mechanism -- NOT cgroups. You can create containers without cgroups. This happens to be my problem space too, and you're not helping by spreading ignorance.
> equating cgroups and namespaces with a lightweight virtual machine technology is conflating two different things.
Finally you mention namespaces. Who mentioned "lightweight vritual machines"? Namespaces are just tags for a process that are used to scope operations to provide isolation. Cgroups are different tags used to provide resource constraints. Just because people use containers in that way at the moment doesn't make the underlying technology just about that.
> an operating system I very heavily use, develop on, and engineer for, I would be interested to learn of them.
Arrogance is not an endearing quality.
> If they exist, I have not heard of them
We can play that game all day. I don't care who you have and haven't heard of, Linux has talented kernel engineers as evidenced by the fact that Linux is widely used for production deployments. You might not agree with what has been built, but you can't deny that it does exist and is being used to power production systems. Please calm down on the saltiness, sodium is bad for your health.
Another excellent C++ book that does this "the right way around" is "A C++ Primer" by Lippman, Lajoie & Moo. The 5th edition is rewritten for C++11. Disclaimer: I've only used the 4th edition.
