>The American labor force is 160 million people, so the truck drivers are about 2%. The economy is currently growing at over 3% per year, so it could easily absorb that many workers even if all the trucks were replaced in one year.
Wow! Said like a statistician, someone who works in HR, or a Hillary campaign advisor. What a myopically heartless line of thinking.
The unemployment rate would be down, yes. But you completely glossed over the 3.5 million people who are now unemployed in an industry that won't come back. They want to take the skills they have (driving a truck) and earn a living. You think those last-mile freelance Amazon drivers are earning a good living? Think again.
As a technology-employed person myself as I get older I realize the growing importance of asking the question "just because we *can* do something, should we?" The cop out of "we scientists/engineers/programmers just create it, others decide how it gets used" died in Hiroshima or by tetraethyl lead poisoning.
This isn't bombs and lasers, you say? Fine. Take an easy example. "Self-driving vehicles will save lives! Carbon!" The transportation companies will be *first* in line to replace long-haul and regional drivers with bots. Those drivers are expensive (training, insurance, wages) and have a lot of downtime. A half-million dollar rig sitting for 8 hours while the driver *sleeps* eats a lot of money.
3.5 million Americans are employed as professional truck drivers and will be out of work when self-driving freight trucks hit the roads. Hire them to build the trucks? Fix them? Retraining them is expensive -- and historically this never happens. They may not even be able to be retrained for those jobs. When industries collapse, things get really bad really fast and politicians are poorly motivated to help.
What should a good technologist do? Keep working on vision systems and feedback controls?
Back in the day RPG was wonderful when it was used for its intended purpose. The concept of the program cycle was a fucking inspired piece of beauty. In a few minutes a competent programmer could create formatted output that would take days in any other language at the time.
Header, detail, break, total, and footer were just *breathing* in RPG. As a programmable text filter, unparalleled.
COBOL isn't hard to learn, and it can be understood/read/debugged a lot easier than many of the more contemporary languages. Banks that want to maintain COBOL systems need to just hire new CS graduates and give them time to come up to speed on the COBOL language.
All this may be true but why would they do that when, if they replaced it with something developed in the current century, they would not need to. A delivery company could train it's employees to drive horses and then use horse carts to make local delivery runs but why would they? Well perhaps for a sales gimick but otherwise using old technology often gives significant disadvantages beyond the need to train your employees.
I've worked in legacy software for a long time... and here's the thing.
Those COBOL systems aren't off-the-shelf modern framework-driven standard software packages. These packages were custom-built and tailored to the business needs of *that particular institution* over many years. You can't plonk down a credit card and buy a replacement; there's no github repository for that kind of code; you can't knock one out in a couple of weekends in a code camp.
That business' processes have co-evolved with that software for better or worse. Replacing it means rebuilding it around the existing business.
The programmers that work with this old cruft know the ins-and-outs of the system -- and if they're smart, they've learned the business, and the business owners *know* they know it. When the business decides to replace it, that's when the developer steps up and says "I'll do it, here's the plan." You go in as Jr. Programmer, you come out as Sr. Software Engineer.
In 30 years I've written (whole or in part) 2 payroll systems, 1 full-financial system (AP, AR, GL, etc..), 1 room scheduling systems, one freight routing system and one tax filing system. Each one (for its time) very modern, but based on older shittier systems that had to be learned and maintained before that.
>>A lot of your excess wind power during the summer comes at night when it's cool," > >I gurddit depends where you live, but around here there's usually less wind at night,
Weirdly, I thought the same thing. As a small boat fisherman I can tell you that it's a lot calmer out on the lakes at night than during the day. At ground level it's absolutely true, it's less windy at night.
But up at the hub level of a wind turbine it seems it's not: it's more windy. For example here is a study on why wind noise from turbines is worse at night (spoilers: it's windier and there's less atmospheric disturbance at ground level, so it sounds noisier)..
Once the executive team figures out that IT security is really important they tend to fuck it all up with an endless parade of audits and consultants
Like any parade, it's all for show. These people swoop in, make IT teams fill out questionnaires, conduct interviews, write reports, make recommendations, but nothing real actually gets done. What IT needs are people willing to get their hands dirty and actually help out with these projects. IT winds up having more thrown on their plate without increases in staffing or budget.
Ditch your PricewaterhouseCoopers schmuks and hire someone to actually do the work.
I work in software for a payroll processor and the "duplicate" SSN problem comes up all the time.
First off, we're not the employer and really don't care who you hire -- that's your problem. I think your contract with us requires that you perform verification of your employees, but we don't handle it. Give us an SSN, and we'll put it in the system.
Secondly, we *legitimately* see duplicate SSN's all the time in our database. Most common? Someone holds two jobs at once and we do payroll for both employers, for example.
Or, a worst case? Jane Smith works at ABC Company on January 1. She gets married on February 1, changes her name legally, moves, and gets a new job. Her old employer "lays off" Joan in case she comes back. February 2 she shows up in our database as Jane Doe at a new address, new job, new name but the same SSN. Both employers saw legitimate documentation and neither has knowledge or a duty to inform the other of any of this -- nor does the employee. We are bound not to disclose this to either client (confidentiality). What do we do? The quarterly filings contain completely different Janes, with the same SSN.
This is someone else's problem.
Now the State and Feds have this file that contains a "duplicate" SSN -- and they know it. What can they do, short term? They've got to swallow the file and take the withholding money. They're so far downstream from the problem, the best they can hope for is to send a notice to the employers asking "WTF" or kick Jane out for an audit when she files. The employers will both say she's fine. When she files -- a year later -- she claims both incomes, properly. Everything is okay for the IRS.
TLDR: SSN is a *terrible* indicator of uniqueness, and the IRS can't find your illegals for you.
Systems in Slashdot context I assumed would be understood as "software/hardware" systems.:) I do Payroll and Tax Filing software architecture. One of the many challenges is to maintain enough checks and balances that it's very hard to lose track of the money, even when an insider does something malicious or stupid.
Fantasy sports leagues are boring as hell. But I design financial systems, and I find cheating fascinating.:)
In a betting system (horses, sports, etc...) you have to base your bets on your own external information (scores, statistics, etc...) and possibly with some help from the betting system itself (300-to-1 odds indicate that this is a long shot).
However these guys had access to the betting information from other players -- in greater detail than the externally stated odds. The articles don't say how much they had access to. Let's say they had all of it. It'd be a reasonably cheat then to find the top few bettors based on past performance, and mimic their wagers. You might not win big, but you probably wouldn't do too badly. Crowd-sourcing the bets, from a very selective crowd.
Luck still plays a part, but this shaves some of the luck off based on information gleaned from data that others had no access to. It's insider.. something.
The quick thought is that systemd has a larger surface area for vulnerabilities than su and is therefore more likely to be a vector for attack -- this is almost always the *correct* assumption. The ball is in systemd's court to prove that despite having more code and more complexity, it is not as vulnerable.
As a kid my family had a Channel F and a boatload of cartridges for it -- plus 2 built-in games! The last one I remember getting was "Galactic Space Wars", and then the Atari 2600 showed up thus relegating the Channel F to the closet.
The graphics weren't great, and the games were something that a beginner could code up on an Atari 800 of the same era in BASIC. But they were fun enough. The Channel F did have a really unusual controller: the joystick could be moved about in a normal axis (up,down,left,right,diagonals) but also twisted, pulled up, or pushed down. The damned things broke a lot and were hard-wired into the console itself.
I didn't! Nowhere did I say the term was the authors exclusively. If you RTFA, you'll see the author uses the term twice for a specific reason. That is, where one speaker uses a more complex form of language relative to another speaker. To each the other's English is "broken" (his quotes, not mine). One is merely a subset or a simplification of the other. The author's point here being that "broken" is a two way street.
There are cases in English, and some of the more common verbs are irregular. However, to your point, if I didn't decline my pronouns properly and fumbled around my irregular verbs in English I'm still perfectly understood. (But, to use the article's term, "broken".)
English's main problem for non-English speakers seems to be the vast vocabulary and idioms, neither of which are needed for functional communication.
Back in the day (80's, 90's) when hard drives would refuse to spin up, a similar technique often worked. Take the drive and pop it into a very warm (but too hot) oven, or leave it on a car's dashboard on a hot summer's day. When it's hot enough that it's very uncomfortable to hold, but not hot enough to burn you... quickly drop it back into the system and spin it up. Then.. back up your data.
This'll cure stiction or lubricant problems with the platters.
One of the things that always mystified me growing up fishing here was the incredible uniformity of freshwater fish species across water bodies with very little geographic connection. New England is dotted with thousands of small ponds, and they all have more or less the same fish. Even tiny little ponds of a few acres with no major tributaries and only seasonal outlets will have bluegill, yellow perch, and probably a few black bass lurking somewhere and reportedly some pike or muskellenge. How did they get there? And why aren't fish like bluegill from different watersheds distinctive, the way the finches Darwin found in different Galapagos islands were different?
From Michigan here, lots of unconnected lakes and ponds here too.
It was always explained to me that they get there carried on the feet of waterfowl. Ducks and such land in the shallows and weeds, feet get covered in eggs. Ducks move on. Sometimes they're stocked by property owners or the DNR.
The fish *are* genetically diverse. Big fishing tournaments rely on this fact and do genetic testing on fish to make sure they came from the correct lake.
These companies insist you work in armpits like Bentonville Arkansas or Decalb Georgia so your salary can be shuffled down the chain to 40 grand a year not under the implication that your services are worthless, but under the assertion that the "cost of living" is so inexpensive you shouldnt need a respectable wage.
As a midwesterner, I'd like to tell you firmly to go fuck yourself... but also I'm far too polite to do that.
Instead maybe realize that wage costs are only part of having your business in the "armpits" -- and a pretty small one at that. Real estate, utilities, shipping, taxes, buildout costs, and a lot of other factors make flyover states a financially beneficial place to locate a business. With tech jobs there's no geographical need to pick a particular location other than space, power and bandwidth -- and those can be bought. Why not go cheap?
* Learn systems, and programming, and all that other crap but you were going to do that anyway. Linux and the cool stuff are fine, just remember to learn Windows too. Enjoy it. It won't be the worst system you'll use by any stretch.
* Use whatever system they give you. You'll learn something from everything you use. If someone pulls a 1978 CADO Systems CAT III out of a closet and needs you to retrieve financials from it, you'll learn the wonders of 8086 multi-user programming and hashed files.
* Take an accounting class. Hell, take two. Business classes are helpful as well. See things from your employer's and their client's perspective. Look at double-entry bookkeeping as a wonderful checksum and transaction based system. Speak to them in their own language.
* Try data entry for a spell. Barring that, go quietly watch your users work. Don't tell people how to use your software, watch how they use it. Nobody wants to click a mouse when they're being read columns of numbers over a telephone by a busy accountant.
* Make yourself useful. If you're not useful there, go find somewhere else to work.
No fear of that my friend. The biggest reason is that most US employers are unwilling to put their futures with the IRS into the hands of someone beyond the reach of US law. Generally, employers want the money here, the companies here, the programmers within easy reach, and full auditing on everything. Even if most of the code is done offshore, someone here still has to look it over.
There are a lot of trust issues around this industry. If the bank absconds with your cash, you're out the cash. If the payroll company takes the cash and fails to make your Federal deposit, you can go to jail (you can't pass the buck on that one).
That's because the software is largely crap. I say that as someone who still learned COBOL and yes, on a mainframe, in university.
I didn't pull any good lessons out of COBOL decades ago, however the designs around RPG turn out to be surprisingly useful even today. The basic concepts of header, details, running totals, nested breaks, subtotals, etc.. don't seem to be easy for programmers, and the interfaces to them in modern reporting systems are universally terrible.
All the while RPG handles this stuff like breathing, in a minimal problems kind of way. Plus the event-loop concept of processing incoming records and calculations is still freaking genius.
Slashdot Mirror
>The American labor force is 160 million people, so the truck drivers are about 2%. The economy is currently growing at over 3% per year, so it could easily absorb that many workers even if all the trucks were replaced in one year.
Wow! Said like a statistician, someone who works in HR, or a Hillary campaign advisor. What a myopically heartless line of thinking.
The unemployment rate would be down, yes. But you completely glossed over the 3.5 million people who are now unemployed in an industry that won't come back. They want to take the skills they have (driving a truck) and earn a living. You think those last-mile freelance Amazon drivers are earning a good living? Think again.
"The economy is growing!" Not for them it's not.
As a technology-employed person myself as I get older I realize the growing importance of asking the question "just because we *can* do something, should we?" The cop out of "we scientists/engineers/programmers just create it, others decide how it gets used" died in Hiroshima or by tetraethyl lead poisoning.
This isn't bombs and lasers, you say? Fine. Take an easy example. "Self-driving vehicles will save lives! Carbon!" The transportation companies will be *first* in line to replace long-haul and regional drivers with bots. Those drivers are expensive (training, insurance, wages) and have a lot of downtime. A half-million dollar rig sitting for 8 hours while the driver *sleeps* eats a lot of money.
3.5 million Americans are employed as professional truck drivers and will be out of work when self-driving freight trucks hit the roads. Hire them to build the trucks? Fix them? Retraining them is expensive -- and historically this never happens. They may not even be able to be retrained for those jobs. When industries collapse, things get really bad really fast and politicians are poorly motivated to help.
What should a good technologist do? Keep working on vision systems and feedback controls?
Get off my lawn. Seriously.
Back in the day RPG was wonderful when it was used for its intended purpose. The concept of the program cycle was a fucking inspired piece of beauty. In a few minutes a competent programmer could create formatted output that would take days in any other language at the time.
Header, detail, break, total, and footer were just *breathing* in RPG. As a programmable text filter, unparalleled.
Nothing of its ilk would come along until AWK.
COBOL isn't hard to learn, and it can be understood/read/debugged a lot easier than many of the more contemporary languages. Banks that want to maintain COBOL systems need to just hire new CS graduates and give them time to come up to speed on the COBOL language.
All this may be true but why would they do that when, if they replaced it with something developed in the current century, they would not need to. A delivery company could train it's employees to drive horses and then use horse carts to make local delivery runs but why would they? Well perhaps for a sales gimick but otherwise using old technology often gives significant disadvantages beyond the need to train your employees.
I've worked in legacy software for a long time... and here's the thing.
Those COBOL systems aren't off-the-shelf modern framework-driven standard software packages. These packages were custom-built and tailored to the business needs of *that particular institution* over many years. You can't plonk down a credit card and buy a replacement; there's no github repository for that kind of code; you can't knock one out in a couple of weekends in a code camp.
That business' processes have co-evolved with that software for better or worse. Replacing it means rebuilding it around the existing business.
The programmers that work with this old cruft know the ins-and-outs of the system -- and if they're smart, they've learned the business, and the business owners *know* they know it. When the business decides to replace it, that's when the developer steps up and says "I'll do it, here's the plan." You go in as Jr. Programmer, you come out as Sr. Software Engineer.
In 30 years I've written (whole or in part) 2 payroll systems, 1 full-financial system (AP, AR, GL, etc..), 1 room scheduling systems, one freight routing system and one tax filing system. Each one (for its time) very modern, but based on older shittier systems that had to be learned and maintained before that.
In a certain day and age Brøderbund Print Shop - made stuff was *everywhere*.
>>A lot of your excess wind power during the summer comes at night when it's cool,"
>
>I gurddit depends where you live, but around here there's usually less wind at night,
Weirdly, I thought the same thing. As a small boat fisherman I can tell you that it's a lot calmer out on the lakes at night than during the day. At ground level it's absolutely true, it's less windy at night.
But up at the hub level of a wind turbine it seems it's not: it's more windy. For example here is a study on why wind noise from turbines is worse at night (spoilers: it's windier and there's less atmospheric disturbance at ground level, so it sounds noisier)..
Once the executive team figures out that IT security is really important they tend to fuck it all up with an endless parade of audits and consultants
Like any parade, it's all for show. These people swoop in, make IT teams fill out questionnaires, conduct interviews, write reports, make recommendations, but nothing real actually gets done. What IT needs are people willing to get their hands dirty and actually help out with these projects. IT winds up having more thrown on their plate without increases in staffing or budget.
Ditch your PricewaterhouseCoopers schmuks and hire someone to actually do the work.
Yes, and slashdot linked directly to Forbes earlier today. The warning looked suspicious, so I didn't fall for it.
I bid... 4, and I use (mostly) my real name. Guess I have to stop being a grouchy old cuss.
I work in software for a payroll processor and the "duplicate" SSN problem comes up all the time.
First off, we're not the employer and really don't care who you hire -- that's your problem. I think your contract with us requires that you perform verification of your employees, but we don't handle it. Give us an SSN, and we'll put it in the system.
Secondly, we *legitimately* see duplicate SSN's all the time in our database. Most common? Someone holds two jobs at once and we do payroll for both employers, for example.
Or, a worst case? Jane Smith works at ABC Company on January 1. She gets married on February 1, changes her name legally, moves, and gets a new job. Her old employer "lays off" Joan in case she comes back. February 2 she shows up in our database as Jane Doe at a new address, new job, new name but the same SSN. Both employers saw legitimate documentation and neither has knowledge or a duty to inform the other of any of this -- nor does the employee. We are bound not to disclose this to either client (confidentiality). What do we do? The quarterly filings contain completely different Janes, with the same SSN.
This is someone else's problem.
Now the State and Feds have this file that contains a "duplicate" SSN -- and they know it. What can they do, short term? They've got to swallow the file and take the withholding money. They're so far downstream from the problem, the best they can hope for is to send a notice to the employers asking "WTF" or kick Jane out for an audit when she files. The employers will both say she's fine. When she files -- a year later -- she claims both incomes, properly. Everything is okay for the IRS.
TLDR: SSN is a *terrible* indicator of uniqueness, and the IRS can't find your illegals for you.
Systems in Slashdot context I assumed would be understood as "software/hardware" systems. :) I do Payroll and Tax Filing software architecture. One of the many challenges is to maintain enough checks and balances that it's very hard to lose track of the money, even when an insider does something malicious or stupid.
Fantasy sports leagues are boring as hell. But I design financial systems, and I find cheating fascinating. :)
In a betting system (horses, sports, etc...) you have to base your bets on your own external information (scores, statistics, etc...) and possibly with some help from the betting system itself (300-to-1 odds indicate that this is a long shot).
However these guys had access to the betting information from other players -- in greater detail than the externally stated odds. The articles don't say how much they had access to. Let's say they had all of it. It'd be a reasonably cheat then to find the top few bettors based on past performance, and mimic their wagers. You might not win big, but you probably wouldn't do too badly. Crowd-sourcing the bets, from a very selective crowd.
Luck still plays a part, but this shaves some of the luck off based on information gleaned from data that others had no access to. It's insider.. something.
The quick thought is that systemd has a larger surface area for vulnerabilities than su and is therefore more likely to be a vector for attack -- this is almost always the *correct* assumption. The ball is in systemd's court to prove that despite having more code and more complexity, it is not as vulnerable.
As a kid my family had a Channel F and a boatload of cartridges for it -- plus 2 built-in games! The last one I remember getting was "Galactic Space Wars", and then the Atari 2600 showed up thus relegating the Channel F to the closet.
The graphics weren't great, and the games were something that a beginner could code up on an Atari 800 of the same era in BASIC. But they were fun enough. The Channel F did have a really unusual controller: the joystick could be moved about in a normal axis (up,down,left,right,diagonals) but also twisted, pulled up, or pushed down. The damned things broke a lot and were hard-wired into the console itself.
I didn't! Nowhere did I say the term was the authors exclusively. If you RTFA, you'll see the author uses the term twice for a specific reason. That is, where one speaker uses a more complex form of language relative to another speaker. To each the other's English is "broken" (his quotes, not mine). One is merely a subset or a simplification of the other. The author's point here being that "broken" is a two way street.
There are cases in English, and some of the more common verbs are irregular. However, to your point, if I didn't decline my pronouns properly and fumbled around my irregular verbs in English I'm still perfectly understood. (But, to use the article's term, "broken".)
English's main problem for non-English speakers seems to be the vast vocabulary and idioms, neither of which are needed for functional communication.
Back in the day (80's, 90's) when hard drives would refuse to spin up, a similar technique often worked. Take the drive and pop it into a very warm (but too hot) oven, or leave it on a car's dashboard on a hot summer's day. When it's hot enough that it's very uncomfortable to hold, but not hot enough to burn you... quickly drop it back into the system and spin it up. Then.. back up your data.
This'll cure stiction or lubricant problems with the platters.
One of the things that always mystified me growing up fishing here was the incredible uniformity of freshwater fish species across water bodies with very little geographic connection. New England is dotted with thousands of small ponds, and they all have more or less the same fish. Even tiny little ponds of a few acres with no major tributaries and only seasonal outlets will have bluegill, yellow perch, and probably a few black bass lurking somewhere and reportedly some pike or muskellenge. How did they get there? And why aren't fish like bluegill from different watersheds distinctive, the way the finches Darwin found in different Galapagos islands were different?
From Michigan here, lots of unconnected lakes and ponds here too.
It was always explained to me that they get there carried on the feet of waterfowl. Ducks and such land in the shallows and weeds, feet get covered in eggs. Ducks move on. Sometimes they're stocked by property owners or the DNR.
The fish *are* genetically diverse. Big fishing tournaments rely on this fact and do genetic testing on fish to make sure they came from the correct lake.
Does anyone else remember Jesux? It didn't claim to talk to God, but <rabbi_voice>it couldn't hurt<rabbi_voice>.
Slightly offtopic...
These companies insist you work in armpits like Bentonville Arkansas or Decalb Georgia so your salary can be shuffled down the chain to 40 grand a year not under the implication that your services are worthless, but under the assertion that the "cost of living" is so inexpensive you shouldnt need a respectable wage.
As a midwesterner, I'd like to tell you firmly to go fuck yourself ... but also I'm far too polite to do that.
Instead maybe realize that wage costs are only part of having your business in the "armpits" -- and a pretty small one at that. Real estate, utilities, shipping, taxes, buildout costs, and a lot of other factors make flyover states a financially beneficial place to locate a business. With tech jobs there's no geographical need to pick a particular location other than space, power and bandwidth -- and those can be bought. Why not go cheap?
The bridge of the Enterprise.
obgeek:
I think it was in the TNG episode Brothers where Data locked out all of the systems on the ship, including Navigation.
WESLEY: We don't even know what star system we're in, sir.
RIKER: The only way we knew we'd come out of warp was by looking out a window.
Um, so how does one break into this dull field?
* Learn systems, and programming, and all that other crap but you were going to do that anyway. Linux and the cool stuff are fine, just remember to learn Windows too. Enjoy it. It won't be the worst system you'll use by any stretch.
* Use whatever system they give you. You'll learn something from everything you use. If someone pulls a 1978 CADO Systems CAT III out of a closet and needs you to retrieve financials from it, you'll learn the wonders of 8086 multi-user programming and hashed files.
* Take an accounting class. Hell, take two. Business classes are helpful as well. See things from your employer's and their client's perspective. Look at double-entry bookkeeping as a wonderful checksum and transaction based system. Speak to them in their own language.
* Try data entry for a spell. Barring that, go quietly watch your users work. Don't tell people how to use your software, watch how they use it. Nobody wants to click a mouse when they're being read columns of numbers over a telephone by a busy accountant.
* Make yourself useful. If you're not useful there, go find somewhere else to work.
No fear of that my friend. The biggest reason is that most US employers are unwilling to put their futures with the IRS into the hands of someone beyond the reach of US law. Generally, employers want the money here, the companies here, the programmers within easy reach, and full auditing on everything. Even if most of the code is done offshore, someone here still has to look it over.
There are a lot of trust issues around this industry. If the bank absconds with your cash, you're out the cash. If the payroll company takes the cash and fails to make your Federal deposit, you can go to jail (you can't pass the buck on that one).
This is what happens when you deal with something not entirely transparent.
That's because the software is largely crap. I say that as someone who still learned COBOL and yes, on a mainframe, in university.
I didn't pull any good lessons out of COBOL decades ago, however the designs around RPG turn out to be surprisingly useful even today. The basic concepts of header, details, running totals, nested breaks, subtotals, etc.. don't seem to be easy for programmers, and the interfaces to them in modern reporting systems are universally terrible.
All the while RPG handles this stuff like breathing, in a minimal problems kind of way. Plus the event-loop concept of processing incoming records and calculations is still freaking genius.
I wish they'd teach it now.