I've never seen an ARM set up to run big-endian, even though it is capable. I far prefer big-endian, but apparently the little-endian heresy is now the dominant religion.
I find it bizarre and a bit infuriating when a charge that lasts multiple days is considered a significant advance. We used to have phones that would go a week without a charge, longer if you didn't make a lot of calls, but these days you're expected to charge the device constantly even if you don't use it. A multi day charge should be considered the bare minimum of acceptability.
We're just putting the wrong people in prison. We imprison people for using drugs who are hurting no one but themselves, but if a CEO screws up people' lives they often get a bonus for it.
There will always be someone who accepts the risk. You should not raise the pay, it is better to get someone who accepts the CEO job at lesser pay who is good at it then someone who demands huge compensation and then plays golf all day.
It is just one small department. They're not R&D, you don't want the IT help desk guys designing the next physical product that gets sold in stores that needs to have security. There are operations with servers that need security, and that's very often not IT, and even when it is IT you will see IT split into several sub-departments. IT tends to be focused on how quickly they can outsource their workers, put all the data into someone else's cloud, and cash in on a big bonus after saving all that money.
And for security, you never want "rank and file" implementing it. The rank and file don't understand security. You want security experts, not someone with a certificate from Microsoft.
Just get someone competent to run IT. And it's not just IT, security covers all departments. R&D that makes products that should have security, operations with external facing servers that should have security, servers that retain customer data, and so forth.
The problem in IT is that it's usually run by someone who just repeats Microsoft marketing and industry buzzwords. There's no real leadership except to pass along the same cookie-cutter solutions to their cookie-cutter employees. That often makes IT the worst place to get security leadership. Your college kid is going to be much much worse to be honest, they won't know the first thing about security; they skipped all those hard classes with math and theory. You need security leadership from a corporate wide group, with enough clout and authority to get things done instead of just being ignored. That's the snag though, there are security experts out there but they're often ignored. Security is very expensive, and it's inherently inconvenient.
The trick then is to make security important enough that people in authority take notice. They can't just delegate to head of IT, the worst person to put in charge of it (probably that same person skipped all the math and theory classes). And to get the leadership's attention, money must be involved. There must be a very prominent risk to the bottom line. The meltdown of blunders at Equifax isn't getting anyone to change their ways ("they failed because they had idiots in charge, but we have geniuses in charge here!").
One way to do this is to get customers to demand security. If one product is seen as insecure, then customers must shun it, no matter how cool or fashionable it is. But that's a pipe dream - customers don't care about security, that's why they keep buying more and more privacy invading devices. They want the newest devices always, even though the first devices to market always leave out security so that they can ship soonest, If you can somehow magically change how customers think about products so that they want something safe and secure and which doesn't snoop on them, then maybe companies will start to care about security.
So that's why I think the question needs to change. Instead we should ask "what are ways to get CUSTOMERS to actually focus on security?" Because that's the only thing that will make companies to focus on security.
I never understood this. Do this "don't do dumb things" during design, at which point you have many groups involved. Devs should not be making up their own features independently anyway. Having operations look over their shoulder once the plan is put in place and implementation is underway seems like overkill.
I used to think this. But I've seen some seriously bad engineering outside of software. You think they'll just do the math and then get the right design but they're still just as much focused on deadlines and cost cutting and politics as anyone else.
Not true. I got promoted to manager and my pay... er.. well.. I got a new title anyway!
I'm joking. I know of several times that my pay went up beyond the average raise. First I was underpaid and when my boss quit suddenly the CEO was in my office giving me a raise before I thought too hard about quitting too.
The trick is to actually be very useful to a company to the point that losing you would be a major inconvenience. But don't be a jerk about it like not documenting anything or writing incomprehensible code. It takes time to get there though unfortunately.
As for raises, they're based on pay grades. At some point you have to get to the next pay grade, otherwise you show up on the charts as having above average pay for the grade. If you're just an average worker then switching jobs may be the best way to go up a pay grade, because the new company doesn't know you're merely average and instead just sees a few more years of experience. But if you were getting those slightly above average raises because you were doing a good job, the manager may try bump the pay grade to keep you around.
Who can hire a developer who works independently and gets a program out to customers without anyone else knowing what is happening? At the very least there should be a manager who assigns the tasks, code reviewers to check it out, QA to test it, and a product manages who says "what the hell is this shit, where's the feature I asked for?"
One way of putting it is, "if it ain't broke, we don't pay you to fix it".
I swear, not lying, I had to deal with three cases of the same developer changing code to "fix it" that resulted in extremely damaging bugs that hit some of the biggest customers in the face (think permanent loss of data and bricked products). And all three occurred in the same month! No one asked for the fixes, although for one of them he kept complaining over and over that it needed fixing until the manager relented. The guy also seemed to be unable to understand the K.I.S.S. principle.
Doesn't matter, if the machine is a production machine vital to getting products shipped, then leave it alone. Doesn't matter if it's still running DOS, Biff from IT has no business trying to upgrade it to Windows 10. If it's in the lab, don't touch it.
If you've got ten operations employees and ten developers, an you replace them with eight people doing the same work, then that's DevOps. It really only applies if your developers are doing web stuff so that there's a little bit of overlap when seen from a mile high.
I was at one job in the 90s when the system and application developers were merged with the customer support team. All of the devs needed to spend time phoning up angry customers, and all of the customer support people had to fix up bugs. It only sort of worked because the customer support did know how to use the scripting language for the product, but us devs were absolute rubbish at talking to real people. That experiment only lasted a month. (later the same company took a few new developers who started that week and turned them into professional services, but that only lasted a day because they all quit)
Are you doing simple stuff? Do you have a lot of free time to do the remedial training of basic skills? Are you really hiring those C- average students?
I do embedded systems. It's very hard to find a new grad who's ever seen C or C++, much less having seen any hardware or assembler. It is quite common that they're just not cut out for the work. I remember one new coworker who would complain "I never learned how to do this!" Now I like a little whine now and then but that was pretty silly.
People did this before the term "cloud" was invented as a new service. The danger is putting everything in the cloud, from your corporate directory to the customer contact info.
There used to be this IBM commercial that I liked that had a bunch of seemingly clueless managers sitting around a table oohing and aahing about the magic pixie dust someone is selling. In real life, there are managers who treat the cloud like magic pixie dust, a way to fire the IT staff and auction off the servers.
But amazon has not put armored shields around the wires all the way to my computer. Accidents will happen. A backhoe will sever a line and the whole block will be without internet for a day or more. Amazon can't fix that. If you're a company that has real products to design, build, and ship then you should be able to continue working even if that accident happens because the data should be local, even if it's not as fast as it once was. If you have it all in the cloud then you may as well give everyone a paid vacation until the internet is back.
This isn't far fetched or hypothetical, it has happened. Single points of failure are always bad.
If you don't care that all your data vanishes and can never be recovered, then the cloud may be a good idea. But most companies don't fall into that category.
I agree that being an absolutist is bad, and often I see the cloud being used as an absolutist solution to downsizing IT staff and resources. The flaw is in not thinking when the latest buzzword is worth adopting or not. There are not many uses where the cloud works, because of the security concerns, not just security of keeping eyes away but security of keeping the data intact.
If you do use the cloud, do not use it as a substitute for having backups. Make your own backups and have them stored off-site. Always have a plan on what to do when the cloud service fails; can you switch to another service quickly, or rely on slower local computers? Even if the internet goes down for several hours, you should still be able to get work done locally, phone calls can be made, products can be shipped, etc. Believe me, from experience it is annoying to be stuck without access to your own data and documents that you thought were local, while waiting for the local telecomm company to fix the lines that got cut.
(Yes, DARPA researched networking protocols as a way to route around problems, but the modern internet sometimes seems like more of a loose collection of star networks)
This is slashdot. It exists only so that we can show up and say "you're an idiot!", which then starts a stream of comments "am not!", "are too!", "my hosts file is better than yours", "IANAL", "first post!"
This is a snag for many operating systems. Their "support" model is to always get the latest version, even if it's not the version you like. Ie, would Microsoft backport a fix to Windows 7 when they prefer to force people to upgrade to Ugly Edition? Will Android or phone makers backport to older models that the user wants to keep or force them to get the latest $800 phone if they want the fix? I can seriously see some companies thinking about this as a profit opportunity rather than priority bug.
Remember, WPA came about as an interim soltuion because the wifi makers wanted to get the products out and for sale quickly rather than wait for WPA2 or 802.11i, and yet it's still in wide use today as an option even in some new products.
Slashdot Mirror
I've never seen an ARM set up to run big-endian, even though it is capable. I far prefer big-endian, but apparently the little-endian heresy is now the dominant religion.
I find it bizarre and a bit infuriating when a charge that lasts multiple days is considered a significant advance. We used to have phones that would go a week without a charge, longer if you didn't make a lot of calls, but these days you're expected to charge the device constantly even if you don't use it. A multi day charge should be considered the bare minimum of acceptability.
We're just putting the wrong people in prison. We imprison people for using drugs who are hurting no one but themselves, but if a CEO screws up people' lives they often get a bonus for it.
There will always be someone who accepts the risk. You should not raise the pay, it is better to get someone who accepts the CEO job at lesser pay who is good at it then someone who demands huge compensation and then plays golf all day.
It is just one small department. They're not R&D, you don't want the IT help desk guys designing the next physical product that gets sold in stores that needs to have security. There are operations with servers that need security, and that's very often not IT, and even when it is IT you will see IT split into several sub-departments. IT tends to be focused on how quickly they can outsource their workers, put all the data into someone else's cloud, and cash in on a big bonus after saving all that money.
And for security, you never want "rank and file" implementing it. The rank and file don't understand security. You want security experts, not someone with a certificate from Microsoft.
Just get someone competent to run IT. And it's not just IT, security covers all departments. R&D that makes products that should have security, operations with external facing servers that should have security, servers that retain customer data, and so forth.
The problem in IT is that it's usually run by someone who just repeats Microsoft marketing and industry buzzwords. There's no real leadership except to pass along the same cookie-cutter solutions to their cookie-cutter employees. That often makes IT the worst place to get security leadership. Your college kid is going to be much much worse to be honest, they won't know the first thing about security; they skipped all those hard classes with math and theory. You need security leadership from a corporate wide group, with enough clout and authority to get things done instead of just being ignored. That's the snag though, there are security experts out there but they're often ignored. Security is very expensive, and it's inherently inconvenient.
The trick then is to make security important enough that people in authority take notice. They can't just delegate to head of IT, the worst person to put in charge of it (probably that same person skipped all the math and theory classes). And to get the leadership's attention, money must be involved. There must be a very prominent risk to the bottom line. The meltdown of blunders at Equifax isn't getting anyone to change their ways ("they failed because they had idiots in charge, but we have geniuses in charge here!").
One way to do this is to get customers to demand security. If one product is seen as insecure, then customers must shun it, no matter how cool or fashionable it is. But that's a pipe dream - customers don't care about security, that's why they keep buying more and more privacy invading devices. They want the newest devices always, even though the first devices to market always leave out security so that they can ship soonest, If you can somehow magically change how customers think about products so that they want something safe and secure and which doesn't snoop on them, then maybe companies will start to care about security.
So that's why I think the question needs to change. Instead we should ask "what are ways to get CUSTOMERS to actually focus on security?" Because that's the only thing that will make companies to focus on security.
I never understood this. Do this "don't do dumb things" during design, at which point you have many groups involved. Devs should not be making up their own features independently anyway. Having operations look over their shoulder once the plan is put in place and implementation is underway seems like overkill.
Oh, I've done similar stuff. I was imaging more of coming up with a new feature and sticking it into the company's cash cow when they're not looking.
Which brings up a very important truth: Newer Does Not Mean Better.
That applies in all fields, not just IT.
I used to think this. But I've seen some seriously bad engineering outside of software. You think they'll just do the math and then get the right design but they're still just as much focused on deadlines and cost cutting and politics as anyone else.
Not true. I got promoted to manager and my pay... er.. well.. I got a new title anyway!
I'm joking. I know of several times that my pay went up beyond the average raise. First I was underpaid and when my boss quit suddenly the CEO was in my office giving me a raise before I thought too hard about quitting too.
The trick is to actually be very useful to a company to the point that losing you would be a major inconvenience. But don't be a jerk about it like not documenting anything or writing incomprehensible code. It takes time to get there though unfortunately.
As for raises, they're based on pay grades. At some point you have to get to the next pay grade, otherwise you show up on the charts as having above average pay for the grade. If you're just an average worker then switching jobs may be the best way to go up a pay grade, because the new company doesn't know you're merely average and instead just sees a few more years of experience. But if you were getting those slightly above average raises because you were doing a good job, the manager may try bump the pay grade to keep you around.
Who can hire a developer who works independently and gets a program out to customers without anyone else knowing what is happening? At the very least there should be a manager who assigns the tasks, code reviewers to check it out, QA to test it, and a product manages who says "what the hell is this shit, where's the feature I asked for?"
One way of putting it is, "if it ain't broke, we don't pay you to fix it".
I swear, not lying, I had to deal with three cases of the same developer changing code to "fix it" that resulted in extremely damaging bugs that hit some of the biggest customers in the face (think permanent loss of data and bricked products). And all three occurred in the same month! No one asked for the fixes, although for one of them he kept complaining over and over that it needed fixing until the manager relented. The guy also seemed to be unable to understand the K.I.S.S. principle.
Doesn't matter, if the machine is a production machine vital to getting products shipped, then leave it alone. Doesn't matter if it's still running DOS, Biff from IT has no business trying to upgrade it to Windows 10. If it's in the lab, don't touch it.
DevSecOpsJanitorIT?
If you've got ten operations employees and ten developers, an you replace them with eight people doing the same work, then that's DevOps. It really only applies if your developers are doing web stuff so that there's a little bit of overlap when seen from a mile high.
I was at one job in the 90s when the system and application developers were merged with the customer support team. All of the devs needed to spend time phoning up angry customers, and all of the customer support people had to fix up bugs. It only sort of worked because the customer support did know how to use the scripting language for the product, but us devs were absolute rubbish at talking to real people. That experiment only lasted a month. (later the same company took a few new developers who started that week and turned them into professional services, but that only lasted a day because they all quit)
Operations gets near the production machines, IT should stay away too. Of course, a lot of companies are confusing the two these days.
Are you doing simple stuff? Do you have a lot of free time to do the remedial training of basic skills? Are you really hiring those C- average students?
I do embedded systems. It's very hard to find a new grad who's ever seen C or C++, much less having seen any hardware or assembler. It is quite common that they're just not cut out for the work. I remember one new coworker who would complain "I never learned how to do this!" Now I like a little whine now and then but that was pretty silly.
Also, developers are not operators, and operators are not developers.
(meanwhile both operators and developers are pissed at Gerry in IT)
People did this before the term "cloud" was invented as a new service. The danger is putting everything in the cloud, from your corporate directory to the customer contact info.
There used to be this IBM commercial that I liked that had a bunch of seemingly clueless managers sitting around a table oohing and aahing about the magic pixie dust someone is selling. In real life, there are managers who treat the cloud like magic pixie dust, a way to fire the IT staff and auction off the servers.
But amazon has not put armored shields around the wires all the way to my computer. Accidents will happen. A backhoe will sever a line and the whole block will be without internet for a day or more. Amazon can't fix that. If you're a company that has real products to design, build, and ship then you should be able to continue working even if that accident happens because the data should be local, even if it's not as fast as it once was. If you have it all in the cloud then you may as well give everyone a paid vacation until the internet is back.
This isn't far fetched or hypothetical, it has happened. Single points of failure are always bad.
If you don't care that all your data vanishes and can never be recovered, then the cloud may be a good idea. But most companies don't fall into that category.
I agree that being an absolutist is bad, and often I see the cloud being used as an absolutist solution to downsizing IT staff and resources. The flaw is in not thinking when the latest buzzword is worth adopting or not. There are not many uses where the cloud works, because of the security concerns, not just security of keeping eyes away but security of keeping the data intact.
If you do use the cloud, do not use it as a substitute for having backups. Make your own backups and have them stored off-site. Always have a plan on what to do when the cloud service fails; can you switch to another service quickly, or rely on slower local computers? Even if the internet goes down for several hours, you should still be able to get work done locally, phone calls can be made, products can be shipped, etc. Believe me, from experience it is annoying to be stuck without access to your own data and documents that you thought were local, while waiting for the local telecomm company to fix the lines that got cut.
(Yes, DARPA researched networking protocols as a way to route around problems, but the modern internet sometimes seems like more of a loose collection of star networks)
This is slashdot. It exists only so that we can show up and say "you're an idiot!", which then starts a stream of comments "am not!", "are too!", "my hosts file is better than yours", "IANAL", "first post!"
You use a phone for a cooking timer? A $5 kitchen timer versus $500 voice controlled fad.
This is a snag for many operating systems. Their "support" model is to always get the latest version, even if it's not the version you like. Ie, would Microsoft backport a fix to Windows 7 when they prefer to force people to upgrade to Ugly Edition? Will Android or phone makers backport to older models that the user wants to keep or force them to get the latest $800 phone if they want the fix? I can seriously see some companies thinking about this as a profit opportunity rather than priority bug.
Remember, WPA came about as an interim soltuion because the wifi makers wanted to get the products out and for sale quickly rather than wait for WPA2 or 802.11i, and yet it's still in wide use today as an option even in some new products.