Pirs, the module that was discarded, was the 3rd oldest module from the ROS (Russian Orbital Section). It was used as (among other things) an airlock, and above and beyond the base age of the module, the pressure cycles from nominal to vaacum take a toll on the structure and equipment of the module. So, age was a factor.

The new module that is coming up, Nauka, has all the capabilities (and more) of Pirs. Therefore, there was no technical reason to retain the old module.

There are some physical constraints to consider as well. The ISS orbits at an altitude that's not far enough up to be entirely free of the effects of atmospheric drag, so it requires periodic boosts to raise its orbit. This is accomplished using thrusters, which consume fuel. The more massive the station is, the more fuel it takes to do so. Because of the technical capability overlap mentioned above, in this regard Pirs was unecessary excess mass.

The mass distribution of the station matters as well. If all the mass were evenly appllied around the fore-and-aft axis of the station, then applying thrust in the forward direction from the aft of the station would put the thrust vector exactly through the center of mass, which would make controlling said thrust vector easy. However, the mass is not thus equally distributed - which the station control systems can deal with, but the further away the center of mass is from the thrust vector, the harder it is to control (and at some point, it would become impossible). There are only so many places for modules to connect (ports) along the fore-and-aft axis of the station. Thus, to keep the mass distribution closer to this axis, the less massive Pirs.had to at least be moved out of the way to make room for the more massive Nauka. And, since there was no reason to retain it, per the above, it could be removed from the station entirely.

Bit o' irony there, having to promise I'll be careful to turn off a feature that is anything BUT careful...

And more to the point, this is nothing new. Curiosity used exactly the same mechanism. Just, when Curiosity landed, there were either no assets (at all, or close enough) to monitor its ejected balance mass(es) impact with the surface.

The below video (and separate slide deck available for download) go into some detail on this:

https://nescacademy.nasa.gov/v...

This backs up my rememberance that Curiosity was the first to use lifting guided EDL. Viking apparently used lift, but it was unguided. Pathfinder and MER (Spirit/Opportunity) were pure ballistic entry vehicles, w/o guidance after entry interface and w/o lift vector offset.

That's rich...

It's every employee's responsibility to remain vigilent. If they're not, then damned right they should be scared. It's just like driving these days... assume everyone else on the road is out to get you.

If a company has employees who click submit and only THEN think about whether it was right to have done so... clearly, if they received training at all, it was either ineffective, or they ignored their training.

Problem is, most anti-phishing training is laughable - some 30-60 minute online video training, "you should not do X" immediately followed by a quiz "should you do X?", and if the company requires periodic re-training/refreshers, it might be once a year. This might be sufficient for a small business, but for a large company, especially one who's entire business touches the internet, it's laughable.

If the company's IT policies and protections rely on self-reporting in order to mitigate a phishing attack, then they've already lost the battle. Twitter ought to (if they don't already) have an internal division who's entire job is to constantly probe the security of their systems, processes, and people. Not only does this have the benefit of constantly exposing the employees to the idea (thus keeping it fresh in their minds), it also has the benefit of exposing any potential shortcomings in the company's own training plan.

IF, and ONLY if an employee can demonstrate that they followed all the training the company has given them (and their own common sense), should they receive any lieneancy if they get phished.Other than that, in my opinion, there's no excuse.

Leaving aside why would such tools be so widely available to employees in the first place... I've commented in the past that, assuming said employees have received anti-phishing training, anyone who provably falls for this should simply be terminated, immediately. No kind of company could or should be more vigilantly aware of social engineering attacks than a social media company.

We've been dealing with the fallout of systems not designed with security in mind from the ground up, for decades now. For a compnay who's entire business presence is exposed to the wider internet, and for them to have begun operating within this time of awareness, and who demonstratably continues to apply the most rigorous security practices, boggles the mind.

Maybe you want to give companies that do this the benefit of the doubt. Maybe (and I speak without specific knowledge of developing iOS apps), some library they used had such a feature enabled by default (in which case shame on the library).

But, we see so much of this these days, I think a lot of folk's "benefit-of-the-doubt" bucket has been drained... and we assume the worst. Because Linkedin is one of those "information" companies, who's core business depends on how much info they have, and/or having more info than The Other Guy, it makes it all the harder to give them the benefit of the doubt.

Plus, of course, them calling it a bug. Suuuure. In my mind, a bug is something that crashes your program or gives a wrong answer to a calculation... not that does something (and does it correctly) that the program isn't supposed to do.

I won't be so naive as to say I don't know why every company these days seems to "telemeter" everything, even when they make a paid product. I just wish we hadn't ended up in a world where it was so prevalent.

Now, to go back to browsing the web on AmigaDOS...

... don't expose your network printers to the internet?

If you find it a pain in the butt to setup, fine, then it's your choice not to do it. But, then, don't complain that you've ceded or failed to retain/reclaim control over your e-mail.

For those that choose to run their own e-mail server, the control outweighs any heartburn for setting things up. Plus, I rather suspect lots of folk will learn a thing or two in the process, and be better off for it.

Perhaps you'd care to back up your claim about major e-mail providers by putting your money where your mouth is, and providing some cold hard data?

Then you'll have the option to have as much control over your inbox as you want, without having to rely on anybody else.

Oh, lighten up. It was an opinion expressed, that's all. Rest assured I am not in a position of authority anywhere to dictate the firing of anyone for any reason.

Based on the wording at the top of the summary, and near the top of the article, it would be easy to assume that this the first phishing test the company conducted. Let's assume for the moment that it is, because if this wasn't the first time, then that makes the numbers even worse. There's also no indication whether any of the test pool had previously received (and passed) any anti-phishing training... that would be a far more telling statistic, and also an indication of how serious and proactive the company is about its own internal security.

Everyone like to espouse that security is everyone's responsibility, and security starts with you... and in that I don't fundamentally disagree. But, in order to be that first layer of security, you need common sense, critical thinking skills, and situational awareness. Experience and training may (and generally will) refine these skills, but they have to be there in some form to begin with.

Gitlab's own exercise description and results page (linked in the article) give three examples of how, at plain sight, this should have been considered suspicious. I'll add a few more:

- Any e-mail that includes a "click here to login" link should raise an immediate red flag
- Any e-mail with an unexpected thing should be considered suspect, especially those regarding getting a new and/or free thing

Handing an employee a set of credentials that allow them access to any non-trivial part of the IT infrastructure (and that's basically everything these days) reposes a level of trust in said employee, and it's a privilege, not a right. Someone abuses that privilege, why shouldn't they punish or terminate them?

Dealing with lackadaisical, untrained, unmotivated coworkers with little to none of the skills I mention above, who elicit knee-jerk reactions from IT and corporate to protect the rest of the company from their dumbness, drives me up the wall, hence the origin of my original opinion. Take it for what you will.

That's really all you can do. Even assuming that the employees have not received training along these lines (in which case GitLab is about as stupid as 20% of the employees they hire), but to be a technology worker in this day and age and not understand what phishing is, or more to the point how common it is, passes understanding, and any decent technology company should not want people like this working for them.

Correct spelling right there in the summary. Just sayin'...

I'm pretty sure the city where the plant is located, has little to no control over the county order that is the point of contention.

You trying to start a rumble?