ixs

Worked at a web property that took scrum, used it and found it lacking in certain cases for development. They Extend it And called the new creation beyond scrum, abbreviated as BS snickers.

Unrelated to the shortcomings we found that Scrumm with the timeboxing concept did not work for infrastructure teams. You cannot just time box most Infrastructure task and just ship whatever you have when you exceeded your initially planned timeframe.

We came up with Kanban as a way to document progress. The swimming lanes together with a limit on things that can be simultaneously in flight served to mirror reality as an operational team much better than pure Scrum.

Southwest 1380 would like a word with you.

Southwest Airlines Flight 1380 was a Boeing 737-700 that experienced an uncontained engine failure[a] in the left CFM56-7B engine after departing from New York–LaGuardia Airport en route to Dallas Love Field on April 17, 2018. […] One passenger was partially ejected from the aircraft and sustained fatal injuries[…]

https://en.m.wikipedia.org/wiki/Southwest_Airlines_Flight_13...

If the person on the phone had said “Capone, Al” instead of “Uh…” he’d possibly not gone to jail.

Even ill gotten gains are taxable and the theory of one crime at a time suggests that even “other, unspecified” could be with paying taxes on to reduce the likelyhood of successful criminal persecution.

I would posit that the fee for tje airline ticket or the fuel and upkeep for your car is a transaction fee levied on cash transactions.

Sure, the bill itself is untouched, but the fee is still extracted.

If all you require a warm bodies to do menial tasks or low- to no-skilled labor? Sure, Pakistan and Africa will be happy to provide these.

If you are trying to rebuild your high-tech industry, however, you require educated people.

And why would these go to Russia if they can go to Europe or the US? Immigrating to Russia with possibly be easier, but it’s still Russia…

I think they store data in DXF. Should be pretty standard thus.

I‘ve been working with sweet home 3d a bit but then gave up on it after running into rendering issues.

Found https://pcon-planner.com/en/?privat=530&page=126 instead which is windows only and bon-open source but effectively free.

Pretty impressive stuff. Been very happy so far.

For fun: This actually runs the Java Applet KVM viewer on a SuperMicro X7 board: https://github.com/ixs/kvm-cli/blob/master/kvm_x7.py

1. Downloads the data from the IPMI interface

2. Modifies the files to run locally

3. Writes out a Java configuration with weak security settings so that TLS works with the deprecated ciphers.

4. Fires off a socat instance to redirect the localhost ports to the remote IPMI device.

5. Starts appletviewer locally.

Great fun writing that. Thank god we decomissioned the last X7 based storage appliances a while ago...

There are reasons for tools like https://github.com/ixs/kvm-cli. It seems like every operations team built their own version that logs into the web interfaces, downloads the java stuff and then runs it locally...

Just annoying.

I was just fiddling around with a SuperMicro X8 IPMI the other day. The X8 IPMI stuff is terrible, e.g. the warning that your Java installation is outdated on opening the website etc.

Turns out, you can actually install X9 IPMI firmware on X8 boards as the platform files are still shipped. Might be worth checking out, if this improves things for you. It did for me.

Check out https://github.com/devicenull/ipmi_firmware_tools for unpacking (and repacking) the SuperMicro firmware. The developer just merged my patches making it work with some of the X8 boards. As long as your board is listed in /etc/defaults of the IPMI tree you should be good.

The distance from Paris to Berlin is longer than Berlin to Lviv in Ukraine. Something that is often forgotten it seems.

The European Union has legitimate territorial security interests and a expansionist empire right next door that is encroaching on your borders isn't something the EU leadership likes to have around.

Considering that I doubt passively waiting for Ukraine to fall was never on the menu. Instead I expect the military and financial help for Ukraine to further increase as it is way cheaper to finance someone else to fight the empire next door than having to beef up your own border security.

There are certainly enough useful idiots around that are clamoring for cheap gas at any price but I do not have the impression that they get a lot of traction. I saw some numbers the other day that 70% of the German population agrees that supporting Ukraine is important, even if it means higher energy prices/colder times in winter. Only the voters of the far right party AfD thought it a sensible policy to drop Ukraine. Not surprising really for Moscow's fifth column.

I previously used MiniKeepass which has been shut down. My grated to KyPass, which looks good on paper but syncing with Google Drive didn’t work in practice.

Now using KeePassium Pro. Very happy. Does everything I need, uses the file API for opening files and integrates well.

Much wider hardware support with OpenWRT. If the hardware is accessible and supports Linux, there is an OpenWRT target for it. There’s even a x86 and a raspberry target.

If you’re happy with DD-WRT, no pressing need to change it. But if you want more features or specific packages, OpenWRT is the thing to look at.

What I find so baffling is that these experiences do not match my own at all.

