Catch up on stories from the past week (and beyond) at the Slashdot story archive

 


Forgot your password?
Close
typodupeerror

Comment Re:Full OS devices (Score 1) 57

by Gravis Zero (#65774232) Attached to: Are Network Security Devices Endangering Orgs With 1990s-Era Flaws?

You should take a class on operating systems so that you understand what an OS really is. It can be extremely restrictive and minimalistic but you still need a full OS because there are many tasks that must be handle simultaneously. You can argue that the current OSes used are too expansive but arguing against needing an OS is idiotic.

Submission + - Bank of America faces lawsuit over alleged unpaid computer boot-up time (hcamag.com)

Submitted by Joe_Dragon
Joe_Dragon writes: Bank of America is facing allegations that hundreds of hourly workers performed up to 30 minutes of unpaid computer setup work daily for years.

A former Business Analyst filed a class action lawsuit in federal court on October 23, claiming the banking giant systematically shortchanged remote employees who had to boot up complex computer systems before their paid shifts began.

Tava Martin, who worked both remotely and at the company's Jacksonville facility, says the financial institution required her and fellow hourly workers to log into multiple security systems, download spreadsheets, and connect to virtual private networks—all before the clock started ticking on their workday.

The process wasn't quick. According to the filing in the United States District Court for the Western District of North Carolina, employees needed 15 to 30 minutes each morning just to get their systems running. When technical problems occurred, it took even longer.

Here's how it worked: Workers turned on their computers, waited for Windows to load, grabbed their cell phones to request a security token for the company's VPN, waited for that token to arrive, logged into the network, opened required web applications with separate passwords, and downloaded the Excel files they needed for the day. Only then could they start taking calls from business customers about regulatory reporting requirements.

The lawsuit says Bank of America enforced a strict "phone ready" policy. Employees had to be prepared to handle calls the moment their scheduled shifts began. Anyone who clocked in but wasn't immediately available to take or make calls for too long risked poor performance scores and possible disciplinary action, up to and including termination.

Yet the company allegedly discouraged workers from reporting any time outside their scheduled hours. Martin's paystubs routinely showed exactly 40 hours per week, or exactly 32 hours when she missed a day—suggesting the bank paid for scheduled time rather than actual work performed.

The unpaid work didn't stop at startup. During unpaid lunch breaks, many systems would automatically disconnect or otherwise lose connection, forcing employees to repeat portions of the login process—approximately three to five minutes of uncompensated time on most days, sometimes longer when a complete reboot was required. After shifts ended, workers had to log out of all programs and shut down their computers securely, adding another two to three minutes.

Martin earned $46.17 per hour through a third-party staffing agency, though Bank of America controlled her schedule, training, and employment conditions. Like many of her colleagues, she regularly worked full-time hours, meaning the uncompensated startup and shutdown time should have been paid at the overtime rate of one and a half times her regular wage.

The lawsuit points to 2008 guidance from the Department of Labor that specifically addresses call centers under the Fair Labor Standards Act. That guidance explicitly states that an example of the first principal activity of the day for call center workers includes starting computers to download work instructions and applications. It also requires employers to keep daily or weekly records of all hours worked, including time spent in pre-shift and post-shift activities.

The filing suggests Bank of America either didn't bother to determine whether the computer time was compensable or knew it was but failed to pay for it anyway. The lawsuit notes the company has faced factually similar cases from other employees about time spent loading and logging into computer systems.

For the week of March 11 through March 17, 2024, for example, Martin was paid for 40 regular hours but no overtime. With unpaid pre-shift, meal-period, and post-shift time of at least 20 minutes per shift over five shifts, she should have received an additional 100 minutes at her overtime rate of $69.25 per hour. Similar calculations apply to other pay periods cited in the complaint.

Business Analysts were interviewed by company hiring managers and assigned to Bank of America managers upon hire. The bank provided supervisors who oversaw their daily performance and gave them training and technical support. The company controlled work schedules and retained the ability to discipline and terminate employees. The positions were hourly, non-exempt jobs with rigid schedules requiring at least eight hours per day, on average five days per week, and up to 40 hours or more weekly.

Martin seeks to represent all current and former remote hourly Business Analysts who worked for the bank during the three years before conditional certification through judgment. She estimates the group includes hundreds, if not thousands, of workers who performed essentially the same tasks using the same or similar computer programs under the same timekeeping policies.

Many Business Analysts, including Martin, were employed through third-party staffing agencies but were required to comply with all Bank of America employee handbook policies, including those covering attendance, timekeeping, and overtime.

The case remains in early stages, with no court ruling yet on whether it will proceed as a class action or on the merits of the allegations.

Comment Maybe (Score 2) 54

by Gravis Zero (#65769770) Attached to: Linux Ported to WebAssembly, Boots in a Browser Tab

So I pondered this seriously and the demo displays using Xterm.js which is pretty advanced for displaying a terminal.
Unfortunately, Xterm.js does not support the Kitty graphics protocol which is used by Terminal Doom. However, DOOM-ASCII which uses colored ASCII art and lacks sound.

Caveats:
* if DOOM-ASCII adds anything to the original DOOM that requires an MMU then it can't run because there is no MMU support in the WASM Linux port.
* The WASM Linux port author wrote that, "The console freezes after 5 minutes" which is related to some timing bug.

TL;DR: maybe using DOOM-ASCII for five minutes.

Comment 2030 (Score 1) 74

Keiji Kaita, president of Toyota’s Carbon Neutral Advanced Engineering Development Center, confirmed this week at the Tokyo Motor Show that the company aims to introduce its first solid-state battery-powered EV by 2028.

"introduce". This means that actual use is going to they are aiming to work out production snags in 2028 before scaling up in 2029. 2030 is when you should expect these to be generally available.

Engineering battery tech is like microfabrication: it takes time because mistakes can be expensive. They will only rush the process if they fear someone will beat them to the market.

Comment Wrong title. (Score 4, Insightful) 57

A more honest title would be:

Security Experts Find that Corporate AI Use Puts Corporations At Risk

Humans are going to be lazy, this is what humans do. If you don't want them to feed sensitive information into AIs then...
A) Stop making it possible.
B) Stop telling them that AI makes things easier.

