Please wait...
Hm, now that I think of it, this happened to me a couple of years ago.
Hotshot wrote stuff in Python without any input from anyone else, to include failing to integrate it with the rest of the product. When I asked him about configuring his tool, he said, "Oh, just call this REST interface here."
"You realize no other part of our system does this, and we don't have the infrastructure to make that happen, right?"
That code is currently rotting in our git repo. We couldn't even move forward with it.
We do, however, have plans to write it again, but according to a dev process.
Hotshot wrote stuff in Python without any input from anyone else, to include failing to integrate it with the rest of the product. When I asked him about configuring his tool, he said, "Oh, just call this REST interface here."
That's called "Service Oriented Architecture" and HOW DARE YOU question the importance of putting that on his resume, even though it screwed up the entire project?
Oh, I'm too wise to allow someone to screw up an entire project if I'm responsible for that project.
He only managed to mess up his part.
I have all of my sessions set to handle resizes the old way (which is fine).
Guacamole has changed the way I use my computer. My main monitor is a 24" 1920x1200 (16:10) screen. It now has a browser maximized on it all day long.
I used to have to switch back and forth between the browser window and my terminal window. Now I've got HTML, SSH, RDP, and VNC in one contiguous set of tabs. And since I'm at 1920x1200, I can view a remote 1920x1080 screen without scaling it down, in those cases where the server won't size to the client's screen dimensions.
Text windows are 190x56, which is a *little* excessive, but not so much that I want to shrink them. Nobody writes code in 80 columns anymore, except maybe COBOL programmers.
Obviously this isn't going to transform everyone's workflow, but it's working great for me. Nearly everything I do is on a remote computer somewhere.
Guacamole has changed the way I use my computer. My main monitor is a 24" 1920x1200 (16:10) screen. It now has a browser maximized on it all day long.
I used to have to switch back and forth between the browser window and my terminal window. Now I've got HTML, SSH, RDP, and VNC in one contiguous set of tabs. And since I'm at 1920x1200, I can view a remote 1920x1080 screen without scaling it down, in those cases where the server won't size to the client's screen dimensions.
Text windows are 190x56, which is a *little* excessive, but not so much that I want to shrink them. Nobody writes code in 80 columns anymore, except maybe COBOL programmers.
Obviously this isn't going to transform everyone's workflow, but it's working great for me. Nearly everything I do is on a remote computer somewhere.
Ok, I see ... it's Platform-as-a-Service renamed to sound trendy so the people
who write code while sitting in Starfucks will be attracted to it. Write
to the provider's API and it runs wherever the hell they want it to instead
of on a dedicated virtual machine.
Fuck that noise. I'll write code that runs on computers.
Fuck that noise. I'll write code that runs on computers.
OMFG...
https://wiki.archlinux.org/index.php/OpenRC
HOW MANY FUCKING SERVICE MANAGERS DOES LINUX REQUIRE?
Whenever someone else thinks, "None of these really start my services how I'd like them started... I think I'll make another one," an angel has its wings ripped uncermoniously out of their torso in agony.
Just Fucking Stop It Already.
Oh, that's a gem:
"Note that when openrc-init is used, it must be paired with openrc-shutdown, and *not* the shutdown or reboot commands from other packages, otherwise you will encounter errors."
So not only have you introduced yet another monstrosity for people maintaining setups to ensure, but you're imposing on system administrators who have developed muscle memory for shutdown/reboot a need to remember the oh-so-much-shorter command "openrc-shutdown" because your system is that much better.
Wankers.
Serverless describes individual subroutines as a service (no, I'm not joking;
look this shit up). The idea being that you don't write code with servers
in them, a special container runs them for you (*cough* EJB *cough), and provides
the linkage for parameters and returning results (*cough* RPC *cough*). Furthermore,
these "serverless" instances are intended to be stateless, for maximum scalability
(both up and out).
In short, it's a jucking foke. This has all been done before, serverless imposes MMAASSSSIIVVEE communications overheads, et. al. which are conveniently hidden behind the wide fan-outs it enables. It's perhaps a good model for any form of computation that depends on pipelining (since 99% of your effort will be in network queueing), but beyond that, it's a horrible new fad that needs to, quite literally, die in a car fire.
Oh, and if you do find yourself working with workloads that benefit greatly from wide fan-out scalability and is inherently amenable to pipelined processing, fuck this shit, and look into FPGA coprocessing instead. You'll consume substantially fewer watts to get the same result, and it'll be markedly faster. But don't tell the Si-Valley folks this, I don't want to be branded a traitor.
In short, it's a jucking foke. This has all been done before, serverless imposes MMAASSSSIIVVEE communications overheads, et. al. which are conveniently hidden behind the wide fan-outs it enables. It's perhaps a good model for any form of computation that depends on pipelining (since 99% of your effort will be in network queueing), but beyond that, it's a horrible new fad that needs to, quite literally, die in a car fire.
Oh, and if you do find yourself working with workloads that benefit greatly from wide fan-out scalability and is inherently amenable to pipelined processing, fuck this shit, and look into FPGA coprocessing instead. You'll consume substantially fewer watts to get the same result, and it'll be markedly faster. But don't tell the Si-Valley folks this, I don't want to be branded a traitor.
OpenRC is probably the dependency-based system I had in mind that predated
systemd. I remember trying gentoo years before 2007, and some of this rings
a bell from back then. It might be a new name, but the framework guts must
have existed back then.
Yep, WIkipedia confirmed it -- initial release of OpenRC as a distinct product
is in 2007, systemd came only in 2010. So, really, you should be outraged
at systemd for being "yet another" init.
It seems as if there was a largely held consensus that sysvinit was aging and had become a liability, since so many different parties have built replacements for it. I guess I'm one of those heretic type people, because I actually like systemd. So I simply hope that eventually we reach a point where systemd becomes the category-killer sysvinit replacement and we can count on it being there. For all practical purposes, ISV's who actually produce software instead of rolling craft beer distributions of Linux in their spare time, only care about Fedora (CentOS, Red Hat) and Debian (Ubuntu). Since both of those lines have already moved to systemd, the debate is essentially over.
Also, I still consider Pluto a real planet.
I kinda don't care what system is used, as long as I don't have to write a ridiculous amount of code to cover all of them.