I've been running a non-profit ISP for about 23 years with a few friends. We've always been doing this from our own IP Space (/20) in RIPE. Even when we had problems sending spam (compromised user accounts, compromised php websites) and we ended up on a blacklist, we usually could get removed pretty fast.

For a few years our mail system would sometimes generate late-bounces, that is accept a mail on the incoming MX only to then figure out that it actually cannot be delivered later on and generate a delivery failure notification mail. Not a good situation.

That got us into some trouble here and there. But even that could easily be unblocked again.

When we finally managed to set up a new mail infrastructure (2 year project cause it's a hobby) we set up new outgoing SMTP servers which cycle through multiple IP addresses. There was exactly one ISP (Deutsche Telekom T-Online) that was not accepting mail from some of these IPs. One mail and a turnaround time of abour 12hrs later this was fixed. Gmail or Hotmail/live.com/Outlook never had any problems with deliverability. Even with a few users forwarding all their email to their gmail accounts including the spam that slips through our filters. That might mean that a single mail would not be deliverd, but other users never suffered as our outgoing IPs are not being blanket-banned.

There's one residential ADSL provider that has a blanket ban on one of our outgoing IPs. There's no way to get that resolved because their mail infrastructure is unmaintained and nobody is reading their mail. Common problem with that one ADSL provider, googling their name shows other people have the same problem. shrug We just use a different outgoing IP for them.

No DMARK or DKIM setup at all for outgoing mail.

So I wonder, what really makes the difference in experience? Is it just the fact that we have a decent sized IPv4 Network in our name as PI space?

I appreciate the nuanced view. Let me add a bit of color though and point out where the "rumors" are wrong.

Subscription management of RHEL has always been an issue. There were ample ways of getting an evaluation set up or a free developer subscription but the backend work needed to get these done seemed insanely complex. I remember at some point hearing that for every free eval subscription an actual "sale" was recorded in the backend ERP (SAP?) system at Red Hat. That made quick drive-by downloads not feasible.

The developer subscription was a bit of a "hack" to extend and required you to go to an incognito window without cookies, authenticate to the developer portal which would then drop in the dev subscription into your Red Hat account. This was documented in https://developers.redhat.com/articles/faqs-no-cost-red-hat-... point 14. I cannot fathom what backend juggling necessitated this workflow.

For larger companies, managing subscription/entitlement keys was sometimes a hassle. I've heard of a handful of companies that paid for commercial RHEL subscriptions but most of the time just installed CentOS in prod as it was less of a hassle. There interesting thing here was that number of paid but unused RHEL subscriptions stayed mostly aligned with the number of machines in use. Other companies had RHEL in prod but CentOS in non-prod policies simply because it enabled quicker turnarounds and deployments.

The rumor that CentOS was on the brink of ending is something I find _very_ hard to believe. The CentOS project was a small group of people which - to the best of my knowledge - were all gainfully employed in the Linux/Admin space or sucessfully self employed as consultants and did the CentOS work in their free time as a hobby. For the consultants the CentOS connection might even have been a door opener. Bandwidth and hardware for mirrors, buildservers and webservers etc. were exclusively donations, as is very common for these projects. Even with a minimum of financial contributions or not even any at all, keeping such a project alive isn't difficult. After all, nobody is depending on the money for their livelyhoods and it's a hobby after all.

In the past there were times where drama hit CentOS-land. In 2009 LWN reported on the CentOS project founder disappearing a while ago and donations not reaching the project: https://lwn.net/Articles/345028/. That article seems to support my impression that financial contributions are not really relevant to the success of a project suhc as CentOS.

The issues with CentOS seemed more around life happening to people in control and then the project suffering: https://lwn.net/Articles/460791/ is an article from 2011 about package builds and pushes happening with delays. These issues however seemed to have been resolved some time later and delays seemed to be much less common. Interesting point: That article was contributed to LWN by the same author as the original post.

Now, considering these data points I wouldn't put a lot of faith into any rumors that CentOS was going to collapse and Red Hat came riding in to safe the day. I'd say it is much more likely that Red Hat had decided that RHEL was too restricted and fedora way to "fast and loose" to build an enterprise developer community around. Instead it might be a good idea to grab the CentOS and turn that into the development basis for ISVs, 3rd party commercial vendors and other open source projects. The Xen 4 CentOS project was a great example for this. Taking into account that a lot of these projects and special interest groups were announced shortly after the acquisition, I'd say this view isn't far from the truth.

At the end of the day, the moaning about a free alternative going away is kinda ridiculous I think. I know large users of CentOS (hundreds of thousands of machines) that had a look at CentOS stream, did talk a little bit about it amongst their different departments and decided that Stream is fine for them. If it is fine for these kind of shops, it can't be that bad.

Uhm. That’s a nice straw man to support the “no true Scotsman” fallacy. Well done. :-)