Touting AI as something that makes work easier and saying it's a "no-no" to put certain information in it is just begging them to violate that rule. Managers/Executives that are encouraging the use of AI have nobody to blame but themselves.

Comment Re:It needs to be able to prove it. (Score 1) 26

by Gravis Zero (#65766580) Attached to: OpenAI Launches Aardvark To Detect and Patch Hidden Bugs In Code

Creating a mental model of how code executes is far more complex when working with source code. It would be far easier to examine a compiled binary because an avoid issues with languages entirely. That said, even reverse engineering tools lack the capabilities entirely map out all possible execution paths for typical closed-system applications (doesn't load external executable data). However, I know it's possible, so it seems like it's only a matter of time before it gets made and then AI might have a chance of being able to use it.

Comment It needs to be able to prove it. (Score 2) 26

by Gravis Zero (#65765732) Attached to: OpenAI Launches Aardvark To Detect and Patch Hidden Bugs In Code

For this to be effective rather than disastrous, it needs to be able to generate a proof that can be validated to confirm that a flaw exists. That is not to say that it will fix it correctly, only that the flaw is real.

Anything short of this is undoubtedly going to generate "fixes" that are just AI slop. Anyone needing convincing need only look at the mess AI has made for the curl project.

Comment This is insane! (Score 1) 47

Quite plainly, this is a national security issue. It's not a far-fetched hypothetical to see networks infiltrated to compromise security in order to steal sensitive information about people, businesses, etc. Yes, "national security" is the common claim of the oppressor but that doesn't mean it's always illegitimate.

WHO THE FUCK WOULD BE AGAINST ACTUAL NATIONAL SECURITY?!

Slashdot Top Deals

"Out of register space (ugh)" -- vi

Close