Waiting for an autonomous car near the city centre may not take long. But what happens when I visit a friend in the suburbs? The car drops me off and goes away. Then when I'm ready to go home, how long do I wait for a car to pick me up? If I own my own car, and if it doesn't go off to pick up someone else, my wait time to go home is nothing.
Keep in mind that my time has value. The cumulative value of the time I wait could be significant over the course of a year.
"Also I strongly echo the "make sure that you're editing what you're running/debugging" comment elsewhere. Still horribly easy to get that one wrong in lots of different ways..."
Agreed, although a modern VCS really really helps avoid this. Wish I'd had GIT back in the '80s.
So what happens when a company screws up and clobbers the wrong company (or individual)? Think about it: when your servers are being attacked, how certain are you as to who the culprit is? Are the cops (or the feds) really going to put their best manpower on vetting the work you've done to track down the baddies? Or will that be where they stick their less capable people?
Bottom line, if someone clobbers your company by mistake, whom do you sue?
Two bugs come to mind, one that I wrote and fixed, one that I fixed but did not create. The one that I created was an assembler bug, code written in UKY-502 assembler (military computer). I screwed up one op code, specifying LK (load constant) instead of L (load from memory address). The difference in the code was one bit, but I had to single-step through the code to find the bug - took me hours for one stinking bit.
The other bug, also on the UYK-502 computer, was a bug in the micro-code. The guy who wrote the micro-code for one particular instruction had ignored the user guide for the bit-slice processor and had implemented a read-modify-write operation in a single micro-code instruction. It worked for him because the timing hardware was slow enough. Unfortunately, a couple of years later, the manufacturer of one of the chips in the timing hardware improved the internal workings of the chip so that one of the line dropped sooner than it did on older versions of the chip (NB: the chip still met the same specs - it was just faster). Debugging was a pain. The computer used a back-plane, and the timing hardward and the bit-slice processor were on difference cards. When we put either card on a extender so we could connect a logic analyser, the delay added by the traces on the extender caused the problem to go away. It took two of a week to find the problem. The fix was to update the microcode ROMs for every computer that received the new timer card.
I'm a (very poor) touch typist. If you start radically altering the keyboard, you will seriously P.O. every touch typist out there because our muscle memory won't work with your keyboard. That means that they will be much less likely to buy your keyboard. By extension, if your keyboard happens to be attached to a laptop, they will be much less likely to buy your laptop. Maybe non-touch typists will be more likely to buy your wares and offset the loss of the touch typists. But maybe not - what if they dislike your changes? Bottom line: there's probably no great business advantage to changing the keyboard but there is a significant business risk, so ain't gonna happen.
If you have a good idea for a better keyboard, start a kickstarter campaign and build/market it yourself. You'll make a huge pile of money. Or not.
Not really. If you look at the likelihood of being in surgery when the network goes down, or the surgeon gets hacked, it's pretty much negligible. What does disturb me is the fact that major hacks are frequently reported as are gross vulnerabilities yet nothing seems to get done.
--
linquendum tondere
I've been wondering about this wireless charging business. It has to be less efficient than wired charging. Given the current push to reduce energy use, I'm at a loss to understand how people can be pushing wireless charging.
My first thought, when I read the summary, was of my co-workers, all male, wearing short skirts or low-cut dresses. I may have to gouge out my eyes.
My personal experience is that absent clear enforced rules, deportment degrades over time to unacceptable levels, at which point management institutes unpalatable rules. If you have freedom in deportment, enjoy it but be sensible.
Talking to the pros is only the worst thing to do if you know as much, if not more, than they do. The fact that the OP is asking slashdot indicates he does not know a lot about setting up storage in the PB range. Are the major vendors overpriced? In terms of the hardware you get, probably. In terms of the knowledge they bring to the table, probably NOT in the case of the OP. If you have someone who can select COTS components and effectively couple them with some good OS/SW, great. Otherwise, get someone who knows what they are doing and buy their solution. Doing it on your own when you don't know what you are doing will only end in tears.
From my perspective, the biggest problem with BYOD is that management is not likely to give IT the resources needed to ensure that BYOD is done in a secure manner. Personally, I will not bring my own device to work for a couple of reasons. First, why on earth would I subsidize my employer? Second, why on earth would I consider giving my employer any measure of control over my device?
This is not necessarily a problem. First off, the legality of some actions may depend on where the actions occurred. In the case of the drone, discharging a gun is illegal in some locales and legal in others. So, the authorities could well investigate where the drone was shooting. Second, law has gotten ridiculous; no cop - heck, no lawyer - is aware of all laws. See something new, like a privately owned drone firing a gun, maybe you want to check whether there are applicable laws. Now, fishing trips to find something with which to harass your ex, definitely a problem.
That's certainly an option. But keep in mind that if you upset them, they do have the ability to make your life very unpleasant every time you cross their path. I'm not saying not to do it, just that you should do a cost-benefit analysis on the concept before you do it.
What do you consider "reasonable" access? I tend to be very conservative about it. If I can do my job, I consider that reasonable access. Anything not strictly required to do my job is simply a bonus. Under those definitions, I've never had a job that did not afford me reasonable access to the internet. I know that many people will consider "reasonable" access to include things like access to Facebook and twitter and their bank accounts, etc. I disagree. When I'm at work, I'm working. When I'm not at work, I'm not at work. I try very hard to keep the boundary distinct. the more I blur the line, the easier it is for my employer to want me to be always available.
Exactly.
Even now, 2015, the vast majority of computer users are clueless. Since the nail that sticks up is the nail that gets hammered, I just hunker down. When (if) the majority of computer users clues in, I may change my policy. Until then, I keep quite. FWIW, if it was something truly urgent that really did require me to notify someone of an incorrect email address, I'd have my lawyer do the notification.
I'm not expecting that my boss will always do what I want. I will settle for the knowledge that when I say something, my boss actually pays attention to what I say and gives it fair consideration. If you want to lose me, ignore me (and then expect me to clean up the mess that occurred because you ignored me). Remember, you are the manager; you are NOT G-d. Your people do know more about some things than do you, and you know more about other things than do they. If you work together, you can maximize your strengths and minimize your weaknesses.
as long as you don't keep the weekly 1-on-1s running forever. They're great for a new manager to get to know his team. But the last thing I want to do is spend 15 to 30 minutes a week in an awkward meeting with my manager when we've nothing to discuss. Keep an eye on the number of meetings your developers are attending. If meetings regularly chew up a large chunk of developer time, you've got a problem. Conversely, if your developers never, or rarely, meet with anyone other than developers or you, you've also got a problem. Developers should be talking to their customers (i.e. the people for whom they are developing the software). Yes, in an ideal agile world, the customers would be right there with the developers. But, in 29 years (dang, has it been that long) as a developer, I've yet to encounter that.
If you really cannot do offices, one thing I've encountered that worked well was a "quiet" time. Essentially, a block of hours each day when no meetings would be accepted, no visitors or conversations allowed (emergencies excepted, of course). It's not perfect, of course, as there are plenty of dorks who think they are too important for such nonsense. But if everyone holds firm and enforces things ("I'm sorry, I cannot talk right now. Can I come by your desk at 2pm?") it can work.
In my current situation, we have all three of the developers, myself included, open plan in a single room with a real door. This works reasonably well. The people with whom we interact most are within very easy reach. Other folks are isolated from us.
Don't know how well this would work with, say, six or seven developers. But a handful of guys working on the same project - not bad.
Bonus: being able to close the door is good when we get a bit raucous or when we want to discuss things privately.
a process problem: either the process sucks or the prison staff are not following process. Release notices by email? By email from an unofficial email address? By unencrypted, undigitally-signed email from an unofficial email address?
Slashdot Mirror
Keep in mind that my time has value. The cumulative value of the time I wait could be significant over the course of a year.
Agreed, although a modern VCS really really helps avoid this. Wish I'd had GIT back in the '80s.
So what happens when a company screws up and clobbers the wrong company (or individual)? Think about it: when your servers are being attacked, how certain are you as to who the culprit is? Are the cops (or the feds) really going to put their best manpower on vetting the work you've done to track down the baddies? Or will that be where they stick their less capable people?
Bottom line, if someone clobbers your company by mistake, whom do you sue?
Two bugs come to mind, one that I wrote and fixed, one that I fixed but did not create. The one that I created was an assembler bug, code written in UKY-502 assembler (military computer). I screwed up one op code, specifying LK (load constant) instead of L (load from memory address). The difference in the code was one bit, but I had to single-step through the code to find the bug - took me hours for one stinking bit.
The other bug, also on the UYK-502 computer, was a bug in the micro-code. The guy who wrote the micro-code for one particular instruction had ignored the user guide for the bit-slice processor and had implemented a read-modify-write operation in a single micro-code instruction. It worked for him because the timing hardware was slow enough. Unfortunately, a couple of years later, the manufacturer of one of the chips in the timing hardware improved the internal workings of the chip so that one of the line dropped sooner than it did on older versions of the chip (NB: the chip still met the same specs - it was just faster). Debugging was a pain. The computer used a back-plane, and the timing hardward and the bit-slice processor were on difference cards. When we put either card on a extender so we could connect a logic analyser, the delay added by the traces on the extender caused the problem to go away. It took two of a week to find the problem. The fix was to update the microcode ROMs for every computer that received the new timer card.
I'm a (very poor) touch typist. If you start radically altering the keyboard, you will seriously P.O. every touch typist out there because our muscle memory won't work with your keyboard. That means that they will be much less likely to buy your keyboard. By extension, if your keyboard happens to be attached to a laptop, they will be much less likely to buy your laptop. Maybe non-touch typists will be more likely to buy your wares and offset the loss of the touch typists. But maybe not - what if they dislike your changes? Bottom line: there's probably no great business advantage to changing the keyboard but there is a significant business risk, so ain't gonna happen.
If you have a good idea for a better keyboard, start a kickstarter campaign and build/market it yourself. You'll make a huge pile of money. Or not.
Not really. If you look at the likelihood of being in surgery when the network goes down, or the surgeon gets hacked, it's pretty much negligible. What does disturb me is the fact that major hacks are frequently reported as are gross vulnerabilities yet nothing seems to get done. -- linquendum tondere
I've been wondering about this wireless charging business. It has to be less efficient than wired charging. Given the current push to reduce energy use, I'm at a loss to understand how people can be pushing wireless charging.
... is one who, once bought, stays bought.
My first thought, when I read the summary, was of my co-workers, all male, wearing short skirts or low-cut dresses. I may have to gouge out my eyes.
My personal experience is that absent clear enforced rules, deportment degrades over time to unacceptable levels, at which point management institutes unpalatable rules. If you have freedom in deportment, enjoy it but be sensible.
...why any "standard" would include patented technology. Seems like a very stupid idea. About the same as copyrighting the spelling of words.
Talking to the pros is only the worst thing to do if you know as much, if not more, than they do. The fact that the OP is asking slashdot indicates he does not know a lot about setting up storage in the PB range. Are the major vendors overpriced? In terms of the hardware you get, probably. In terms of the knowledge they bring to the table, probably NOT in the case of the OP. If you have someone who can select COTS components and effectively couple them with some good OS/SW, great. Otherwise, get someone who knows what they are doing and buy their solution. Doing it on your own when you don't know what you are doing will only end in tears.
From my perspective, the biggest problem with BYOD is that management is not likely to give IT the resources needed to ensure that BYOD is done in a secure manner. Personally, I will not bring my own device to work for a couple of reasons. First, why on earth would I subsidize my employer? Second, why on earth would I consider giving my employer any measure of control over my device?
This is not necessarily a problem. First off, the legality of some actions may depend on where the actions occurred. In the case of the drone, discharging a gun is illegal in some locales and legal in others. So, the authorities could well investigate where the drone was shooting. Second, law has gotten ridiculous; no cop - heck, no lawyer - is aware of all laws. See something new, like a privately owned drone firing a gun, maybe you want to check whether there are applicable laws. Now, fishing trips to find something with which to harass your ex, definitely a problem.
... but if you do it without Stupid's permission, Stupid may get angry.
That's certainly an option. But keep in mind that if you upset them, they do have the ability to make your life very unpleasant every time you cross their path. I'm not saying not to do it, just that you should do a cost-benefit analysis on the concept before you do it.
"The cloud is still basically a v1.0 product." Begging your pardon, but the cloud is really still 0.X.
Time to ban kitchen tables.
What do you consider "reasonable" access? I tend to be very conservative about it. If I can do my job, I consider that reasonable access. Anything not strictly required to do my job is simply a bonus. Under those definitions, I've never had a job that did not afford me reasonable access to the internet. I know that many people will consider "reasonable" access to include things like access to Facebook and twitter and their bank accounts, etc. I disagree. When I'm at work, I'm working. When I'm not at work, I'm not at work. I try very hard to keep the boundary distinct. the more I blur the line, the easier it is for my employer to want me to be always available.
Exactly. Even now, 2015, the vast majority of computer users are clueless. Since the nail that sticks up is the nail that gets hammered, I just hunker down. When (if) the majority of computer users clues in, I may change my policy. Until then, I keep quite. FWIW, if it was something truly urgent that really did require me to notify someone of an incorrect email address, I'd have my lawyer do the notification.
I'm not expecting that my boss will always do what I want. I will settle for the knowledge that when I say something, my boss actually pays attention to what I say and gives it fair consideration. If you want to lose me, ignore me (and then expect me to clean up the mess that occurred because you ignored me). Remember, you are the manager; you are NOT G-d. Your people do know more about some things than do you, and you know more about other things than do they. If you work together, you can maximize your strengths and minimize your weaknesses.
as long as you don't keep the weekly 1-on-1s running forever. They're great for a new manager to get to know his team. But the last thing I want to do is spend 15 to 30 minutes a week in an awkward meeting with my manager when we've nothing to discuss. Keep an eye on the number of meetings your developers are attending. If meetings regularly chew up a large chunk of developer time, you've got a problem. Conversely, if your developers never, or rarely, meet with anyone other than developers or you, you've also got a problem. Developers should be talking to their customers (i.e. the people for whom they are developing the software). Yes, in an ideal agile world, the customers would be right there with the developers. But, in 29 years (dang, has it been that long) as a developer, I've yet to encounter that.
If you really cannot do offices, one thing I've encountered that worked well was a "quiet" time. Essentially, a block of hours each day when no meetings would be accepted, no visitors or conversations allowed (emergencies excepted, of course). It's not perfect, of course, as there are plenty of dorks who think they are too important for such nonsense. But if everyone holds firm and enforces things ("I'm sorry, I cannot talk right now. Can I come by your desk at 2pm?") it can work.
In my current situation, we have all three of the developers, myself included, open plan in a single room with a real door. This works reasonably well. The people with whom we interact most are within very easy reach. Other folks are isolated from us. Don't know how well this would work with, say, six or seven developers. But a handful of guys working on the same project - not bad. Bonus: being able to close the door is good when we get a bit raucous or when we want to discuss things privately.
a process problem: either the process sucks or the prison staff are not following process.
Release notices by email? By email from an unofficial email address? By unencrypted, undigitally-signed email from an unofficial email address?
If something goes wrong, you're carrying a boatload of highly flammable material while playing with fire. Sounds like a setup for a Darwin award.