notabot @ notabot @lemm.ee

Due to the impending lemm.ee shutdown I have migrated to notabot@piefed.soc

---

Read more

Posts

2

Comments

654

Joined

2 yr. ago

It is genuinely difficult to tell if the stories they link to are real or just hyperbolic parody. Even just skimming them I can feel the incoherent rage and desperate glee for vengeance billowing off of them. Anyone actually reading them seriously would inevitably end up getting swept along, and it makes a lot of what we've seen make a lot more sense.

Good grief! You can't just go posting that sort of thing in public, at least tag it NSFW.

Now please excuse me while I go and clutch my pearls in horror.

The problem with releasing them on day one is that you then can't gather more. If you've only just exposed the edges of the malfeasance you need time to get the rest before exposing it. Go too early and the rest of the evidence can be destroyed, covered up or those holding it coearsed into silence.

Having a dead man's switch is a way to ensure whatever you've gathered gets released if you're no longer in a position to gather more. As such I disagree with the poster about making it public knowledge before release. Keep it secret until you have everything, then release it.

I'm sure he was, or at least making the statement in a wry way. It's a very English sort of humour to understate the seriousness of the situation like that.

Trying to avoid using any arithmetic operators, and sticking just to binary (extending beyond 16 bit unsigned ints is left as an exercise for the interested reader):

    
#!/usr/bin/perl

# This increments $i

my $i=1;
print "Start: $i ";

if (($i & 0b1111111111111111) == 0b1111111111111111) {die "Overflow";}
if (($i & 0b0000000000000001) == 0b0000000000000000) {$i=(($i & 0b1111111111111110) | 0b0000000000000001);}
else
{
        if (($i & 0b0111111111111111) == 0b0111111111111111) {$i=(($i & 0b0000000000000000) | 0b1000000000000000);}
        if (($i & 0b0011111111111111) == 0b0011111111111111) {$i=(($i & 0b1000000000000000) | 0b0100000000000000);}
        if (($i & 0b0001111111111111) == 0b0001111111111111) {$i=(($i & 0b1100000000000000) | 0b0010000000000000);}
        if (($i & 0b0000111111111111) == 0b0000111111111111) {$i=(($i & 0b1110000000000000) | 0b0001000000000000);}
        if (($i & 0b0000011111111111) == 0b0000011111111111) {$i=(($i & 0b1111000000000000) | 0b0000100000000000);}
        if (($i & 0b0000001111111111) == 0b0000001111111111) {$i=(($i & 0b1111100000000000) | 0b0000010000000000);}
        if (($i & 0b0000000111111111) == 0b0000000111111111) {$i=(($i & 0b1111110000000000) | 0b0000001000000000);}
        if (($i & 0b0000000011111111) == 0b0000000011111111) {$i=(($i & 0b1111111000000000) | 0b0000000100000000);}
        if (($i & 0b0000000001111111) == 0b0000000001111111) {$i=(($i & 0b1111111100000000) | 0b0000000010000000);}
        if (($i & 0b0000000000111111) == 0b0000000000111111) {$i=(($i & 0b1111111110000000) | 0b0000000001000000);}
        if (($i & 0b0000000000011111) == 0b0000000000011111) {$i=(($i & 0b1111111111000000) | 0b0000000000100000);}
        if (($i & 0b0000000000001111) == 0b0000000000001111) {$i=(($i & 0b1111111111100000) | 0b0000000000010000);}
        if (($i & 0b0000000000000111) == 0b0000000000000111) {$i=(($i & 0b1111111111110000) | 0b0000000000001000);}
        if (($i & 0b0000000000000011) == 0b0000000000000011) {$i=(($i & 0b1111111111111000) | 0b0000000000000100);}
        if (($i & 0b0000000000000001) == 0b0000000000000001) {$i=(($i & 0b1111111111111100) | 0b0000000000000010);}
}
print "End: $i\n";

  

Things I was not expecting to see first thing in the morning: number 1...

Ha! Faking key presses, truly an elegant weapon for a more civilized age. If it works, it works.

The thing that got me to switch was being able to maintain my pane layout between connections. The various window and pane management niceties (naming, swapping, listing and the like) got me to stay. Now you can keep your screen, but you'd have to pry tmux from my cold, dead, tty.

It's likely that you're using a systemd based system and the admin hasn't enabled linger for your user.

This changes everything...

Depending on exactly what you mean by importing from excel, there are libraries for Perl/Python/your scripting language of choice that will simplify that so it becomes a matter of a fairly small amount of code to build a test harness that does exactly what you want.

"Sure you can." Later on the druid fails a diplomacy check because they've got an ant stuck between their teeth.

s/goat/potato/

Delightful though goats undoubtedly are, potatoes don't typically try to escape or eat the scenery.

I agree with the sentiment regarding being woken up, but I used to look forward to being on call. I could go to bed happily, knowing I was earning a significant premium and I'd still get a good night's sleep because the systems just didn't go down. I had the advantage that most of the customers I supported had similar requirements, so I had their systems locked up pretty well. Minor problems (disk space. Why is it always disk space?) would self heal, catastrophic failures (hardware failures or the engineer who supposed to replace a component unplugging the wrong server) would fail over to the rest of the cluster. I never had much trouble with logging either, it was typically one of the first things set up, and I had most of the setup automated to avoid missing anything. I suppose the thing was I was supporting systems I'd built, and I'd built them to ensure I didn't have to be woken up.