I did a bit of digging on Wikipedia. And based on the description in https://en.m.wikipedia.org/wiki/March_1933_German_federal_el... I think the claim that the ‘33 election wasn’t a free election isn’t baseless.

Having your fascist enforcers “monitor” the election, helping elderly people to the voting booths and “helping” them to vote correctly all seem to be indicators that the election is fishy.

And even then, the fascist party didn’t even get a majority…

There’s an argument to be made that the nazi Party never won an actual free election.

https://www.washingtonpost.com/opinions/hitler-was-not-voted... is a good example of the reasoning.

Based on the comments here I did a quick look at Amazon and was surprised to not even see a single vacuum only robot from Evovacs. At least not prominently showcased.

Why are there only mixed models and what are the benefits?

If I look at my place the ground floor is tiled and the top floor is all carpet.

That means I would need two vacuums anyway as they haven’t learned yet to climb stairs.

Why wouldn’t I want a vacuum only model for upstairs? For downstairs the universal model is great obviously. But upstairs?

Yes. This is so important.

Go on the internet, figure out who/which place near you is the predominant expert on that specific cancer and go there with your family member for a second opinion.

I am based in Europe and do not have US numbers, but you can look at statistics and see that the treatment success at hospitals focussed on cancer treatment is noticeably higher than at general hospitals who treat cancer amongst other cases. Regardless how long that trip takes or how complex the logistics are, it's worth doing.

All the best to OP and OP's family. The treatment takes a while and takes a lot out of people. It's going to take time to recover. Take that time, it's important.

I would generally agree with everything you said. These steps will get you job offers and employment.

But based on personal experience in Europe I do find that networking with recruiters is a complete waste of time. Networking with past colleagues and popping into the local meetup scene plus targeted talks with recruiters at industry conferences such as oscon (rip!) are going to give you way better returns.

I've got 20+ years experience in the industry, I've worked at some well-known shops and I have a decent looking CV with some financial sector experience. I do get the regular Google and Facebook recruiters on LinkedIn but would probably not pass their interview because I am already gainfully employed and do not have the time to cram computing trivia to pass their screen. Due to the financial sector experience I seem to get a ton of recruiters from the UK (and now NL), plus an incredible large number of invites to talk about a "devops engineer position" from German recruiters.

Especially the German recruiters are a complete waste of time. They are so terrible, they keep offering junior to mid-level positions to someone with 20yoe and a tech-lead/staff title to match. Their base comp is usually below 50% of my current base, sometimes barely a third. The UK and NL offers are better financially but still not reaching current TC levels. At this point, it's not even worth replying to their LinkedIn or Xing messages.

If you're at the bottom of the market or just starting out, recruiters or headhunters can be helpful to get an in at a company. But once you have a few years experience, their value rapidly declines, especially if you're aiming at the top of the market comp wise. With experience and a network, you know where your friends are working, if they like the places and you have an easy way to get referrals.

It does not. There are myriad ways of extracting the TOTP seed from these apps... Or you just reverse engineer the setup/confirmation process and then you can generate/trigger your own tokens from your automation workflow.

2FA is a good security feature but it does not help against web scraping. Credential stuffing and other 3rd party attacks? Yes, it _can_ help. But it does not always help. There's a phishing group that has seemingly specialised on getting people to click the green confirm button in their Duo app... ¯\_(ツ)_/¯

Check https://github.com/revalo/duo-bypass for a python script that can be used to automate Duo tokens... Has some code from me. There are similar scripts for all the other well known OTP Apps...

Last time I looked, ruffle did badger and similar videos well.

