Head over to Seek (seek.com.au), which a local can confirm is arguably one of the most popular job search engines in Australia.
Pick Adelaide as a region, "C++" as a skill. Yes, I know Adelaide is a small capital city, don't get me started.
Six hits. A few weeks ago, it was four.
Four of those hits *require* an additional mandatory skill or language beyond C++, or security clearance.
Of the remaining two, I can confirm that last year, one of them wasn't interested in a First-Class Comp Sci Honours graduate C++ software developer with well over ten years of experience. They didn't even reply. Think about that for a moment.
That leaves one opening. For how many existing developers and new graduates?
Let's try Hobart now.
No jobs at all.
Same for Darwin. No jobs.
What skills shortage?
And yes, I do know that cities such as Melbourne and Sydney have many more opportunities.
One advantage of brick-and-mortar stores is that if you want something *today*, or want to look at the darn thing in person first, and *then* get it today, they have an incredible edge over online retailers. Not everyone wants to drive to a store, look at something, and then go off and find another place to get it, and then wait for it to arrive.
Honestly, I'm surprised you can't log in online to more stores, place an online reservation a product to pickup today (with a limited reservation window), and by the time you arrive the salesperson has exactly what you want, and a good idea as to what they might be able to upsell you on. They could very well be stealing business from online stores by pushing the "do you want it now?" angle. I'm not sure why they don't.
Service is dead though. Most of the staff in such stores aren't paid enough any more to give a damn beyond selling you the product with the highest commission, and it means that anyone with any sense steps inside the store already filled with skepticism. The only thing that seems to be remaining in that area (IMHO) is competing on return policies. If a place has a good return policy and you want a working product ASAP, it can be worth paying extra to get the thing you want, knowing that you won't be waiting for four weeks on an RMA if it's broken.
As someone who has spent an awful lot of time documenting *other* people's code over the last few years, I believe I can offer some insight as to how it gets that way.
IMHO, the big reasons for poor documentation tend to be either related to the self-interest of the developer, or insufficient time being allowed by management to create the documentation. On the self-interest front, we have:
- Job security: If it is apparent that replacing a developer is going to be costly due to nobody else knowing the tricks of the undocumented code, nobody is going to put their hand up to be the one doing the firing, as the resultant disaster from the replacement getting up to speed is probably going to be blamed on the one who did the firing.
- Artificial inflation of worth: If a developer knows the secrets of the code but their coworkers do not, they tend to look considerably more efficient and productive than their coworkers when working on that segment of code. This is so common that it's almost easier to list the cases where it doesn't happen, than where it does.
- Politics and currency: Knowledge of the code has value, and withholding that from others gives it value that can be used to buy favours from other people, or used to "punish" people who cross them.
- Lack of visibility: Poor commenting and inaccurate documentation is often only really noticed by people with the technical background to understand it. If the developer answers to a non-technical person, they can choose to get lazy about the things they don't strictly need themselves.
- Revenge: If the developer leaves, the next guy is going to have a lot of trouble getting up to speed. By withholding documentation, the developer can make sure the impact is greater, and is really felt.
- Hiding bodies: If the code is hideously broken, and the developer incompetent or inadequately resourced, having no documentation allows them to hide this for as long as possible whilst they look for a way to get out of the organisation, reputation intact. Let the next guy take the heat.
On the management side:
- Lack of understanding: Sometimes management doesn't understand that if documentation (and code cleanups) and forever withheld, the codebase will become an unmaintainable mess. Simple changes start to take forever, and complex changes never fully work due to the need to hack them in.
- No time: Sometimes documentation becomes a "work in the background" thing, where no time is really ever allocated for it, until some disaster strikes, and the same people cry "but where was the documentation". Writing documentation (eg. technical documents) takes time, not only from needing to refer to and test the code, but also to verify and proofread the whole thing. It never happens in magical zero-time.
- Job security: Similarly to the developer's trick, management can do this too. If they hold knowledge about how everything fits together, and it's not written anywhere, then it's going to be hard to replace the *manager*, for the same reasons.
- Artificial inflation of worth: Let's face it, the manager's manager is probably never going to really read any technical documentation- they're too far removed from it all. Who looks better: The manager who delivers work in eight months, or the one who does it in nine, with proper documentation?
- Short-term focus: If the driving factors are always the externally visible ones, and internal concerns such as code maintenance are always neglected (perhaps because the manager won't explain the necessity of this to the higher-ups), then documentation *will* be neglected. If the manager plans to move on in the medium term, they may not care if the project falls over in a heap after they leave- it's unlikely anyone will pin it on them, and it may not matter anyway.
And a last one that's in a class of its own: Inability. Not everyone can write documentation well.
Having worked on both sides of the IT support fence, I like the plumbing analogy.
If the plumbers started mandating toilet times and protocols, and required you to get management approval for each piece of toilet paper you planned to use, a month in advance, then you have a problem.
If the company employees insisted on their right to relieve themselves in their offices, and demanded to know why someone isn't there in five minutes to clean up after them, you also have a problem.
If your IT department are blissfully ignorant as to the needs of the organisation, and there is no oversight of what they do, then you have a problem.
If your IT department are forced to jump on demand, and are never given the chance to address network security, stability, or backups appropriately because they are always supporting random device X that has nothing to do with the job (until data is lost, and everyone suddenly remembers that backups *are* needed), then you have a problem.
As with many things, there is a healthy balance between the extremes that a company should be aiming for. It's all common sense, and sometimes, it's not all that common.
> But there is another kind of evil which we must fear most, and that is the indifference of good men.
Whilst the quotation is a good one, I'm not sure it is very fair on the GP. The GP expressed a very specific concern with respect to reporting the crime, so it is hardly indifference. Perhaps it would be better to ask *why* he feels that he would potentially be in danger for reporting a crime- what has gone wrong so that he feels this way, and what can be done to fix it, so that the next person does not hesitate similarly? Just a thought.
> A battleship that has shown its willingnes to keep firing all guns until all atoms previously making up any knife-wielding attacker is at least in earth orbit, preferably in sun orbit.
Well said.
If the size of the battleship doesn't give you pause, climbing over the charred remains of the last few knife-wielding attackers may.
You know, they might not be so rare if every do-gooder with a time machine didn't keep going back in time and picking up all of the remaining copies before they were found.
> well they make hardware (motion capture sensors) for a niche market. So it's not terribly likely that their code being stolen will be a big issue, I think. It's a tiny market with few players. In fact, having the code open might make their hardware easier to integrate for some clients with custom solutions, or at least feel safe about it.
Hardware manufacturers can potentially be good candidates for open source software, since they can release the source, and sell the hardware. If it's a small market or the hardware is expensive, they probably won't gain much from hobbyist contributors, so the question as to whether or not a company is likely to use the source and contribute back becomes more important. Of course, the modifiable source could end up being a selling point as you suggest.:)
> If the cloner comes with a name like IBM, Google, MicroSoft or HP, they can be 3 years behind and still get the contract... nobody ever got fired for choosing ________.
If one of the big players starts intruding into your market, you've probably got a real, business-killing problem to deal with, unless you can satisfy a need that they can not or will not satisfy themselves.
But then again, sometimes they come bearing money instead, since they want the product, but don't want to develop it from scratch.
> Even if your competitors do then take that idea and steal it, it's possible to make money from the fact that your version is always months ahead in innovations. It's easier for someone who is actively inventing ideas to keep the flow of research moving forward, compared to someone that who just copied a subset of their ideas.
This is a very good point. If the product is such that you can keep improving it, and keep those improvements in the eyes of your customers, then anyone cloning the product will be seen as just playing catchup. It then becomes hard for them to compete on anything but price, which is hard to do if they're hiring double the number of developers as well. Heck, open sourcing your last version and charging for your most recent one would probably be one way to keep clone-based competitors from even *starting* to nip at your heels. I'd say there are probably lots of ways of playing it, depending on the type of product, and the potential benefits of opening some or all of the source in those circumstances.
- Is your product something that hobby developers might take an interest in? Will their contributions add value to your codebase or company? Will they want to contribute?
- Is your product something other companies might find useful if they took it, added a feature, and contributed it back to you? Will they have any incentive to send anything back to you?
- Do you have anything that you can subsequently sell to the people using your open code, that they are going to want to buy, that a competitor can't quickly spring up and take the opportunity from you?
- Could opening the code allow you to steal away a significant part of the market, that you can later sell products or services to, for a net profit? Is this likely?
And weigh this up against:
- You've given away the code. Is there anything left to sell, and will people want to buy it?
- Would your company survive if someone saw the code, thought it was a good idea, and put double the number of developers on it and told them: "make something like this"? Assume they will use your code as a reference, but no proof of it will ever be found.
- A company with an international presence steals your code, builds it into their product, and sells it. Do you either have the resources to fight a huge multinational (possibly hiding behind a subsidiary in a different country), and the ability to survive for a few years whilst it works its way through the courts, as well as fight off baseless countersuits? Or is your product such that your company will survive, even if it is being ripped off, possibly even benefiting from the exposure?
I think that it's great that you've been able to run Windows for so long, and experienced no driver or stability problems. You definitely should receive some sort of award or official recognition.
Anyway, I'd love to chat, but it's Monday and Suzy's PC is infested with malware again.
Hairyfeet, I'm not 100% sure, but I get the feeling you *might* personally have a preference for using Windows operating systems over Linux-based ones. If you could respond with a few hundred more inflammatory words to let me know for sure, that'd be just peachy.
Also, did you have a traumatic experience using a commandline when you were young? Possibly lost family members due to an accident involving a poorly-formed regular expression? Just curious.
My personal, unverifiable, unscientific, pulled-out-of-my-rear theory is that the development of life similar to and understandable by our own is sufficiently rare, and the universe so imperceivably large that the countless life that has evolved (we'll just say billions of instances in a suitably chosen near-infinitely-tiny fraction of the universe), just haven't *found* each other for the most part. Perhaps we're just unlucky enough to be located sufficiently far from other life, and there are billions of interactions between billions of similarly evolved lifeforms in some areas of the universe. Maybe heavy interaction between such lifeforms is the norm, and we're just part of the smaller fraction who are pretty isolated. Perhaps we are the front of life spreading into a new area, or the result of life dying off in the same area. But even that is probably overstating our importance.
Going with the above, Earth is definitely special case within a certain area, if we extend that area out until just before the closest instance of the uncountable number of other cases that meet the same criteria.:} It certainly seems to be quite unique within the area that we can currently perceive and understand. Perhaps this will change one day, when we can better understand the universe around us. Or perhaps we'll have died off long before then.
Anyway, that's how I like to look at things.
Short version: Tiny fractions of an imperceivably large universe.
Looks like Apple wants in on the patent extortion rort.
Apple's competitors can pull the same tricks too- I'd fully expect a few "innovation startups" to spring up soon, preloaded with patent portfolios, and start hitting Apple back.
My hope is that in the resulting mess a few senior people in the bigger organisations take notice and figure out that they could make huge savings by spending some of that money on political lobbying instead, get patent laws cleaned up, and pull the fangs from these lawsuits. These organisations have made great efforts to get the cheapest manufacturing, labour, and development costs. It seems strange that they haven't gone for similar savings in the legal area as well.
"Linux and UNIX-like operating systems have followed a particular, if arcane, way of organizing files"
In other news, if somebody doesn't personally understand the reason for something, it is now "arcane".
Personally, I still prefer to have "/usr" on its own filesystem, so I can unmount it if I need to and tidy it up, using the tools in "/bin" and "/sbin". It's not *necessarily* a space thing. I quite like the separation between basic tools, and "everything else". If an "everything else" package install or script or similar stuffs things up, it's nice to be able to fix it in a reasonable environment (which an unmounted "/usr" gets you).
I also don't mind the separation between admin tools, and user tools. I think that covers the "/usr/sbin" versus "/usr/bin" thing.
The cult of gratuitous uptime has always bewildered me.
Eventually, you are going to run into a problem that you do not know how to solve on a live system. Even if you are arrogant enough to believe in your own omnipotence, eventually you are going to run into a problem that *cannot* be solved on a live system. And even if that never happens, a hardware failure is going to bring your system to a screaming halt one day.
Sometimes the problem you are trying to solve will take some time to understand, and you need a solid understanding to plan how to properly fix an ongoing problem. Sometimes you have to hack a quick fix to see you through whilst properly planning your long-term fix.
Sometimes, some clown screws up and takes something out that the live system needed. Sometimes, that clown is you.
If you have been concentrating on keeping your amazing uptime, you have probably been neglecting any verification that your server is even *capable* of correcting booting back up, if you are ever forced into a corner and need to bring the system down. Discovering this, and attempting to fix it mid-crisis, is negligence at its worst. And leaving it to chance based on the belief you are a *nix-God and couldn't possibly be wrong?
Being reasonably confident that you can shut down and bring up a system in a crisis is important. If you're not taking time to do this verification because you think that your excessive uptime demonstrates your hardcore *nix-guru-ness, you're just being negligent.
> but listening to the End User is not one of MS's problems
After reading countless posts regarding inaction and apathy on long-term known bugs in the Visual Studio suite, I too can confirm that listening to the end user is definitely not something that MS consider their problem.
> On the other hand, pipe up to just about any Open Source project about End User issues, and "STFU and submit a patch" is about the nicest thing you'll hear
What complete nonsense. There are plenty of projects out there that are run by people who care about the quality of their project and are keen to hear about problems with it, and plenty of commercial organisations that won't respond with much apart from "sorry that you've run into a problem, by the way, don't expect a fix". Suggesting that non-responsiveness is the primary domain of open source projects ahead of commercial ones is disingenuous; if anything, I've found the opposite to be true.
Unless people care about it specifically, you will find that it will never expire, as it will be extended every x years, until the heat-death of the universe. Why? Because as time goes by, there's more money locked up in this vault of old works, and whatever forces are there to push through these laws today, they will be there and stronger tomorrow. This will be the case until people care enough to break this lock, or your system of government collapses entirely.
I'm using a pair of triple- and quad-head PCs as we speak. Linux on both: CentOS 5.3 on one, Ubuntu 9.10 on the other. One ran OpenSuSE 10.2 previously. Two cheap dual-head nVidia cards, their binary drivers. Started with the xorg.conf generated from the nVidia tool. Spent several hours the first time trying to get it going years back, but nowadays just spend about 15 minutes setting it up upon install. Works as one large screen in each case. As such, I just drag things around on the (big) desktop to change displays. The doco supplied with the nVidia drivers is reasonably good and all I really used. Runs 3D stuff fine on each. One is KDE, the other GNOME. Both environments seem to have an awareness of the physical displays as well- if I hit maximise, it'll fill the current monitor. I'm not sure that the Linux ecosystem is really lacking such things.
I'm not 100% sure which features are apparently lacking? Is it just keyboard shortcuts to move a window from one physical screen to another? That'd certainly be useful, though I can already do this with a mouse. I know that the keyboard shortcut list is lacking in GNOME, and more options in KDE couldn't hurt either. Perhaps that's what it's about.
Slashdot Mirror
Skills shortage, hey?
Head over to Seek (seek.com.au), which a local can confirm is arguably one of the most popular job search engines in Australia.
Pick Adelaide as a region, "C++" as a skill. Yes, I know Adelaide is a small capital city, don't get me started.
Six hits. A few weeks ago, it was four.
Four of those hits *require* an additional mandatory skill or language beyond C++, or security clearance.
Of the remaining two, I can confirm that last year, one of them wasn't interested in a First-Class Comp Sci Honours graduate C++ software developer with well over ten years of experience. They didn't even reply. Think about that for a moment.
That leaves one opening. For how many existing developers and new graduates?
Let's try Hobart now.
No jobs at all.
Same for Darwin. No jobs.
What skills shortage?
And yes, I do know that cities such as Melbourne and Sydney have many more opportunities.
Okay, that's enough Linus. It's simply not funny any more. Hand it back now.
One advantage of brick-and-mortar stores is that if you want something *today*, or want to look at the darn thing in person first, and *then* get it today, they have an incredible edge over online retailers. Not everyone wants to drive to a store, look at something, and then go off and find another place to get it, and then wait for it to arrive.
Honestly, I'm surprised you can't log in online to more stores, place an online reservation a product to pickup today (with a limited reservation window), and by the time you arrive the salesperson has exactly what you want, and a good idea as to what they might be able to upsell you on. They could very well be stealing business from online stores by pushing the "do you want it now?" angle. I'm not sure why they don't.
Service is dead though. Most of the staff in such stores aren't paid enough any more to give a damn beyond selling you the product with the highest commission, and it means that anyone with any sense steps inside the store already filled with skepticism. The only thing that seems to be remaining in that area (IMHO) is competing on return policies. If a place has a good return policy and you want a working product ASAP, it can be worth paying extra to get the thing you want, knowing that you won't be waiting for four weeks on an RMA if it's broken.
As someone who has spent an awful lot of time documenting *other* people's code over the last few years, I believe I can offer some insight as to how it gets that way.
IMHO, the big reasons for poor documentation tend to be either related to the self-interest of the developer, or insufficient time being allowed by management to create the documentation. On the self-interest front, we have:
- Job security: If it is apparent that replacing a developer is going to be costly due to nobody else knowing the tricks of the undocumented code, nobody is going to put their hand up to be the one doing the firing, as the resultant disaster from the replacement getting up to speed is probably going to be blamed on the one who did the firing.
- Artificial inflation of worth: If a developer knows the secrets of the code but their coworkers do not, they tend to look considerably more efficient and productive than their coworkers when working on that segment of code. This is so common that it's almost easier to list the cases where it doesn't happen, than where it does.
- Politics and currency: Knowledge of the code has value, and withholding that from others gives it value that can be used to buy favours from other people, or used to "punish" people who cross them.
- Lack of visibility: Poor commenting and inaccurate documentation is often only really noticed by people with the technical background to understand it. If the developer answers to a non-technical person, they can choose to get lazy about the things they don't strictly need themselves.
- Revenge: If the developer leaves, the next guy is going to have a lot of trouble getting up to speed. By withholding documentation, the developer can make sure the impact is greater, and is really felt.
- Hiding bodies: If the code is hideously broken, and the developer incompetent or inadequately resourced, having no documentation allows them to hide this for as long as possible whilst they look for a way to get out of the organisation, reputation intact. Let the next guy take the heat.
On the management side:
- Lack of understanding: Sometimes management doesn't understand that if documentation (and code cleanups) and forever withheld, the codebase will become an unmaintainable mess. Simple changes start to take forever, and complex changes never fully work due to the need to hack them in.
- No time: Sometimes documentation becomes a "work in the background" thing, where no time is really ever allocated for it, until some disaster strikes, and the same people cry "but where was the documentation". Writing documentation (eg. technical documents) takes time, not only from needing to refer to and test the code, but also to verify and proofread the whole thing. It never happens in magical zero-time.
- Job security: Similarly to the developer's trick, management can do this too. If they hold knowledge about how everything fits together, and it's not written anywhere, then it's going to be hard to replace the *manager*, for the same reasons.
- Artificial inflation of worth: Let's face it, the manager's manager is probably never going to really read any technical documentation- they're too far removed from it all. Who looks better: The manager who delivers work in eight months, or the one who does it in nine, with proper documentation?
- Short-term focus: If the driving factors are always the externally visible ones, and internal concerns such as code maintenance are always neglected (perhaps because the manager won't explain the necessity of this to the higher-ups), then documentation *will* be neglected. If the manager plans to move on in the medium term, they may not care if the project falls over in a heap after they leave- it's unlikely anyone will pin it on them, and it may not matter anyway.
And a last one that's in a class of its own: Inability. Not everyone can write documentation well.
Having worked on both sides of the IT support fence, I like the plumbing analogy.
If the plumbers started mandating toilet times and protocols, and required you to get management approval for each piece of toilet paper you planned to use, a month in advance, then you have a problem.
If the company employees insisted on their right to relieve themselves in their offices, and demanded to know why someone isn't there in five minutes to clean up after them, you also have a problem.
If your IT department are blissfully ignorant as to the needs of the organisation, and there is no oversight of what they do, then you have a problem.
If your IT department are forced to jump on demand, and are never given the chance to address network security, stability, or backups appropriately because they are always supporting random device X that has nothing to do with the job (until data is lost, and everyone suddenly remembers that backups *are* needed), then you have a problem.
As with many things, there is a healthy balance between the extremes that a company should be aiming for. It's all common sense, and sometimes, it's not all that common.
> But there is another kind of evil which we must fear most, and that is the indifference of good men.
Whilst the quotation is a good one, I'm not sure it is very fair on the GP. The GP expressed a very specific concern with respect to reporting the crime, so it is hardly indifference. Perhaps it would be better to ask *why* he feels that he would potentially be in danger for reporting a crime- what has gone wrong so that he feels this way, and what can be done to fix it, so that the next person does not hesitate similarly? Just a thought.
> A battleship that has shown its willingnes to keep firing all guns until all atoms previously making up any knife-wielding attacker is at least in earth orbit, preferably in sun orbit.
Well said.
If the size of the battleship doesn't give you pause, climbing over the charred remains of the last few knife-wielding attackers may.
You know, they might not be so rare if every do-gooder with a time machine didn't keep going back in time and picking up all of the remaining copies before they were found.
> Ever wonder why you see so few patent lawsuits from IBM relative to their portfolio?
Personally, I just assumed it was the same reason that you see very few knife attacks on the hull of a battleship.
> well they make hardware (motion capture sensors) for a niche market. So it's not terribly likely that their code being stolen will be a big issue, I think. It's a tiny market with few players. In fact, having the code open might make their hardware easier to integrate for some clients with custom solutions, or at least feel safe about it.
Hardware manufacturers can potentially be good candidates for open source software, since they can release the source, and sell the hardware. If it's a small market or the hardware is expensive, they probably won't gain much from hobbyist contributors, so the question as to whether or not a company is likely to use the source and contribute back becomes more important. Of course, the modifiable source could end up being a selling point as you suggest. :)
> If the cloner comes with a name like IBM, Google, MicroSoft or HP, they can be 3 years behind and still get the contract... nobody ever got fired for choosing ________.
If one of the big players starts intruding into your market, you've probably got a real, business-killing problem to deal with, unless you can satisfy a need that they can not or will not satisfy themselves.
But then again, sometimes they come bearing money instead, since they want the product, but don't want to develop it from scratch.
> Even if your competitors do then take that idea and steal it, it's possible to make money from the fact that your version is always months ahead in innovations. It's easier for someone who is actively inventing ideas to keep the flow of research moving forward, compared to someone that who just copied a subset of their ideas.
This is a very good point. If the product is such that you can keep improving it, and keep those improvements in the eyes of your customers, then anyone cloning the product will be seen as just playing catchup. It then becomes hard for them to compete on anything but price, which is hard to do if they're hiring double the number of developers as well. Heck, open sourcing your last version and charging for your most recent one would probably be one way to keep clone-based competitors from even *starting* to nip at your heels. I'd say there are probably lots of ways of playing it, depending on the type of product, and the potential benefits of opening some or all of the source in those circumstances.
Consider:
- Is your product something that hobby developers might take an interest in? Will their contributions add value to your codebase or company? Will they want to contribute?
- Is your product something other companies might find useful if they took it, added a feature, and contributed it back to you? Will they have any incentive to send anything back to you?
- Do you have anything that you can subsequently sell to the people using your open code, that they are going to want to buy, that a competitor can't quickly spring up and take the opportunity from you?
- Could opening the code allow you to steal away a significant part of the market, that you can later sell products or services to, for a net profit? Is this likely?
And weigh this up against:
- You've given away the code. Is there anything left to sell, and will people want to buy it?
- Would your company survive if someone saw the code, thought it was a good idea, and put double the number of developers on it and told them: "make something like this"? Assume they will use your code as a reference, but no proof of it will ever be found.
- A company with an international presence steals your code, builds it into their product, and sells it. Do you either have the resources to fight a huge multinational (possibly hiding behind a subsidiary in a different country), and the ability to survive for a few years whilst it works its way through the courts, as well as fight off baseless countersuits? Or is your product such that your company will survive, even if it is being ripped off, possibly even benefiting from the exposure?
I think that it's great that you've been able to run Windows for so long, and experienced no driver or stability problems. You definitely should receive some sort of award or official recognition.
Anyway, I'd love to chat, but it's Monday and Suzy's PC is infested with malware again.
A downmod for a post making fun of an attack piece, and an upmod of the attack piece? Stay classy.
Hairyfeet, I'm not 100% sure, but I get the feeling you *might* personally have a preference for using Windows operating systems over Linux-based ones. If you could respond with a few hundred more inflammatory words to let me know for sure, that'd be just peachy.
Also, did you have a traumatic experience using a commandline when you were young? Possibly lost family members due to an accident involving a poorly-formed regular expression? Just curious.
My personal, unverifiable, unscientific, pulled-out-of-my-rear theory is that the development of life similar to and understandable by our own is sufficiently rare, and the universe so imperceivably large that the countless life that has evolved (we'll just say billions of instances in a suitably chosen near-infinitely-tiny fraction of the universe), just haven't *found* each other for the most part. Perhaps we're just unlucky enough to be located sufficiently far from other life, and there are billions of interactions between billions of similarly evolved lifeforms in some areas of the universe. Maybe heavy interaction between such lifeforms is the norm, and we're just part of the smaller fraction who are pretty isolated. Perhaps we are the front of life spreading into a new area, or the result of life dying off in the same area. But even that is probably overstating our importance.
Going with the above, Earth is definitely special case within a certain area, if we extend that area out until just before the closest instance of the uncountable number of other cases that meet the same criteria. :} It certainly seems to be quite unique within the area that we can currently perceive and understand. Perhaps this will change one day, when we can better understand the universe around us. Or perhaps we'll have died off long before then.
Anyway, that's how I like to look at things.
Short version: Tiny fractions of an imperceivably large universe.
Looks like Apple wants in on the patent extortion rort.
Apple's competitors can pull the same tricks too- I'd fully expect a few "innovation startups" to spring up soon, preloaded with patent portfolios, and start hitting Apple back.
My hope is that in the resulting mess a few senior people in the bigger organisations take notice and figure out that they could make huge savings by spending some of that money on political lobbying instead, get patent laws cleaned up, and pull the fangs from these lawsuits. These organisations have made great efforts to get the cheapest manufacturing, labour, and development costs. It seems strange that they haven't gone for similar savings in the legal area as well.
But I know that I'm hoping for too much.
"Linux and UNIX-like operating systems have followed a particular, if arcane, way of organizing files"
In other news, if somebody doesn't personally understand the reason for something, it is now "arcane".
Personally, I still prefer to have "/usr" on its own filesystem, so I can unmount it if I need to and tidy it up, using the tools in "/bin" and "/sbin". It's not *necessarily* a space thing. I quite like the separation between basic tools, and "everything else". If an "everything else" package install or script or similar stuffs things up, it's nice to be able to fix it in a reasonable environment (which an unmounted "/usr" gets you).
I also don't mind the separation between admin tools, and user tools. I think that covers the "/usr/sbin" versus "/usr/bin" thing.
And there we have it.
1. Copy Fruit code? / Develop own code
2. Copy Crafty code? / Develop own code
3. Customise code / Develop own code
4. Enter tournament / Enter tournament
5. Win tournament / Identify Plagiarism!
6. Oh crap /
Black to play and mate in three.
The cult of gratuitous uptime has always bewildered me.
Eventually, you are going to run into a problem that you do not know how to solve on a live system. Even if you are arrogant enough to believe in your own omnipotence, eventually you are going to run into a problem that *cannot* be solved on a live system. And even if that never happens, a hardware failure is going to bring your system to a screaming halt one day.
Sometimes the problem you are trying to solve will take some time to understand, and you need a solid understanding to plan how to properly fix an ongoing problem. Sometimes you have to hack a quick fix to see you through whilst properly planning your long-term fix.
Sometimes, some clown screws up and takes something out that the live system needed. Sometimes, that clown is you.
If you have been concentrating on keeping your amazing uptime, you have probably been neglecting any verification that your server is even *capable* of correcting booting back up, if you are ever forced into a corner and need to bring the system down. Discovering this, and attempting to fix it mid-crisis, is negligence at its worst. And leaving it to chance based on the belief you are a *nix-God and couldn't possibly be wrong?
Being reasonably confident that you can shut down and bring up a system in a crisis is important. If you're not taking time to do this verification because you think that your excessive uptime demonstrates your hardcore *nix-guru-ness, you're just being negligent.
> but listening to the End User is not one of MS's problems
After reading countless posts regarding inaction and apathy on long-term known bugs in the Visual Studio suite, I too can confirm that listening to the end user is definitely not something that MS consider their problem.
> On the other hand, pipe up to just about any Open Source project about End User issues, and "STFU and submit a patch" is about the nicest thing you'll hear
What complete nonsense. There are plenty of projects out there that are run by people who care about the quality of their project and are keen to hear about problems with it, and plenty of commercial organisations that won't respond with much apart from "sorry that you've run into a problem, by the way, don't expect a fix". Suggesting that non-responsiveness is the primary domain of open source projects ahead of commercial ones is disingenuous; if anything, I've found the opposite to be true.
Unless people care about it specifically, you will find that it will never expire, as it will be extended every x years, until the heat-death of the universe. Why? Because as time goes by, there's more money locked up in this vault of old works, and whatever forces are there to push through these laws today, they will be there and stronger tomorrow. This will be the case until people care enough to break this lock, or your system of government collapses entirely.
I wouldn't put 2018 in your diary at all.
OverflowingBitBucket likes this.
I'm using a pair of triple- and quad-head PCs as we speak. Linux on both: CentOS 5.3 on one, Ubuntu 9.10 on the other. One ran OpenSuSE 10.2 previously. Two cheap dual-head nVidia cards, their binary drivers. Started with the xorg.conf generated from the nVidia tool. Spent several hours the first time trying to get it going years back, but nowadays just spend about 15 minutes setting it up upon install. Works as one large screen in each case. As such, I just drag things around on the (big) desktop to change displays. The doco supplied with the nVidia drivers is reasonably good and all I really used. Runs 3D stuff fine on each. One is KDE, the other GNOME. Both environments seem to have an awareness of the physical displays as well- if I hit maximise, it'll fill the current monitor. I'm not sure that the Linux ecosystem is really lacking such things.
I'm not 100% sure which features are apparently lacking? Is it just keyboard shortcuts to move a window from one physical screen to another? That'd certainly be useful, though I can already do this with a mouse. I know that the keyboard shortcut list is lacking in GNOME, and more options in KDE couldn't hurt either. Perhaps that's what it's about.