Suzuran

moar liek chad hominem amirite

My apologies for incorrectly assuming your nationality.

CLOSED WONTFIX Working as intended

You are not allowed to discuss human rights until your government stops its unprovoked war on Iran, issues a full repudiation of the policies that led to it, and makes full reparations to the entire rest of the world whose energy prices you have driven up for the benefit of a handful of wealthy inside traders.

Edit: Parent poster wasn't American. I incorrectly assumed their nationality.

No, you missed the point. The GP was talking about causes for the situation where people are apparently prone to "outsourcing their thinking", resulting in low-effort AI slop being produced by entities that really should know better. The style of management I describe destroys the employee's confidence and agency, so they are much more likely to just submit and blindly accept whatever management/AI/etc. tells them than to do any sort of critical thinking.

There was also a test of the Apollo Launch Escape System wherein an unmanned CSM was launched on a Little Joe rocket with the plan being to manually trigger the LES at a specific point in the flight. The problem was that the roll accelerometer in the Little Joe had been installed backwards, so it quickly developed a substantial roll rate once it left the ground and the resulting centrifugal force acting on the innards of the SM turned them into rapidly escaping outards. This tore the SM skin apart and satisfied the automatic abort conditions for firing the LES. The LES operated as designed, the CM was pulled free of the SM, then went on to become stable and reach successful recovery conditions. The result was determined to be a successful test of the LES and the mission did not need to be reflown.

There is also the "You aren't paid to think, you are paid to do exactly what I tell you, nothing more or less!" school of management. I'm not sure how prevalent this attitude is now but it was very common in the 90s and 2000s. The AI and the bosses that want you to use it all speak from positions of authority and confidence. That's their right, granted to them by their position. You don't speak that way because as a subordinate if you do so it's an act of insubordination or disfealty and you need to be reminded of your place. So you learn to stay in your lane, mind your own business, etc etc because rule number one is that the nail that sticks up gets beaten down. ("He who has the money makes the rules" is rule number zero.)

Funny, I've also been lectured in the past but the other direction. I was judged guilty of being unjustifiably optimistic and giving people false hope which will only harm them in the future.

What will be left for us to work on? Nothing. The wealthy own all of the infrastructure and we are already being priced out of the means of building our own. The proverbial ladder has been pulled up. When the wealthy no longer have need of us and we are no longer worth the resources we consume, they will give us death. All we can do is hope it is a peaceful and painless death instead of a violent and painful death.

None of those concerns approach the level of priority that must be assigned to security. On defense, your security must be perfect forever or you are absolutely defeated. None of us are on the red team. It's not a rash decision, it's the only decision that logic allows. If you are not secure, you are NOTHING.

That's not relevant though. All concerns are secondary to security and Rust is the only language with security GUARANTEES. No other language is as secure. Therefore, even the worst Rust rewrite is automatically better than the best work in any other language, because it is the only one with guaranteed security.

If a Rust rewrite of any of your software becomes available and you aren't installing it immediately and without reservation, then you are simply not giving security the priority it both demands and deserves, and that makes you disastrously insecure. This is a serious issue that should be given all priority. There is no room for debate. Your only policies should be security before all else and compliance with those policies must be absolute and without deviation, or all is lost.

...probably with a referral string that results in them getting paid, too.

Your problem is not to circumvent security policies. Doing that places you at fault for whatever may happen. Reboot and comply fully with all security mandates. When productivity fails to meet expectations, that is a problem for your superiors to resolve, not you. Know your place and accept it.

"Bait used to be believable."

Freedom of speech exists to protect politically useful tools. That means the nazis and the Klan so long as they remain such. When they are no longer useful, the protection will pass to another useful tool.

That has always been the goal. There is, has, and always will be a powerful caste system to ensure that they are gods and we are trash. "Stay in your lane" / "Know your place" / etc. have been watchwords for thousands of years.

Mainframes can LPAR dynamically. When you want to test if your production system will IPL cleanly, you clone your production environment to an isolated LPAR and IPL it. No impact to production and you get your test.