But as soon as there was any interactivity, e.g. random game from Kongregate (e.g. https://www.kongregate.com/games/moonkey/hexiom-connect or https://www.kongregate.com/games/kajika/planet-defender) ruffle just didn't do much other than hang at the loading screen.

My own personal use case for flash is to access baseboard management interfaces on servers. e.g. the Cisco UCS220B3 series uses a flash based interface. No dice with ruffle. It can do the login form and that's all there is.

This depends on the importance you assign to on-call.

And that value is usually defined by the likelihood of incidents and the impact of these.

If you constantly have incidents that are critical, you can either spend the engineering hours to fix the problems once and for all. If that is not possible because it's a different problem every time, it might be important to invest in more engineering resources and have them work shifts.

Printing for example has such a system where the impact of a stopped printing press can be catastrophic because no newspapers tomorrow. Thus there are on-site engineers that are paid to sit around and wait for a press to stop working.

If the occurrence of an incident is rare or the impact of them is basically nil for whatever reason, feel free to consider on-call not that important. Maybe an SLA of 6 hours is acceptable in such a situation.

If incidents are happening often and are important yet you do not want to spring for extra engineers but have your existing staff work on these on top of their regular duties, you need to come up with the right incentives. Massive pay helps to sweeten the deal and also provides incentives to prevent pages.

Personally I rarely drink anything, so not applicable to me.

But I had seen a good attitude from a colleague once: If you want me to put my normal life on hold for on-call shifts, that is fine with me. But then you need to pay me for that time as if I was sitting in the office: "So I'm going to be paid an additional 128hrs the week I'm on call, okay?"

In the specific case it was not about drinking but about weekend or evening trips with the family where the company expected the employee to sit at home instead and wait to potentially be paged.

People quickly came to the conclusion that some lowered expectations for the on-call person would be appropriate and working via a 4G connection from a notebook is totally acceptable.

I would say the experience is transferrable to drinking. Don't drink yourself into a stupor is sage advice, but we're not worrying about a bottle of wine, especially if it's shared over Dinner or such.

I fear you might underestimate the maintenance costs of forking.

A nice anecdote I heard a long time ago was comparing the approach to custom engineering between SuSE and Red Hat.

SuSE was always very happy to do custom engineering for paying customers and developed and shipped these features in their Linux Distribution. Specifically I am thinking of some interesting features done in the Kernel. At that point, SuSE received money for the engineering work but now had the burden of supporting their fork. The functionality code itself was not a problem, but the interfaces to the remaining kernel were a source of churn and pain.

Red Hat did the opposite. They told their customers that they can have whatever is in the upstream Kernel and they will help them upstream the necessary changes. That took markedly longer but the long term maintenance was much less effort because the in-tree code would be updated whenever an API/interface changed.

Canonical also had a tendency to happily fork of whatever project they needed to ship a fancy thing on time (think Netbook UI, think Unity etc.) and then get hit by the long term maintenance burden once upstream diverged.

Both SuSE and Canonical always found themselves in the unenviable position of having to constantly update their code and potentially seeing a competing but conflicting solution being merged upstream.

Carrying a few bugfixes or feature improvements in a local branch of a library is easy at first. But you're essentially creating technical debt which you'll need to pay off on every upstream change, every security fix etc. Most companies see value in developing features for their main application, not in maintaining internal forks of open source libraries.

I saw a recent (< 3 months) offer from MSFT and it contained the „standard“ 4y vesting schedule with a 1y cliff and then quarterly vesting after.

I think removing the vesting cliff is great but personally I am not worried as I never sew the cliff as a problem.

The US companies are hiring, just like everybody else.

Multi-nationals now seem to post most jobs as “remote” which means global. A smaller number is “US-remote”. Usually this is not for tax reasons but for business or security reasons if dealing with the US government.

Hiring remotely is easy for these companies as they usually have a subsidiary already in country. But even if not, there are now agencies that take care if things like taxation etc. I believe remote.com might be the one most known but it is certainly not the only one.

This! So much.

Sometimes you can plan for success/heroic actions (in the good way) but often it happens by accident.

The right person digging into a weird problem they encountered, two people sitting together to review a design or someone doing a firmware update that fixes a bug in the RAID controller giving you double the IOps...

I have tons of anecdotes from colleagues who did some unplanned work just because they talked with someone else and that work then turned out to have massive positive impact. The results are lauded but it wasn't even clear when the "little" project started that it would actually be a massive boon.

At a prior job (some website selling hotels online) I was responsible for the project that ended up giving the whole fleet a 25% capacity boost. Instead of 2000 machines we only bought 1500 next quarter. If we calculate that in perpetuity my project was a massive success. Millions of EUR saved since 2011.

The project initially started out as "tons of people tried building a decent perl RPM but couldn't get it to work, could you have a look?". The guy originally tasked with it was busy fixing a broken LDAP server. So I built some RPMs, wrote a bit of tooling around it and we ended up with a Perl environment separate from the system perl which was great because the business was nearly exclusively running on Perl 5.8.9. At that point I looked into using that to get us off CentOS4. With the help of two colleagues we got a CentOS5 environment running and could migrate to a x86_64 environment.

That migration than gave us a 25% capacity boost and happiness ensued all around. The OS upgrade wasn't part of the original project scope, we just went with it because it made sense and management understood that it's a good idea.

Super annoying behavior indeed.

But thanks to open source, being able to look at the driver and understanding how that SFP check is done, some people at the Serve The Home forum were able to figure out which EEPROM bit needs to be flipped for these cards to accept any and all SFP modules: https://forums.servethehome.com/index.php?threads/patching-i...

I saw that and wrote an automated patcher as a quick python hack to automate that: https://gist.github.com/ixs/dbaac42730dea9bd124f26cbd439c58e