I do a lot more troubleshooting and rescue type work nowadays, and the number of times I run into systemd components just not doing what they should is frustrating to say the least. Being able to pull the logs by knowing the service name would be nice, but a) you could already do that because you set up different services to log to different places and b) you don't always know the service name in question. Being able to just grep the log directory is a lifesaver. You can still do that, but only because distros set systemd up to log to file as well as it's binary format. I loathe the way systemd ends up spreading it's unit files over about a dozen different directories, with overrides increasing that even further. I just want to know what services I've got and what will start up, in exactly what order, on the next reboot, dammit! The last one is particularly tricky as, due to services being started in parallel, you can't predict exactly what order things will actually start between targets. That shouldn't matter, units should have all their dependencies properly listed, but it's no fun tracking down a race condition that only happens once every x reboots when a particular network service takes a few hundred milliseconds longer to come up. Give me sequential boot any day. It might take a few tens of seconds longer, but it happens the same way each time, and I only need to look in one place to know what that is.

As to systemd's dominance, once Redhat, where Mr Pottering worked, chose it, it became hard for other distros not to. Derivative distros obviously went with it, and if you look back through the various email discussions, it was far from a unanimous choice for distros like Debian to choose it. They did so eventually mostly, as far as I can see, because it would theoretically make packaging easier. Fortunately they still support sysvinit, so all is not lost for those of us who want a mainstream distro without systemd bloat.

Shifting stuff to kube is definitely goot for making things more robust, so long as you've got the underlying clustering working, and I quite like working with it too. Once you realise it's basically just a database and message queue with a bunch of controllers for managing storage, networking, containers and the like, and the ability to extend that, you can do all sorts of fun things with it.

Anyway, I've gone on for long enough. If you're a sysadmin and the number of trouble calls is going down, then you probably don't hear this often enough: well done, you're doing a great job.

Sure, they blew a hole in the building, but the pizza was perfectly cooked, so mission accomplished.

Ok, fair point on the capital D, I must have read it like that years ago and it stuck. I shall have to make an effort to unlearn it.

As to the rest, systemd has been a constant thorn in my side ever since L. Pottering published "Rethinking PID 1" back in 2010 or so. I found, and still find, that most of the assertions and actions in that document either don't really hold, or just aren't really relevant. Basically it's trying to solve a problem that really wasn't an issue in the real world, and does so in such a massively overbearing way that everything actually becomes more laborious than it otherwise would be. From my perspective it's an unnecessarily complex and poorly architected attempt to answer a need that was better served in different ways. That it's become a near mono-culture is deeply concerning.

I've also run into all sorts of awkward edge cases and misfeatures over the years, from the automounter that occasionally didn't to race conditions that only manifest at the worst moments, none of which would have occured had the basic tenet of "do one thing and do it well" been followed. The extreme verbosity of the configuration, and unnecessarily large number of places it can be spread just serve to make it even more unpleasant to deal with compared to the simplicity of init scripts, crontabs and the like.

The sad thing is, there's undoubtedly some good ideas buried in it, but they could all have been implemented much more lightly and in a way that worked with the rest of the ecosystem rather than fighting it. Things like starting daemons in what is essentially a repeatable sandbox, or being able to isolate logging per service. They could, and had both been implemented already, but systemd has a real "not invented here" problem, so everything was built again, with all the attendant bugs, and design issues that inevitably brings.

Ultimately clients pay good money for me to look after their systems, systemd or not, so I probably shouldn't grumble, but I miss the days when Linux was a clean and elegant system, without this multi-tentacled thing sitting on top of it.

It looks like he pretty much invented surfing tidal bores on rivers, rather than surfing in general, and did it on a board he'd made himself.

I quite like knowing there were and are people like that about, even if you probably shouldn't look too closely at their politics. Knowing the spirit of adventure is alive and well gives me a little hope that things will turn out ok, and laughing at their bizarre antics is always a bit of a boost.

I think 'mad as a sack full of badgers' might be a more appropriate fit, but I can see the psychopath accusation, although he seems to mostly not cared about his own safety rather than displayed an unusual level of psycopathy for a soilder. If you read about the rest of his life it looks like hus feeling of invulnerability continued.

SystemD is far too much of a poorly thought through mess to have anything like a sane GUI configuration, it doesn't even have a sane textfile based configuration. We're going to have to wait fir SystemD to crumble under it's own weight and be replaced with multiple, simple, cleanly designed components before we have any hope of a sane config again. Sort of like we used to have before a certain someone/some company (depending on how conspiratorial you're feeling) decided to come along and muck it all up.

/rant

Thank you for coming to my Ted Talk Rant. You may gather I dislike SystemD quite a lot.

Do it as soon as possible, this is an opportunity that literally only comes around once per lifetime. Also, if she consents, try to record audio of her talking so that later generations can hear her and all the nuances of how she tells the stories.