@cartman82 I can confirm that I substantially outdo Google. I run over a trillion containers per day on a few servers as such: while true docker run hello-world * cores * 10. I was talking to my friend at google though about this and he talked about this even more popular technology called "processes". Apparently Google runs these ten thousand times more than then run docker containers! What's more is that apparently there's this even more popular tech called threads. Apparently Google runs yet fifty times more of those than they do processes! Even more impressive are these things called "subroutines". Apparently Google runs a thousand times more these than threads! If that's not impressive however, I've heard of the ultimate new technology called "instructions". Apparently Google runs a thousand times more of these than even subroutines! Obviously docker is very low down in the food chain and people ought simply be using instructions instead.
First Last
@First Last
Best posts made by First Last
-
RE: WTF Bites
-
RE: On the right to rant.
I've been quite a long time heavy user of Debby but I have to be honest it is rant worthy. First I liked that Debby (ironically early on was beneficial having a relatively small simple footprint compared to some more ambitious distros) and its fork Ubuntu tended to have a lot of packages compared to things like stock Centos. After a while though I noticed quality issues. Then I ended up getting into packaging and this is where debian really reveals itself. Centos is dead simple most of the time. It tries not to deviate too much away from the make scripts packages come with.
There are exceptions to that but in general if I want to make a package in Centos it's just one little combined config and build script and a few commands to get it built and in a repo. Adding a repo is easy as well with very little to think about. Debian on the other hand, there's this skeleton with mystic files everywhere, a hundred ways to skin a cat and things like two convoluted ways or adding patches. I think the worst of it though is all the extras. Quite often when people package things for Debby, you have too much contribution (for more you contribute, the more you have to contribute, maintenance). All these extra scripts and reconfiguration away from defaults as well as random patches from all over the place get pulled in (and not necessarily pushed upstream). In short, you ask for a skeleton package in Debian and you get a mass grave instead. It then also turns out packages are massively modded so something as simple as updating a package yourself with your own repo for when you need that (since Debby freezes version) becomes a major undertaking if you want to reuse the original source package from Debby.
As much as I might depend on Debby, in essence, when I look at these scripts and things which are all superfluous and bulbous (sometimes of a curious level of quality or convention), Debby is one big enormous rant, except it's written in things like bash and python. Rather than being in yur mailing list or forum it's in yur packages, file system, executables, climbing in yur windows, etc.
-
RE: When being configurable is more important than being useful
Next time someone leaves their Ubuntu desktop unlocked I know what I'm going to do.
Latest posts made by First Last
-
RE: When being configurable is more important than being useful
Next time someone leaves their Ubuntu desktop unlocked I know what I'm going to do.
-
RE: On the right to rant.
I've been quite a long time heavy user of Debby but I have to be honest it is rant worthy. First I liked that Debby (ironically early on was beneficial having a relatively small simple footprint compared to some more ambitious distros) and its fork Ubuntu tended to have a lot of packages compared to things like stock Centos. After a while though I noticed quality issues. Then I ended up getting into packaging and this is where debian really reveals itself. Centos is dead simple most of the time. It tries not to deviate too much away from the make scripts packages come with.
There are exceptions to that but in general if I want to make a package in Centos it's just one little combined config and build script and a few commands to get it built and in a repo. Adding a repo is easy as well with very little to think about. Debian on the other hand, there's this skeleton with mystic files everywhere, a hundred ways to skin a cat and things like two convoluted ways or adding patches. I think the worst of it though is all the extras. Quite often when people package things for Debby, you have too much contribution (for more you contribute, the more you have to contribute, maintenance). All these extra scripts and reconfiguration away from defaults as well as random patches from all over the place get pulled in (and not necessarily pushed upstream). In short, you ask for a skeleton package in Debian and you get a mass grave instead. It then also turns out packages are massively modded so something as simple as updating a package yourself with your own repo for when you need that (since Debby freezes version) becomes a major undertaking if you want to reuse the original source package from Debby.
As much as I might depend on Debby, in essence, when I look at these scripts and things which are all superfluous and bulbous (sometimes of a curious level of quality or convention), Debby is one big enormous rant, except it's written in things like bash and python. Rather than being in yur mailing list or forum it's in yur packages, file system, executables, climbing in yur windows, etc.
-
RE: WTF Bites
@cartman82 I can confirm that I substantially outdo Google. I run over a trillion containers per day on a few servers as such: while true docker run hello-world * cores * 10. I was talking to my friend at google though about this and he talked about this even more popular technology called "processes". Apparently Google runs these ten thousand times more than then run docker containers! What's more is that apparently there's this even more popular tech called threads. Apparently Google runs yet fifty times more of those than they do processes! Even more impressive are these things called "subroutines". Apparently Google runs a thousand times more these than threads! If that's not impressive however, I've heard of the ultimate new technology called "instructions". Apparently Google runs a thousand times more of these than even subroutines! Obviously docker is very low down in the food chain and people ought simply be using instructions instead.