Why would the phone need special support? Every phone has a burned-in IMEI. So the subscriber registers the IMEI to their subscriber ID (IMSI) when they activate their phone. It can even be automated: when a SIM's issued to a subscriber, the first time it's put in a phone the carrier associates that phone's IMEI with the IMSI. Then, when the subscriber reports his phone stolen, the carrier publishes the IMEI to a database. All carriers check that database, and when an IMEI that appears in the database tries to connect to their network they reject it. The phone can still be used stand-alone, but how useful is a cel phone that can't connect to a network? And of course since the carrier now knows at least the cel tower the phone's connecting to if not the actual GPS coordinates, it's easy for them to forward the location to the local police and if there's a unit in the vicinity not doing anything more important they just got an easy bust. And maybe a big one, if the cel phone was being used by criminals because it was stolen and not directly traceable back to them. If the phone sent GPS coordinates you've got air-tight probabl cause: you know the phone's been reported stolen, you know it's at this location, that means that whoever's got it has to be at least receiving stolen property and that should more than satisfy any judge as probable cause to search the place. No phone support for any of this needed, it's all carrier-side and can't be bypassed short of disabling the radio in the phone so it can't connect to a carrier's network (which kind of defeats the purpose of stealing a cel phone in the first place).
Actually the first thing I'd do is design and build things to prevent the attacker from getting in in the first place. Yes, vulnerabilities will always exist. But it's possible to mitigate them before they're exploited, by for instance not exposing services where an attacker can access them, or by designing your services from the beginning to be resistant to types of attacks. This may require avoiding common ways of speeding up development, but... "Fast, cheap, right. Pick any 2.".
If I was attacked, I'd definitely take action. But you're trying to set up a false set of choices. I'd pick the third choice: get angry, do some investigation, and take appropriate legal action of my own against the identified attacker. If it's a zombie box, the owner's still responsible and we can work backwards from there to the real attacker. Just trashing a throwaway zombie box may be viscerally satisfying, but the real attacker considered it disposable anyway so you've done no real harm to him. All you've done is angered the public and exposed yourself to liability, leaving the real attacker unscathed and laughing at you. If you're lucky you'll merely pay out a lot of money to make the mess go away. If you aren't lucky, you may have those authorities you disparage putting you in their sights because of pressure from politicians who're nervous about public backlash. And if you're really unlucky, your attacker will decide to teach you a lesson and hit you again, this time really trashing your systems. Working within the legal framework to identify the responsible parties, while not nearly as immediately satisfying, can get you the real culprit while keeping both the public and the authorities firmly on your side, which in turn will let you get your pound of flesh from the attacker easier than if you're fighting the attacker and the public and the authorities at the same time.
The question is really going to be what kind of shape the drives will be in a year or so from now after 12+ months of constant heavy usage. The usage profile in consumer computers is a lot different from that in a server, and the server workload's going to stress more of the weakest areas of SSDs. And when it comes to manufacturer or lab test results, simple rule: "The absolute worst-case conditions achievable in the lab won't begin to approximate normal operating conditions in the field.". So, while SSDs are definitely worth looking at, I'll let someone else to do the 24-36 month real-workload stress testing on them. There's a reason they call it the bleeding edge after all.
If they're amenable to that, then there should be a rough listing of the terms they're willing to license the software on. There's simply a lot of software out there for any given application, more than I can reasonably sort through honestly, and one of my first filters is "Does it tell me what terms I can use it on?". Anything that doesn't, I can skip. If I don't find anything I can use that gives clear terms, then I may go back through the most promising of the rest and dig further into getting it.
As far as understanding licenses, my position is that if you're putting it out there in public you'd better have at least a basic understanding of copyright and licenses. Anyone who doesn't, probably also doesn't have enough development experience to put out something I can use readily. There may be exceptions, but again there's such a huge volume of software that I have to filter somehow and regardless of technical quality I probably don't want to deal with the legal tangle that comes with trying to license something from someone who doesn't understand licensing.
It's the same as with vendors: if they don't understand basic contracts, their product has to be really really special to make it worth dealing with them instead of one of the dozen other vendors who do know how to negotiate a contract.
Here's the other thing: without a license I can't use a copy. All software is copyrighted by default, unless there's an explicit dedication to the public domain. Absent a license, only the author of the software may make and distribute copies of it. So with no license on the software I'm OK looking at it on Github of the like, but making a copy of it onto my machine to build, use and redistribute as part of my own software is right out. I have no license from the copyright holder to make and distribute those copies. So if your software doesn't include a license? I can't safely touch it nor can I use it.
If you want to put no restrictions on reuse of your code, put it under something like the BSD or Apache license. But if you don't put it under some license, it's automatically under a license that says "You may not copy or redistribute this work, nor may you make and distribute works based on or derived from this work.".
Thing is, most of the "hack back" responses don't involve going after the hacker still in your system. They boil down to trying to figure out who the hacker is, where they live, and then going to that address and attacking whoever's there. Which of course raises such issues as "Did your attacker leave a false trail that would lead you to attack someone not involved in the attack on you?" and "What are you going to do if that uninvolved party decides to hack back themselves?". Few of the proponents of "hack back" seem willing to discuss those issues, they mostly brush them off as "That won't happen.". When probed as to exactly what it won't and what'll keep it from happening, though, they start flailing badly rather than giving coherent answers. And none of them want to commit to accepting full legal liability if it does happen. If it won't happen, what's the problem with agreeing to accept a liability you'll never need to accept?
Someone was assigned to go through and clean up all the loose ends from Java 6, move them away from public access and into the paid-support area. Reasonable, J6 isn't supported and people should be discouraged from depending on it.
tzupdater is listed under Java 6, so got flagged for cleanup.
Nobody twigged to the fact that tzupdater, while listed under J6, is actually version-agnostic and applies to Java 5 through 7 (they all use the same format for zoneinfo files, the format output by javazic).
I've had this happen many times at work. We'll have something created for one purpose, and as time goes by it gets used for other things. It's use is documented in the records for those other things, but the original documentation never gets updated. Eventually the original project becomes obsolete and gets removed, and people go by it's documentation to decide what related things should be removed along with it. Zany hijinks ensue. Which is why I always push for a second review of things like that, with an emphasis on searching all the code for the references people don't think exist that really do. Paranoia: it's not the law, it's just a good idea.
Seriously, they have nobody reviewing these things? That scares me more than the idea that it was deliberate.
Meanwhile, what I want isn't actually tzupdater. What I want's a tool that'll automatically pull down, compile and install the latest tzdata package from IANA into all JRE/JDK installations in the standard locations. The compile and install parts are already there, just need the download part and a search for folders to install in.
First off, the budget should be a non-issue. All the CFO's saying there is "IT's more expensive than I think it should be.". Well, that's usually the case. Not because IT's spending too much, but because non-IT management often underestimates how much IT really costs. And in any case, budgeting is the CFO's field. He shouldn't need to be bringing in outside consultants to handle that. I'd push that part aside for later.
As for the head of IT lacking technical skills and "parroting" what his technical people tell him, WTF? First, the head of IT isn't a technical person. He can't be completely oblivious, but his job's mostly organizing things and interacting with management. He has technical people under him who know the technology and are supposed to be giving him advice on the technical details. And it's considered a problem when he's listening to them and taking their advice? Sorry, as a technical person my first reaction is that the problem there isn't with the head of IT, it's with the outsider who's saying the head of IT should be ignoring and not trusting his own technical people.
Now, the IT department being ineffective, that's a valid point to look at. But by what metrics? What are they being expected to do, what resources are they being given to do it, and where and how are they failing to get the job done? If the CFO's moaning about costs, have you considered that the IT department may be being asked to do a lot and then not be being given the resources (budget, staff headcount, training, software packages, documentation, support contracts) needed to do the job? All too often I've seen IT departments where management's cut staffing by 50%, doubled the amount of work they want done, and then been shocked when projects don't meet deadline or fail completely. If the head of IT's really responsible for the failures, you should be able to lay out the resource allocation vs. the project load and show the failures. That's where I'd start my research. And I wouldn't start by assuming any particular cause, I can't judge that until I've gotten the information laid out.
As far as the IT department being loathed, again I'd start by asking why. More often than I can count I've found myself on the receiving end of vitriol from other departments because I'm forcing them to get work done by the deadline they promised when they really don't want to do it. I've also found my self on the receiving end of similar vitriol when someone in Marketing has promised a new feature or product and I won't back down from a position of "We're already at 150% resource allocation. If you want this new project done by the deadline you specified, we need to postpone at least 3 other projects to free up the needed time and resources. Which 3 do you want us to postpone?". If IT's loathed by other departments, first start by figuring out whether they're loathed because they're being jerks, or merely because they're doing their jobs and other departments don't like it when they don't get their way. If it's the former, then HR and not the CFO needs to be involved. If it's the latter, then it's the other departments that need talked to about what their responsibilities and obligations are.
It's a three-layer process. Devs themselves are expected to adhere to the rules. Then the subsystem maintainers are supposed to filter changes to their subsystems. And finally Linus is the final arbiter on what gets merged into the release branch. Technically devs can check in anything they want, but it has to go through the subsystem maintainers and Linus to get into the release. Linus' role here is prodding the subsystem maintainers and the devs themselves to remember the rules and stop sending him so many things to sort through. It's easier on him if it's 90% rubber-stamp approvals and if a few stragglers get through it's not causing any widespread issues, as opposed to if it's 50% cruft and if he doesn't scrutinize everything carefully it's going to be a mess.
Because people aren't sending him fixes for concerns that have to be addressed before the release. They're sending him "this is a bit messy, here's code that looks a bit cleaner" or "it works but I don't like it so here's a different way to do the same thing". And sometimes as the manager you have to smack the devs with the cluebat to get them to remember that it doesn't matter if the code's messy or ugly, it doesn't matter if there's another way to do it, it doesn't matter if there's a better way to do it, by the time you're at the release-candidate stage the only things you should be sending in changes for are fixes for the things that're actually not working right. If you don't, they'll keep tweaking forever and you'll never get a release. As a dev myself I can understand where Linus is coming from here. I doubt he's even really mad at anyone, just irritated at everyone and issuing a pointed reminder that there's a difference between what the devs want to do and what they ought to be doing before he does have to get mad at anyone.
Oh, and I noticed that updating to Java 7 will not get you the current timezone data. The latest Java 7 packages are using tzdata from 2012i, current is 2013c. So even if you're using Java 7, you need to run tzupdater to bring you current or compile the javazic tool and build your own zoneinfo files.
What's keeping me on Windows? Office and.Net. My employer requires Word, Excel and Outlook. Those packages are designed to make it infeasible for any other software to correctly handle their files and interoperate with all the exotic features of Exchange. Plus some of their Web applications are designed to operate only with IE6 (to the point where they don't work correctly with IE7+). And the software I need to work on's written in C#/.Net using Windows-only libraries from MS on top of it. Note that none of the functionality's Windows-only, but the non-functional requirements preclude any non-Windows OS.
What's keeping me off Windows? Posix. The older software (that's still handling the bulk of the workload) is C++ using Posix APIs, and Windows simply doesn't have the Posix support to let it compile. Considering the sheer bulk of accumulated code and features in the old software, I don't see it going away any time soon. Not to mention that Windows doesn't have the performance to handle the workload. No, I'm not joking here, we've literally made Windows boxes fall over handling a workload that's just beginning to make smaller and less powerful Unix servers break a sweat. I don't see Windows gaining a high-quality Posix subsystem any time soon, nor of getting an order-of-magnitude improvement in performance, so.
Which all translates to my sitting on a Windows machine spending 90% of my time in Cygwin using Unix tools to do Unix software development, using terminal windows to run/debug the software on Unix servers.
The tzupdater's applicable to Java 7 as well. I'm interested in a replacement for two reasons:
So I can automatically sync my Java installations with my Unix tzdata, getting timezone updates sooner than new JRE/JDK releases.
So I can keep timezone information updated for Java 7 when it stops getting updates, as well as for Java 6. For some stuff I don't have the luxury of updating to Java 7 because Java 6 is mandated for it (corporate rules, I don't get to change them).
Hmm. Oh, look, OpenJDK 7 jdk\make\tools\src\build\tools\javazic has source code for a tool to... compile Olson tzdata into Java zi format. Well then. Problem solved, it looks like.
Check me, but Java uses the Olson tzdata files as it's base. So is there enough documentation on the format of the files in Java's lib/zi directory tree to create a tool for converting the current tzdata package to something Java can use? That'd be the route I'd take, possibly looking at the OpenJDK source code to see if there's useful information there.
The ideal route would be to replace the standard Java classes with ones that used the Olson database directly, but the way the JRE packages classes that's probably infeasible.
Unless of course the admins have turned IMAP support off. You can do that, you know.
My reason for wanting a "real" e-mail client is simple: I want local copies of e-mail that aren't subject to corporate deletion policies and that won't be subject to going away if the company decides to change e-mail providers. If it's HR stuff related to my job, I do not want it to disappear until at least 7 years after I've left that job. If it's stuff like project requirements and the discussion that led to them, I want it filed and retained until the project in question is decommissioned (there's copies in the documentation for the project, but I want my copies where I can get them regardless of what anyone's done to the official documentation). Google's great and all, but e-mail there is at the mercy of the admins and of course if the company decides to not use Google anymore there's the issue of getting all the e-mail out before it goes away.
Isn't society entitled to know whether you committed the murder or not?
Yes, it is. But society has also decided that it's the prosecution's job to show a) that a murder was committed and b) that you committed it. It's not your job as the defendant to prove the prosecution's case for them. What that part of the 5th Amendment boils down to is that the prosecution can't compel you to confess to a crime.
There's also the double-bind situation. Suppose you didn't in fact commit the crime. The prosecution demands that you confess to it. If you do, you go to jail. If you don't, the prosecution charges you with felonies starting with lying to a Federal agent in the course of an investigation and you go to jail. The only way out is for you to prove you didn't commit the crime, and as a society we've decided that it's not the job of the innocent person to prove their innocence, it's the job of the prosecution to prove their guilt.
Net access on my phone is through the cellular network, no cable involved. The same network used for voice. The only way to change that is to block all cel network access inside the car and force all phones to go through the car's cel relay. But that'd involve 1) an expensive bit of hardware in the car to create a mini cel tower and 2) forcing everyone to replace their phones with ones that can route voice and data through the USB cable (mine can't, the USB connection is for block storage device and serial data only, it takes some special software to fool the phone into thinking the USB connection is a 3G cel data interface plus you have to root the phone to do it and it doesn't route voice). So no, that's not going to work.
So how would this proposed system distinguish between the driver using a phone and a passenger using a phone? It's not reasonable to forbid every passenger (who's not driving and has no need to not be distracted) from using any device while someone else is driving.
I'm wondering, though. For package goods it's fine. For perishables like meat, dairy, refrigerated goods and so on, it's a bit more complicated. The supermarkets (Vons in my area) already have the distribution network and storage in place in every store they have. All they need to do for delivery is pick the stuff off the shelves (or out of the back room before it goes on the shelves), put it in a truck and go. It'll be interesting to see how Amazon deals with keeping perishable goods in stock close enough to the destination to make it through delivery intact.
Users are really bad about giving you abstract descriptions of exactly what they want. But they're really good at telling you what parts of an existing system they're using are working well, what parts aren't and how they'd prefer the bad parts to work. So get a rough prototype into their hands early, get that feedback, modify your design to keep the good parts and change the bad parts to be more what the users prefer. Lather rinse repeat.
Requirements will change over time. Early on they'll change faster, but change they will over the entire life of the project. Build that into your processes. Favor designs that'll let you implement just the basic functionality at the beginning without preventing you from adding the more exotic/complex parts later.
And finally, management has to accept that there is no magic here. Accommodating changes requires work. If they're building a 4-story building and they suddenly want 6 stories, the foundations and framework will need to be reworked. You can do the work up-front, over-designing the foundations and framework to accommodate a potentially taller building before construction starts, or you can do the work later when you have to tear up the lower floors to re-do the foundations and load-bearing framework, but snapping your fingers and magically making foundations designed just big enough for a 4-story building suddenly support 6... we're not Harry Potter, this ain't Hogwarts, and the Burrow just won't stay standing in real life.
From personal experience, it depends on how much knowledge of the final requirements you've got. One thing you've got going for you that the initial team didn't is the initial work they did figuring out requirements. They may not have produced a workable result, but the Agile team you're "rescuing" almost certainly accumulated a lot of information about what exactly's needed in the final product. You get to base your design off of that.
The hard part of course is where you aren't rescuing another team and don't have all the information they accumulated. That's where waterfall breaks down, because it's hard to do the whole design when you don't have much clue what you actually need to build. You have to do a lot of thinking and basically sketch out almost the entire final system, and that takes more time than management's usually willing to allow without seeing some kind of results (which you won't have because until your design's finished you can't start coding and producing what management would call results). Bear in mind that waterfall development got a bad rep precisely because of an accumulated history of failed projects, missed deliveries and products that didn't do what was needed (there's a lot of truth to the line from a filksong "It's just what we asked for / but not what we want."). Don't ask how many times we've started into things only to find out about huge areas that nobody even thought existed.
Simply put, if you're doing something that hasn't been done before you need to do a lot of exploration to figure out what the users really want and what the best way of doing it is. Agile didn't just pull the idea out of thin air, it came from the acceptance of decades of hard experience: on a non-trivial project you do not know and can not know all the requirements and gotchas going into it. The problem is often that management doesn't accept this, and they tend to panic just at the point in an Agile project where the developers have finally gotten a good handle on the requirements and are in a position to nail down a good design and start working towards it. That's compounded by a lot of Agile teams not having group buy-in on a single design and set of requirements. You don't have to get everybody to agree on what the best design is, but you do have to get everyone to agree on what the design will be for this project. When you don't, when you get every developer with their own idea of how it should work, it all falls apart.
Some do. Which is a distinction I clearly drew in the post you responded to, apparently without reading all of it.
No, because it's a distinction you can't draw. There's a line from a Dr. Who episode: "Not every shadow, just any shadow.". The same applies to attackers. Not every attacker will know the details, but any attacker may. And since by the time you know whether any particular attacker knows the details or not it's too late to defend, you have to assume that any attacker knows and defend yourself before the attack starts.
And in this age of attack toolkits that get regular updates, once one attacker knows the details and creates the attack modules any other attacker is just one toolkit update away from having the attack too.
Slashdot Mirror
Why would the phone need special support? Every phone has a burned-in IMEI. So the subscriber registers the IMEI to their subscriber ID (IMSI) when they activate their phone. It can even be automated: when a SIM's issued to a subscriber, the first time it's put in a phone the carrier associates that phone's IMEI with the IMSI. Then, when the subscriber reports his phone stolen, the carrier publishes the IMEI to a database. All carriers check that database, and when an IMEI that appears in the database tries to connect to their network they reject it. The phone can still be used stand-alone, but how useful is a cel phone that can't connect to a network? And of course since the carrier now knows at least the cel tower the phone's connecting to if not the actual GPS coordinates, it's easy for them to forward the location to the local police and if there's a unit in the vicinity not doing anything more important they just got an easy bust. And maybe a big one, if the cel phone was being used by criminals because it was stolen and not directly traceable back to them. If the phone sent GPS coordinates you've got air-tight probabl cause: you know the phone's been reported stolen, you know it's at this location, that means that whoever's got it has to be at least receiving stolen property and that should more than satisfy any judge as probable cause to search the place. No phone support for any of this needed, it's all carrier-side and can't be bypassed short of disabling the radio in the phone so it can't connect to a carrier's network (which kind of defeats the purpose of stealing a cel phone in the first place).
Actually the first thing I'd do is design and build things to prevent the attacker from getting in in the first place. Yes, vulnerabilities will always exist. But it's possible to mitigate them before they're exploited, by for instance not exposing services where an attacker can access them, or by designing your services from the beginning to be resistant to types of attacks. This may require avoiding common ways of speeding up development, but... "Fast, cheap, right. Pick any 2.".
If I was attacked, I'd definitely take action. But you're trying to set up a false set of choices. I'd pick the third choice: get angry, do some investigation, and take appropriate legal action of my own against the identified attacker. If it's a zombie box, the owner's still responsible and we can work backwards from there to the real attacker. Just trashing a throwaway zombie box may be viscerally satisfying, but the real attacker considered it disposable anyway so you've done no real harm to him. All you've done is angered the public and exposed yourself to liability, leaving the real attacker unscathed and laughing at you. If you're lucky you'll merely pay out a lot of money to make the mess go away. If you aren't lucky, you may have those authorities you disparage putting you in their sights because of pressure from politicians who're nervous about public backlash. And if you're really unlucky, your attacker will decide to teach you a lesson and hit you again, this time really trashing your systems. Working within the legal framework to identify the responsible parties, while not nearly as immediately satisfying, can get you the real culprit while keeping both the public and the authorities firmly on your side, which in turn will let you get your pound of flesh from the attacker easier than if you're fighting the attacker and the public and the authorities at the same time.
The question is really going to be what kind of shape the drives will be in a year or so from now after 12+ months of constant heavy usage. The usage profile in consumer computers is a lot different from that in a server, and the server workload's going to stress more of the weakest areas of SSDs. And when it comes to manufacturer or lab test results, simple rule: "The absolute worst-case conditions achievable in the lab won't begin to approximate normal operating conditions in the field.". So, while SSDs are definitely worth looking at, I'll let someone else to do the 24-36 month real-workload stress testing on them. There's a reason they call it the bleeding edge after all.
If they're amenable to that, then there should be a rough listing of the terms they're willing to license the software on. There's simply a lot of software out there for any given application, more than I can reasonably sort through honestly, and one of my first filters is "Does it tell me what terms I can use it on?". Anything that doesn't, I can skip. If I don't find anything I can use that gives clear terms, then I may go back through the most promising of the rest and dig further into getting it.
As far as understanding licenses, my position is that if you're putting it out there in public you'd better have at least a basic understanding of copyright and licenses. Anyone who doesn't, probably also doesn't have enough development experience to put out something I can use readily. There may be exceptions, but again there's such a huge volume of software that I have to filter somehow and regardless of technical quality I probably don't want to deal with the legal tangle that comes with trying to license something from someone who doesn't understand licensing.
It's the same as with vendors: if they don't understand basic contracts, their product has to be really really special to make it worth dealing with them instead of one of the dozen other vendors who do know how to negotiate a contract.
Here's the other thing: without a license I can't use a copy. All software is copyrighted by default, unless there's an explicit dedication to the public domain. Absent a license, only the author of the software may make and distribute copies of it. So with no license on the software I'm OK looking at it on Github of the like, but making a copy of it onto my machine to build, use and redistribute as part of my own software is right out. I have no license from the copyright holder to make and distribute those copies. So if your software doesn't include a license? I can't safely touch it nor can I use it.
If you want to put no restrictions on reuse of your code, put it under something like the BSD or Apache license. But if you don't put it under some license, it's automatically under a license that says "You may not copy or redistribute this work, nor may you make and distribute works based on or derived from this work.".
Thing is, most of the "hack back" responses don't involve going after the hacker still in your system. They boil down to trying to figure out who the hacker is, where they live, and then going to that address and attacking whoever's there. Which of course raises such issues as "Did your attacker leave a false trail that would lead you to attack someone not involved in the attack on you?" and "What are you going to do if that uninvolved party decides to hack back themselves?". Few of the proponents of "hack back" seem willing to discuss those issues, they mostly brush them off as "That won't happen.". When probed as to exactly what it won't and what'll keep it from happening, though, they start flailing badly rather than giving coherent answers. And none of them want to commit to accepting full legal liability if it does happen. If it won't happen, what's the problem with agreeing to accept a liability you'll never need to accept?
As near as I can tell, what happened is:
I've had this happen many times at work. We'll have something created for one purpose, and as time goes by it gets used for other things. It's use is documented in the records for those other things, but the original documentation never gets updated. Eventually the original project becomes obsolete and gets removed, and people go by it's documentation to decide what related things should be removed along with it. Zany hijinks ensue. Which is why I always push for a second review of things like that, with an emphasis on searching all the code for the references people don't think exist that really do. Paranoia: it's not the law, it's just a good idea.
Seriously, they have nobody reviewing these things? That scares me more than the idea that it was deliberate.
Meanwhile, what I want isn't actually tzupdater. What I want's a tool that'll automatically pull down, compile and install the latest tzdata package from IANA into all JRE/JDK installations in the standard locations. The compile and install parts are already there, just need the download part and a search for folders to install in.
Question: what's the ROI on the janitorial staff?
Second question: how many people would want to work at a company that couldn't keep their restrooms clean and their trash cans emptied?
First off, the budget should be a non-issue. All the CFO's saying there is "IT's more expensive than I think it should be.". Well, that's usually the case. Not because IT's spending too much, but because non-IT management often underestimates how much IT really costs. And in any case, budgeting is the CFO's field. He shouldn't need to be bringing in outside consultants to handle that. I'd push that part aside for later.
As for the head of IT lacking technical skills and "parroting" what his technical people tell him, WTF? First, the head of IT isn't a technical person. He can't be completely oblivious, but his job's mostly organizing things and interacting with management. He has technical people under him who know the technology and are supposed to be giving him advice on the technical details. And it's considered a problem when he's listening to them and taking their advice? Sorry, as a technical person my first reaction is that the problem there isn't with the head of IT, it's with the outsider who's saying the head of IT should be ignoring and not trusting his own technical people.
Now, the IT department being ineffective, that's a valid point to look at. But by what metrics? What are they being expected to do, what resources are they being given to do it, and where and how are they failing to get the job done? If the CFO's moaning about costs, have you considered that the IT department may be being asked to do a lot and then not be being given the resources (budget, staff headcount, training, software packages, documentation, support contracts) needed to do the job? All too often I've seen IT departments where management's cut staffing by 50%, doubled the amount of work they want done, and then been shocked when projects don't meet deadline or fail completely. If the head of IT's really responsible for the failures, you should be able to lay out the resource allocation vs. the project load and show the failures. That's where I'd start my research. And I wouldn't start by assuming any particular cause, I can't judge that until I've gotten the information laid out.
As far as the IT department being loathed, again I'd start by asking why. More often than I can count I've found myself on the receiving end of vitriol from other departments because I'm forcing them to get work done by the deadline they promised when they really don't want to do it. I've also found my self on the receiving end of similar vitriol when someone in Marketing has promised a new feature or product and I won't back down from a position of "We're already at 150% resource allocation. If you want this new project done by the deadline you specified, we need to postpone at least 3 other projects to free up the needed time and resources. Which 3 do you want us to postpone?". If IT's loathed by other departments, first start by figuring out whether they're loathed because they're being jerks, or merely because they're doing their jobs and other departments don't like it when they don't get their way. If it's the former, then HR and not the CFO needs to be involved. If it's the latter, then it's the other departments that need talked to about what their responsibilities and obligations are.
It's a three-layer process. Devs themselves are expected to adhere to the rules. Then the subsystem maintainers are supposed to filter changes to their subsystems. And finally Linus is the final arbiter on what gets merged into the release branch. Technically devs can check in anything they want, but it has to go through the subsystem maintainers and Linus to get into the release. Linus' role here is prodding the subsystem maintainers and the devs themselves to remember the rules and stop sending him so many things to sort through. It's easier on him if it's 90% rubber-stamp approvals and if a few stragglers get through it's not causing any widespread issues, as opposed to if it's 50% cruft and if he doesn't scrutinize everything carefully it's going to be a mess.
Because people aren't sending him fixes for concerns that have to be addressed before the release. They're sending him "this is a bit messy, here's code that looks a bit cleaner" or "it works but I don't like it so here's a different way to do the same thing". And sometimes as the manager you have to smack the devs with the cluebat to get them to remember that it doesn't matter if the code's messy or ugly, it doesn't matter if there's another way to do it, it doesn't matter if there's a better way to do it, by the time you're at the release-candidate stage the only things you should be sending in changes for are fixes for the things that're actually not working right. If you don't, they'll keep tweaking forever and you'll never get a release. As a dev myself I can understand where Linus is coming from here. I doubt he's even really mad at anyone, just irritated at everyone and issuing a pointed reminder that there's a difference between what the devs want to do and what they ought to be doing before he does have to get mad at anyone.
Oh, and I noticed that updating to Java 7 will not get you the current timezone data. The latest Java 7 packages are using tzdata from 2012i, current is 2013c. So even if you're using Java 7, you need to run tzupdater to bring you current or compile the javazic tool and build your own zoneinfo files.
What's keeping me on Windows? Office and .Net. My employer requires Word, Excel and Outlook. Those packages are designed to make it infeasible for any other software to correctly handle their files and interoperate with all the exotic features of Exchange. Plus some of their Web applications are designed to operate only with IE6 (to the point where they don't work correctly with IE7+). And the software I need to work on's written in C#/.Net using Windows-only libraries from MS on top of it. Note that none of the functionality's Windows-only, but the non-functional requirements preclude any non-Windows OS.
What's keeping me off Windows? Posix. The older software (that's still handling the bulk of the workload) is C++ using Posix APIs, and Windows simply doesn't have the Posix support to let it compile. Considering the sheer bulk of accumulated code and features in the old software, I don't see it going away any time soon. Not to mention that Windows doesn't have the performance to handle the workload. No, I'm not joking here, we've literally made Windows boxes fall over handling a workload that's just beginning to make smaller and less powerful Unix servers break a sweat. I don't see Windows gaining a high-quality Posix subsystem any time soon, nor of getting an order-of-magnitude improvement in performance, so.
Which all translates to my sitting on a Windows machine spending 90% of my time in Cygwin using Unix tools to do Unix software development, using terminal windows to run/debug the software on Unix servers.
The tzupdater's applicable to Java 7 as well. I'm interested in a replacement for two reasons:
Hmm. Oh, look, OpenJDK 7 jdk\make\tools\src\build\tools\javazic has source code for a tool to... compile Olson tzdata into Java zi format. Well then. Problem solved, it looks like.
Check me, but Java uses the Olson tzdata files as it's base. So is there enough documentation on the format of the files in Java's lib/zi directory tree to create a tool for converting the current tzdata package to something Java can use? That'd be the route I'd take, possibly looking at the OpenJDK source code to see if there's useful information there.
The ideal route would be to replace the standard Java classes with ones that used the Olson database directly, but the way the JRE packages classes that's probably infeasible.
Unless of course the admins have turned IMAP support off. You can do that, you know.
My reason for wanting a "real" e-mail client is simple: I want local copies of e-mail that aren't subject to corporate deletion policies and that won't be subject to going away if the company decides to change e-mail providers. If it's HR stuff related to my job, I do not want it to disappear until at least 7 years after I've left that job. If it's stuff like project requirements and the discussion that led to them, I want it filed and retained until the project in question is decommissioned (there's copies in the documentation for the project, but I want my copies where I can get them regardless of what anyone's done to the official documentation). Google's great and all, but e-mail there is at the mercy of the admins and of course if the company decides to not use Google anymore there's the issue of getting all the e-mail out before it goes away.
Yes, it is. But society has also decided that it's the prosecution's job to show a) that a murder was committed and b) that you committed it. It's not your job as the defendant to prove the prosecution's case for them. What that part of the 5th Amendment boils down to is that the prosecution can't compel you to confess to a crime.
There's also the double-bind situation. Suppose you didn't in fact commit the crime. The prosecution demands that you confess to it. If you do, you go to jail. If you don't, the prosecution charges you with felonies starting with lying to a Federal agent in the course of an investigation and you go to jail. The only way out is for you to prove you didn't commit the crime, and as a society we've decided that it's not the job of the innocent person to prove their innocence, it's the job of the prosecution to prove their guilt.
Net access on my phone is through the cellular network, no cable involved. The same network used for voice. The only way to change that is to block all cel network access inside the car and force all phones to go through the car's cel relay. But that'd involve 1) an expensive bit of hardware in the car to create a mini cel tower and 2) forcing everyone to replace their phones with ones that can route voice and data through the USB cable (mine can't, the USB connection is for block storage device and serial data only, it takes some special software to fool the phone into thinking the USB connection is a 3G cel data interface plus you have to root the phone to do it and it doesn't route voice). So no, that's not going to work.
So how would this proposed system distinguish between the driver using a phone and a passenger using a phone? It's not reasonable to forbid every passenger (who's not driving and has no need to not be distracted) from using any device while someone else is driving.
I'm wondering, though. For package goods it's fine. For perishables like meat, dairy, refrigerated goods and so on, it's a bit more complicated. The supermarkets (Vons in my area) already have the distribution network and storage in place in every store they have. All they need to do for delivery is pick the stuff off the shelves (or out of the back room before it goes on the shelves), put it in a truck and go. It'll be interesting to see how Amazon deals with keeping perishable goods in stock close enough to the destination to make it through delivery intact.
The basic ideas behind it are:
And finally, management has to accept that there is no magic here. Accommodating changes requires work. If they're building a 4-story building and they suddenly want 6 stories, the foundations and framework will need to be reworked. You can do the work up-front, over-designing the foundations and framework to accommodate a potentially taller building before construction starts, or you can do the work later when you have to tear up the lower floors to re-do the foundations and load-bearing framework, but snapping your fingers and magically making foundations designed just big enough for a 4-story building suddenly support 6... we're not Harry Potter, this ain't Hogwarts, and the Burrow just won't stay standing in real life.
From personal experience, it depends on how much knowledge of the final requirements you've got. One thing you've got going for you that the initial team didn't is the initial work they did figuring out requirements. They may not have produced a workable result, but the Agile team you're "rescuing" almost certainly accumulated a lot of information about what exactly's needed in the final product. You get to base your design off of that.
The hard part of course is where you aren't rescuing another team and don't have all the information they accumulated. That's where waterfall breaks down, because it's hard to do the whole design when you don't have much clue what you actually need to build. You have to do a lot of thinking and basically sketch out almost the entire final system, and that takes more time than management's usually willing to allow without seeing some kind of results (which you won't have because until your design's finished you can't start coding and producing what management would call results). Bear in mind that waterfall development got a bad rep precisely because of an accumulated history of failed projects, missed deliveries and products that didn't do what was needed (there's a lot of truth to the line from a filksong "It's just what we asked for / but not what we want."). Don't ask how many times we've started into things only to find out about huge areas that nobody even thought existed.
Simply put, if you're doing something that hasn't been done before you need to do a lot of exploration to figure out what the users really want and what the best way of doing it is. Agile didn't just pull the idea out of thin air, it came from the acceptance of decades of hard experience: on a non-trivial project you do not know and can not know all the requirements and gotchas going into it. The problem is often that management doesn't accept this, and they tend to panic just at the point in an Agile project where the developers have finally gotten a good handle on the requirements and are in a position to nail down a good design and start working towards it. That's compounded by a lot of Agile teams not having group buy-in on a single design and set of requirements. You don't have to get everybody to agree on what the best design is, but you do have to get everyone to agree on what the design will be for this project. When you don't, when you get every developer with their own idea of how it should work, it all falls apart.
No, because it's a distinction you can't draw. There's a line from a Dr. Who episode: "Not every shadow, just any shadow.". The same applies to attackers. Not every attacker will know the details, but any attacker may. And since by the time you know whether any particular attacker knows the details or not it's too late to defend, you have to assume that any attacker knows and defend yourself before the attack starts.
And in this age of attack toolkits that get regular updates, once one attacker knows the details and creates the attack modules any other attacker is just one toolkit update away from having the attack too.