Re: Fans of Dabbsy, D'oh! See?
Like the now underemployed security guard who still puts on a shirt and dark tie every morning
A Victor Meldrew reference! Today is going to be excellent.
460 publicly visible posts • joined 12 May 2010
The explanation that I've seen for prohibiting mobile phone use on a forecourt is because some people get absorbed in their phone conversation and disregard their surroundings. Having the whole line wait for someone to finish chatting with their bestie is not good for business.
You present some fascinating ideas. What struck me the most is
"because that's the design I am familiar with. It's the way I know." ...Spectrum BASIC to VAX/VMS to CP/M to RISC OS to OS/2 to Windows 95 to Windows NT to Linux...and Mac OS X.
Yes, I think we do tend to solidify our ideas based on experience. In Domain/OS, libraries were loaded globally; you didn't link to a file, you just called an OS function. In VMS, "default (current) directory" was merely a variable, not a verified location in the filesystem. Those examples make it easier to imagine OS features as independent from a file system.
1. If you have, say, a terabyte of non-volatile RAM, why do you need disks or paging at all?
Horses for courses. For example, a database runs in memory. One could argue that's the only place it really exists. If you export data to use in another program (e.g. financial reports), that might be easier as a named file rather than a memory segment.
No current OS organizes its RAM as a filesystem.
Fair point. That has advantages and disadvantages. I hope to never see another Linux OOM Killer.
I suggest that Object Storage is an example of an alternative to traditional filesystems, and might help imagine other ways to address data. I'd love to see a mail relay use Optane.
how about decreasing how many chips are needed for a car?...Do the seatwarmers' switches have to be wired to chips, or can they be connected via those newfangled "relay" thingies?
While I agree that cars include many computerish features of dubious value, it's not trivial to replace the chips. That buttwarmer switch has a thin data wire and a thin power wire. The relays are (probably under) each seat. To move the relay to the switch, you'd need to route the buttwarmer power circuit through the switch.
All those controls in the steering wheel/column are just inputs to computer chips which then transmit commands over the data bus which are received by the target devices. Anything you replace with a relay would require you to route the respective power circuit through the switch itself. Imagine rewiring every power window and lock through the driver door handle!
This is why older cars had hefty electric cables in the steering column.
The FAA warned about this 6 months ago. https://www.reuters.com/business/aerospace-defense/faa-has-deep-concern-about-5g-network-plan-aviation-safety-letter-2021-10-29/
They didn't sell the spectrum, the FCC did. Please keep in mind that not every country has privatized its airwaves.
"a decades old platform, the technical debt keeps on accumulating, and at some point it bites you"
What do you propose in place of radar altimeters? Airlines do have GPS (newer tech) and barometers (older tech) but those provide only the location of the aircraft, not of obstacles beneath.
"25% of our host resources to run their agent is just ridiculous."
I assume you mean their Controller VM, which uses 4 CPU cores and 32GB RAM (depending on features), per cluster node. If that's 1/4 of your virtualization farm, ouch.
The complexity is real. It helps to be familiar with Linux (especially KVM) and cloud concepts like object storage and metadata. Beneath their shiny UI, they use Hadoop for storage and OpenVSwitch for networking. I'm surprised your firmware updates were that bad. If you take one node offline at a time, even if that node breaks, your VMs should be fine.
I've been using it at work for a few years, and like it enough to use it for my VM lab at home. It sure isn't for everyone, and the "hybrid cloud" mentality isn't a perfect match for regular VM workloads, but there's a lot to like. Their REST API is great for automating cloud-like jobs.
I hope this isn't just a cover to raise their prices.
Or who learned not to trust any computers. Or learned that if their school district employs someone with a history of minor fraud, that person could return years later to ruin everyone's lives.
Computer backups are not easy to understand. Offline backups are not easy to perform. And often, the topic doesn't come up until after someone loses data and is upset.
Well, the OBD II standard is real. Wikipedia has some good information; look up Parameter IDs. Even a cheap $50 (£50) scantool can read the faults behind any warning light on your vehicle, and get a dazzling amount of operating parameters besides.
It is just a baseline, though. Manufacturers have many more details beyond the common set, sometimes specific to a certain engine or transmission. They charge money for that info. This is one difference between the little bluetooth dongles and the $5000 scantools that mechanics use.
And yeah, it's dirty that manufacturers can software-lock components to retain control. It's basically the same thing that Apple does with iPhone parts.
"I thought it already applied to cars in the USA?"
Yes, there is a defined set of things which must be available, like the standard OBD2 codes.
Manufacturers also use what I think are called "extended OBD2" codes. They transmit ignition timing on the OBD2 standard, but maybe the control module uses unpublished codes to transmit its internal diagnostics. So anyone could see there's a misfire, but only if you have proprietary OEM data could you see the module reporting a broken data wire.
Some manufacturers also lock their components by serial number. Okay, you bought a replacement ignition control module. Now bring it to the dealership because the other electronics in your car won't work with it until they program the new serial number. BMW is known for this, I think Volkswagen too. Ask a Tesla owner where they go for repairs.
At a previous job, I built some SMTP relays. They were highly tuned Linux servers with lots of disk space for mail spools. I published benchmarks, something like 1 million messages per day per server.
Years later, another team took over responsibility for email. Their tech lead made a Great Project to replace this old low-budget infrastructure with world-class appliances. He got test gear and quotes from 3 vendors, any of which utterly eclipsed the performance (and cost) of the Linux relays. Someone got me invited to help test.
My first suggestion was to list all the failure modes that each device was protected against: failed drives (RAID), redundant power supplies, battery-backed write cache, etc. Then induce every failure mode in rapid sequence. Yank a drive, wait a few minutes, re-insert it, wait until it started to rebuild the array. Then pull power from one supply, reconnect, yank the other power cord, reconnect, then pull both. Power it back on then start the performance test.
One appliance failed immediately. The others were badly impaired. Vendors got upset, and the tech lead was livid because he didn't look good either.
At a Meeting with managers and vendors, Tech Lead called me out on this BS. I was only sabotaging the project out of jealousy. He observed that the old relays had never been through that.
I showed them my original test results, where I had done exactly the same tests, but had first queued up 7 days of email on the Linux relays "because it could happen."
One appliance really shone. We bought that one. He never invited me to another project.
When I worked with a crisis line, people mostly called to connect with someone who will hear them, who "gets it." A few call for advice, but those are rarely the ones in crisis.
That human connection might offer a reason to keep being alive a little longer. The feeling that someone really does care about you. I once told someone that if they hadn't called that night, we would both have missed an excellent conversation.
Crisis counselors offer their humanity to connect with someone who might feel very far away from life. Chatbots can't.
Yup, it's all about their goals. These CEOs are often highly motivated, used to defining a goal and then seizing it.
Fictional example. If the Board at SAP set his Key Performance Indicators were (stock price), (revenue growth targets), and (year-on-year quarterly profit margin), then if he could buy another company to achieve them, he will. Slash headcount? Yes please.
Still fictional, if the Board at ServiceNow set his KPIs as (billable hours per employee), (increased revenue per customer), and (market share), he could invest in retaining staff, jigger how time is billed, push inside sales targets, and offer discounts to customers who drop a competitor.
I don't care if init calls a service manager. I want the web server to start after boot, and if it depends on a database back-end, I want the database up before the web server starts, and if the database depends on an NFS mount, I want that volume mounted first. I don't want every startup task to be serialized, but get the dependencies right.
"'sometimes one needs systemd evil' Can you provide examples?"
It's useful to be able to manage service dependencies and groups of services. This is why I liked the Service Management Facility in Solaris
Note that I don't claim systemd is the correct solution to anything, only that I have found cases where it helps to manage services at a higher level than SysV init.
"I for one DO NOT WANT to see "server-initiated transactions".
Your networking world is small. There are plenty of situations where data is pushed to the client. How would you connect a telephone call without notifying the recipient? How would you update real-time financial data to a trading terminal?
Yup, more confusing for normal humans, but network people should pick it up quickly.
When you have to untangle network problems in IPv4, it's already binary. Masks are binary, option flags are binary, routes are binary. Router jockeys are as dain brammaged as people who code in assembly language.
"MTU is only an issue for a single TCP stream....multiple streams and the aggregate bandwidth across the link will support it."
I agree, but sometimes the use case is a single TCP stream. I believe the above mention of MTU was for encapsulation, which can play merry hell with a TCP connection when some upstream device adds a few bytes to your packet which pushes it over 1500. Then the router frags 1 packet into 2. For various reasons, this is a common situation. If the client uses Path MTU Discovery, the connection just failed.
It's not just VPNs that get blocked.
A friend invited me to join his game (Valheim, I think). I could never connect to the game on his PC. He could connect to mine no problem. We dug a bit: his router wasn't receiving packets to the game port. I suspected CGNAT, but his ISP wouldn't discuss.
If radalts can't filter out a signal over 200MHz out of band there is something very wrong with them. Who allowed such shoddy equipment to be used to fly hundreds of people in a metal tube ffs?
It's not just what the radio altimeter can accept, it's also what might be sent to it.
Airplane equipment is safety critical. It's regularly re-tested. Airport electronics like ILS transmitters are too. In fact, not only are the transmitters re-tested regularly, but they are also tested from specially equipped airplanes to detect if something else is screwing with the signal.
In the US, telcos are lighting up powerful radios intended to transmit on frequencies close to air navigation frequencies, at locations close to airports. What if one malfunctions or the signal gets distorted? Will these be treated as safety-critical equipment?
Manufacturers, the FAA, and airlines around the world have expressed serious and specific concerns about the safety of this rollout. If that's not sufficient to take this seriously, what is?
Crooks kidnapping art and then waiting for the Statue of Limitations to run out?
Box office gold! My favorite part will be the climactic scene where the Statue, still gripping the mangled body of one of the art thieves, is confronted by FBI attack helicopters, police in tanks, and our small band of superheroes who just escaped from prison after being wrongly convicted of the heists.
I worked at a company when they outsourced their HR.
It sucked. I had a confidential "what if" question (related to a medical test) and instead of walking over to talk with someone who knew me and whom I knew would not take unnecessary notes, I had to call a number, identify myself by name and employee ID, and they were required to log the conversation in my file. Since everything was "on the record" there was no honest advice, only avoiding liability.
That gave me a new appreciation for the many HR people who find ways to genuinely help employees (within the limits of their job). And yes, termination is part of their job, just as automating manual tasks is part of mine. The job comes with a sword, and doesn't require that you enjoy swinging it.
I can think of quite a few cases where self-driving would be useful.
People with disabilities need to travel for work and shopping. Lots of disabled people who could work are unemployed because of a disability that limits their ability to drive, and public transit is often not a viable alternative.
Old folks. In the US, driving is often a key part of being independent. As people get too old to drive capably, there's no great transition for them. Self-driving cars could fill that gap.
Fatigue. I've read some studies that e.g. nurses have a higher risk commuting home after a 24-hour shift. A self-driving car could save lives.
I've been told off for doing work that was...better than desired
Most recently, we had to configure a lot of desktop PCs. The schedule was 5 each day, for several weeks. Life is short. I set up 14 at once and went back to my desk, RDP in occasionally while I do my regular job. 3 days of installs each afternoon.
The project manager got upset at me for screwing up his schedule. I told him to piss at my boss, because I've never been written up for delivering early. Thus ended the matter.
"is aware of a /potential concern/ related to the clock display...,"
That phrase really gets on my wick. "Potential" indicates that it's not realized. Hint: you're replying to an expressed concern. It's more than a concern, too: it's actually happening.
"any distress that might have been caused"
Double-ugh! "People told us about the problem, but we don't believe them."
"At least with paid for software there is someone to sue..."
Is there? License agreements usually state that the product is sold "as is" and explicitly disclaim all liability. I'm not aware of any (US) statute that would support a lawsuit of the type you mention.
Have you heard of any lawsuits against suppliers over software vulns? Were they successful?
I'd certainly like to hear a Windows or Macintosh user's experience trying Elementary Linux. Unfortunately, I don't know any such person who would be interested. They just run whatever programs on their PC; the desktop is (literally) background, and the underlying OS is invisible.
The highlights of our conversation would probably be "Where do I install Zoom?" "Can I sync photos from my phone?" and "What keys do I press for the screen reader?"
"Two tangled-up leads have four ends, and no matter how carefully you followed them, the two that you've plugged in may not belong to the same lead..."
A desktop PC fell off the network at mid-day. I walked over and learned that someone had just moved it to a desk with 3 other PCs already. The Ethernet cables were tangled, but fortunately they were each a different color so it wasn't too bad. One end was a little loose. I plugged it into the switch until the "click." People in adjacent rooms started shouting.
A moment later, the eager young shipping clerk showed me the third end of that orange Ethernet cable.... Yup, I had just looped 2 ports in the switch.
I severely distrust network cables with an odd number of ends.
"Runaway trim is runaway trim regardless of the cause. Pilots are trained to deal with it. The controls for doing just that were functioning but not used."
Pilots are trained to deal with runaway trim by running checklists to try various methods to regain control of the aircraft. Which method is effective does depend on the cause (and a novel cause might not be solved by the checklist.) The initial NTSB report showed the ET pilots took steps that correspond to the runaway trim checklist.
RF Burns, you keep claiming the incident pilots acted improperly. Please provide your sources. I gave mine.
"There was an exceptionally educational technical discussion on pprune at the time of the aerodynamics of the Max and why MCAS was introduced. And it was all to do with that the engine was way too powerful for the 737 wing config / cog. MCAS was not so much to make it have the same flying characteristics as previous model of the 737 but to actually keep it stable in flight."
Thanks for that. PPRuNe has some serious techs; I'll look. Always happy to learn!
"The Ethiopian pilots left the throttle at takeoff thrust. This is why the aerodynamic forces were so high. Further, electric trim was available but they didn't use it to override the computer....the Lion Air crash, the flight immediately before the accident had the MCAS problem. Those pilots used their training to override the computer and land safely....one pilot responded correctly but the other didn't."
No. From NTSB report pp 2-3 https://www.ntsb.gov/investigations/AccidentReports/Reports/ASR1901.pdf
During the preceding Lion Air flight on the accident airplane with a different flight crew, ...a 10-second automatic AND [Aircraft Nose Down] stabilizer trim input occurred, and the crew countered the input with an ANU [Aircraft Nose Up] electric trim input..captain moved the stabilizer trim cutout (STAB TRIM CUTOUT) switches to CUTOUT. He then moved them back to NORMAL, and the problem almost immediately reappeared. He moved the switches back to CUTOUT. He stated that the crew performed three non-normal checklists: Airspeed Unreliable, ALT DISAGREE (altitude disagree), and Runaway Stabilizer. The pilots continued the flight using manual trim until the end of the flight.
...Similar to the Lion Air accident flight, a 9-second automatic AND stabilizer trim input occurred after flaps were retracted and while in manual flight (no autopilot)...the pilot flying, partially countered the AND stabilizer input by applying ANU electric trim. About 5 seconds after the completion of pilot trim input, another automatic AND stabilizer trim input occurred. The captain applied ANU electric trim and fully countered the second automatic AND stabilizer input; however, the airplane was not returned to a fully trimmed condition. Cockpit voice recorder data indicated that the flight crew then discussed the STAB TRIM CUTOUT switches, and shortly thereafter DFDR data were consistent with the STAB TRIM CUTOUT switches being moved to CUTOUT.
However, because the airplane remained in a nose-down out-of-trim condition, the crew was required to continue applying nose-up force to the control column to maintain level flight. About 32 seconds before impact, two momentary pilot-commanded electric ANU trim inputs and corresponding stabilizer movement were recorded , consistent with the STAB TRIM CUTOUT switches no longer being in CUTOUT. Five seconds after these short electric trim inputs, another automatic AND stabilizer trim input occurred, and the airplane began pitching nose down.
"bolt big engines on a forty year old air-frame and there was no one left in Boeing who would tell the management - that will kill people."
The aircraft, including engines, is basically fine. The problem was that Boeing's target market was airlines who already fly previous models of the 737 and who would buy the new model as long as they didn't have to re-train* their flight crews. That was the reason Boeing added MCAS: to change how flight control surfaces behave so that the same pilot inputs produce the same aircraft behavior as with previous 737s. And Boeing really screwed up MCAS hard.
I completely agree about McDonnell-Douglas management. What a goat-rope.
*"re-train" is an understatement. Not only must pilots get a differences course on the new subtype, but they might not be permitted to switch back and forth between different subtypes. "It's just another 737" is a powerful sales argument for Boeing. That's the altar at which they sacrificed safety.
"use a GNSS-derived speed for validation of the pitot tube output. Now, I know the aviation industry doesn't like to rely on GNSS for various reasons, but it struck me this might be a valid application."
The problem is that GNSS measures a different thing than pitot tubes do. Pitots measure speed of local airflow: the medium in which the aircraft flies. GNSS measures geographic location. They are used for different applications.
A poor analogy would be road conditions versus location. I'll navigate with GNSS/GPS, but I'll drive by looking out the window and feeling the road. The difference, of course, is that when a car hits a road hazard you steer to the verge and stop. When a plane hits a hazard it's more exciting.
About 10 years ago, a new head of computer security came in and decided to clean house. He re-branded the dept to <RedactedCo> Information Security, or ISIS. He had shirts made with the new name. His staff tried to stop him because of Da'esh, but he didn't listen to stupid people.
He changed his mind after a trip to Israel. Apparently Mossad had pulled him aside to discuss his shirt.
At a previous job, I deployed a management server named "CLAM" which was a plausible acronym. The second data center later got CLAP. I planned DRIP for the Disaster Recovery center, but left before that was built. These were among thousands of other servers, so the pattern was not obvious.
It was a private joke until my last week there.