In my case, it's always been because the native terminal emulator had issues actually emulating terminals when connected to remote systems, it was intended to be only a terminal-shaped wrapper around the host system's shell.

America is not rich. A handful of Americans are rich. The rest of us are not, and can never be allowed to become rich because that would not be in the interests of the aforementioned handful.

Another thing I should point out is that the CSP instruction set was not documented to the customer. The CSP software was called "Microcode" and the customer was not told about the CSP's design or how it worked. The documented instruction set for the System/34 and System/36 is that of the Main Storage Processor or MSP, which was an evolution of the IBM System/3.

You may not be looking for the right thing. On the aforementioned CSP, the instruction that performed XOR was called "XR" and not "XOR". My source is firsthand knowledge; I was a CE and performed service calls on the System/34, System/36, 370, and 390.

In any case, I am describing equipment built mostly in late 60s through the late 70s at IBM Rochester and Poughkeepsie. The IBM PC was developed by an entirely different team at IBM Boca Raton, and IBM didn't design its CPU.

On some of IBM's smaller processors, such as channel controllers and the CSP used in the midrange line prior to the System/38, the xor instruction had a special feature when used with identical source and destination - It would inhibit parity and/or ECC error checking on the read cycle, which meant that xor could be used to clear a register or memory location that had been stored with bad parity without taking a machine check or processor check.

Could be. You could also have been thinking of the 11/730, which was a cost-reduced 11/750 and thus the second-slowest VAX model DEC ever sold.

The slowest would be the 11/725, which was a cost-reduced 11/730 that had a reduced clock speed and half of the bus slots filled with epoxy to limit expansion. The 11/725 was so slow that using it was an act of masochism; It was slower than your 11/23+.

Those models were pretty rare though. Even though they were cheaper than an 11/750 the performance drop from the 750 to the 730 was too severe to justify even the reduced cost. If that were all then maybe replacing PDP-11s being used in industrial applications might have saved it but the 730 was still too expensive versus the existing PDP-11 products, and the 725's limited expansion made it less attractive than those same PDP-11 products. The PDP-11 thus outlived both the 725 and the 730.

It looks entirely made up because the procedure described is also entirely alien to me, and I had professional experience with both VMS and Ultrix when they were still supported by DEC. (And it's certainly not BSD...)

"We'll fix it eventually" is not good enough. If a human can find a flaw, then a bot can find the same flaw, and the bots are always watching and always testing. If someone can't commit to immediate security response when running a public-facing internet service then they should not be running that service, because the rest of the internet will not forgive them when their machine gets popped and becomes everyone else's problem.

If they can't commit to a hard timeline of less than a few days, then publish. What happens next is not your fault - it was inevitable anyway.

Edit for clarity: This is just in general, not specifically SDF or small orgs or large orgs. The internet does not care about the difference. The internet just does not care period. Nobody is going to give anyone else any breaks, and especially not a botnet.

There was no 11/380 but there was an 11/780.

If you have relays, the easiest RAM is just a bank of latching relays and the easiest ROM is a resistor board. Core rope is only for density.

The company doesn't get the choice. If they fire you or cut your pay over jury service, or even just threaten to to do so, and you can prove it, they can be arrested immediately. I have personally witnessed a judge issue a bench warrant for the arrest of a retail manager who told an employee that if she failed to get out of jury duty before her shift started that she would be fired. When the manager was brought in and questioned by the judge he tried to argue that it was his right to deny jury service by his employees. He was given 90 days in jail for contempt of court.

The problem is punishing the uploader doesn't remove the upload. Once the public has it, it has it forever. It doesn't un-contaminate a jury pool, and there's no later retraction if whatever that was uploaded is found to be lacking context, false, or outright fabricated. Once that kind of damage is done, it can't be un-done.

Using HTTP does not guarantee your content can be read, since it can be modified in transit. Your content could be replaced entirely and you would never know unless someone reported it to you.