> And the machines will fine tune and configure > themselves.
No they won't, but with very few exceptions big companies don't fine tune machines. Read that again slowly - BIG COMPANIES DON'T FINE TUNE THEIR MACHINES. It is cheaper to throw in more hardware than to employ someone to tune a slow machine, except in extremely unusual circumstances.
Last year, I spent time reviewing performance data from ~7000 servers (Windows, Sun, Linux, HP-UX) for one large organization. Across those 7000 machines, guess what the average CPU utilisation was. 7%! That's not a misprint - 7%. Even when you looked at (mean + 3 standard deviations) of CPU utilisation (which shows where the machine spends 99%+ of its time), hardly any got above 20%. In other words, you could replace almost all of these machines with boxes that had 20% of the CPU grunt. Sure, there were a few big spikes, but almost invariably they occurred at backup time at e.g. 2am and lasted less than 5 minutes;I don't think anyone would have noticed if those spikes went on for 5-10 times as long. Other measures of machine utilisation showed a similar story of unused capability.
Now, maybe you work at places where they're trying to squeeze the last drop of performance out of systems, but this particular company spends literally *billions* of dollars each year on their IT and they obviously don't do that. Nor do any of the other companies I work at, most of which would spend in the hundreds of millions on IT each year. Sure, there's the odd exception here and there, where there will be one or two servers for one or two specific applications that get tuned, but that's about it.
> You obviously have no idea what it costs to > provide true contingency, even with "cheap" > hardware.
And in the places that I work, if you proposed walking in and tuning thousands of machines, you'd be laughed off site. Similarly, building machines is something that vendors and/or outsourcers do, so that every machine is in a notionally similar configuration and nobody has to manage a hundred different scenarios of machine configuration when it comes to e.g. updating a management agent.
There is almost literally no place for individual experts in these machine rooms; they're production line, factory-floor types of environments where uptime is king.
As someone else said, consider Google - a huge computing facility running solely Linux on commodity hardware. As has been reported many times, they don't even unrack dead boxes, probably because it's considerably cheaper to just buy/rent more floor space and throw in a new rack of 43 blade servers. That's the model that the world is moving to, and which Sun doesn't service at present.
Bottom line: we obviously work in very different parts of the industry, but I'd maintain that the customers I work for used to be Sun's bread and butter customers, but now they buy from someone else.
> There's a definite market for this kind of > service. Just because you're not in it doesn't > mean it isn't there.
I'm absolutely working in that market - over the last several years I've worked for large banks, massive telcos, global car manufacturers, the Tax Office,...
These companies DON'T pay for that level of service; they engage outsourcers to do it for them. The outsourcers, not Sun, are paid to provide the love.
The outsourcers are selected primarily on price, so they cut corners wherever possible. When it comes time to replace a Sun box, the outsourcer recommends that the customer replace it with MS or Linux; that way the outsourcer can reduce their payments to Sun for support by hiring MS and Linux expertise themselves. As they generally get paid at least partly on a box-by-box basis, replacing 1 Sun with 2-3 Intel boxes is very good business for the outsourcer.
If you think I'm wrong, why else is MS and Linux replacing Sun in these data centres? Why do e.g. reputable banks run their Internet Banking on Windows servers? It's not for the reliability... Sure, there's still Sun boxes around, but they're now called "legacy systems" and left running e.g. Solaris 2.6.
Is the outsourcer's Linux and MS expertise as good as Sun's support? No way, but it takes the customer some time to work this out; at that time, they renegotiate their contract with the outsourcer from a position of weakness (i.e. customer has no in-house expertise left). The brave ones churn to the next outsourcing company
Is the customer able to pass off broken gear and apps to someone else to fix? Absolutely
Does the customer still get their lovin' from someone when things break? Yes; if not from the call centre person, then the call centre supervisor. If not the supervisor, then the account manager. And so on, up the tree. Meanwhile, behind the scenes, the outsourcer (generally a big company in its own right) is engaging Sun or whoever on a one-off basis, and the problem will get fixed. What the hell; maybe they'll even get a Sun engineer onsite(!!) to get things sorted, and thus the customer feels loved even more (note: by the outsourcer, not Sun)
Am I cynical about all this? You bet
Re:Still can't see how Sun will survive
on
Sun-isms Debunked
·
· Score: 2, Interesting
You can argue that Sun *deserves* better, courtesy of stuff like ZFS, containers, ease of setup, "Solaris does things right" and so on. I won't argue the merits of that stuff with you, because I agree that they're very nice to have.
However, I don't think Sun will *get better*; it's doomed.
Two or three years ago, companies I worked for would go out and buy ~10 E10k or E15k boxes with not a lot of financial justification required; these were banks and telcos, so they had the money and they were willing to pay the premium price because Sun stuff was that much better than their competitors. "Nobody got fired for choosing Sun's Unix hardware" was pretty much a golden rule.
Those same companies, with the same people making the decisions, now buy Dell boxes to do the same task. In many cases, the apps running on the 3yo Sun boxes are being replaced by apps running on the new Dells. Each individual Sun box is still more reliable than the corresponding Dell (as I'm sure you know), but the cost difference is no longer justified. If/when a Dell box dies, admins throw in another one; that's how cheap they are.
On that topic, IT staff are a lot cheaper now too; using MS as an example, you can employ e.g. 2-3 "paper MCSEs" today for the price of a 2000-era Sun guru. So what if the MCSEs aren't that great? 95% of their job is to use Ghost to image new Dells every few days; if they don't like it, they can leave and someone else will replace them. If you're a big IT shop, you just don't need that many guru-level people around these days to keep gear running. Apologies if that dose of harsh reality offends...
I've got no idea if the following figures are correct, but the big Suns might be up 99.999% of the time and the Dells would be up 99.9% of the time. That used to be a big deal, but throw in a second (clustered) Dell box and now you've got the same hardware uptime in terms of impact on service delivery. What the hell, throw in 4 or 5 Dells to replace one Sun and be done with it; you'll still save wads of money.
Suns were good when the competition was crap. Now the competition is "good enough" (in uptime terms, which is what CIOs understand) and a lot cheaper, so out go the Suns.
Re:Still can't see how Sun will survive
on
Sun-isms Debunked
·
· Score: 4, Informative
Yep, you're right on both counts. However...
Every Sun purchase I've seen has been ultimately driven by support and reliability/uptime. Sun recognised this, and focused on building hardware and software to address reliability/uptime in particular. What's changed is that, while Solaris has more features than Linux in some ways, those features are primarily related to uptime which isn't that big a deal any more.
Why not? - for every useful feature that Sun adds in, someone in Linux-land will eventually see that feature as a good thing and work will be done to port that feature to Linux. The porting to Linux of an existing Sun feature can be done faster than Sun can think up and build new features, and as Linux pushes more and more into the enterprise, the focus will become more and more on replicating Sun's advantages in Linux. The numbers are simply against Sun managing to stay ahead - to a very large extent, you can achieve uptime by scaling "wide" i.e. throwing more boxes at the problem. It's absolutely not a panacea to all uptime issues, but it's an approach that fits particularly well with Linux/Intel due to the low incremental cost of the hardware. Whatever "uptime smarts" Sun can add to their OS, I and many others can achieve the same results (in pure uptime terms) by bolting a bunch of new Intel boxes into a rack
Re:Sun can be a champion-- but how?
on
Sun-isms Debunked
·
· Score: 2, Interesting
Embrace Linux, then use their still-excellent support services to offer enterprise-level Linux support.
While there's players in that area today, there's certainly room for Sun to make some very big dollars. I could well see Sun becoming a very successful services company; EDS is obligingly stepping out of the way in a timely manner...
Will they do it? No - I think Sun management is arrogant, inwardly-focused and too tied to their glory days to the point that they would see such a move (i.e. switching from high-margin hardware to slow-and-steady services as their primary source of revenue) as untenable
Still can't see how Sun will survive
on
Sun-isms Debunked
·
· Score: 4, Interesting
Sun still has to address the issue that their old market seems to have gone away to a large extent. While it made sense 5 years ago to drop ~$500k on an E10k box to get reliability and support, nowadays you can get that same reliability for much less by using piles of clustered Intel hardware and a fairly-competent Linux or BSD admin.
Outside of academia, the only reason people bought smaller Sun boxes is so they could develop for Sun's big iron with minimal migration issues at deployment or "scaling up" time. With the disappearance of Sun's big iron market, their low level market disappeared as well.
Open sourcing Solaris 10 is fine and dandy, but I think it's too little too late. There's brands of Linux and BSD (e.g. RHES, Debian, SE Linux, OpenBSD) that cover every one of Sun's old sweet spots (e.g. uptime, security, Oracle support,...), so I just can't see why people would go with Solaris these days.
Bottom line: Where is their sweet spot for selling their product? Why would I buy Sun these days?
It's a pity - Sun had a terrific product line that no-one else could match, but they didn't see the tide turning.
Anyone who's a subscriber and has actual pics of this thing in action, HAS to post some pic links
Now THIS is an idea...
on
Internet Hunting
·
· Score: 2, Insightful
...that can only end in tears.
Possible scenarios that occured to me within first 30 seconds: - Internet hunter shoots animal, some human goes out to retrieve it. Oooh, what will the next hunter that gets online fire a shot at? - "something goes wrong" and the system becomes unreliable. Who's going to onsite to fix the thing, while it's playing up? - it's all a big con, and when you think you're "hunting" you're actually watching a carefully prepared film - parachute one of these things into Fallujah, then auction off rights to "The Real Deathmarch 2004, with added reality"
Anyone care to round out a top 10 list? I would, but I'm at work, about to walk into a meeting and wishing I had one of these with me right about now...
I'm hoping you USians stand up and actively use civial disobedience to get this sort of rubbish thrown out. To your country's credit, you've got a history of this sort of activity that effectively adds an extra level of government that is only rarely required.
If you don't do it and this type of idiotic law becomes commonplace, then your country will progressively push it out to the rest of the world via "Free Trade Agreements" and similar tautologies. Unfortunately, we don't have a strong record of using civil disobedience, or anything like a Bill Of Rights, in Australia, so chances are laws such as this will quietly be accepted here.
> So I'm writting software for buisness methods. A > double whammy. According to a number of people on > thee forums I shouldn't be able to make money at > what I do...
No, I don't think anyone in Slashdot would deny you the right to earn a living at it whatever you choose, unless it's working for SCO. Or you're based in India. Or you use Microsoft products to do it...
What is regularly questioned is the right to *patent* business methods and software. What is wrong with the existing system of copyright for protecting such things? The main impact of patenting your work (vs. copyright) is that you can prevent others being able to both produce the same thing in a different way *and* coming up with the same thing independently.
One part of the argument that appears to have been turned around over the previous several years is that you (the individual) are *requesting* a patent from us (the public), on the grounds that your advancement is so good and has chewed up enough of your time and resources that the rest of us should be prepared to pay you what amounts to a tax for using your stuff. You should be convincing us how insanely great your advancement is, and that you should be compensated for it into the future so that you can go build your next insanely great advancement. That was the original intention of patents.
If you're manufacturing widgets, in this day it's quite difficult to believe that your widget is THAT much of an advancement that a patent could be justified on those grounds. Maybe if you've invented e.g. a jet engine that consumes 20% less fuel and can save airlines millions of dollars a day, you'd have an argument, but that's the kind of advancement that you'd have to come up with in this day and age.
To apply patents to software, you have to accept the following: - *every* piece of code you're producing builds heavily on the work of others. You may be hitting databases, using HTML or XML, using C++ or Java, using queues, whatever; every one of those advances was made by someone else and you're almost always going to be adding your 1% on top to build your thing. I would argue that your incremental 1% contribution had better be pretty amazing to justify a patent - in fact I (the public) could reasonably argue that the entire software industry as it exists today is built on tiny incremental advances over what existed yesterday, and that you'd need to invent something of the magnitude of "the database" or "the spreadsheet" to not have me laugh at your patent application and throw it back at you
You have to look back to history to see just how ridiculous the idea of patentable business processes are: - suppose Henry Ford patented "the assembly of manufactured products via production lines". I can't conceive of another business process that is equivalent to that in terms of breakthrough, but if Ford was allowed to patent that process, where would we be now? What would our manufacturing industry be like? - suppose Nokia patented the mobile phone (OK, it probably wasn't Nokia who invented them, so substitute in the correct company name). It too allowed a huge advance over the way business and personal communication was done, but where would the public interest component be if Nokia was granted a business process patent for mobile phones?
Double-entry accounting; offering the service of consultants to assist businesses make decisions when they don't have the expertise in house; monitoring production computer systems using software agents; online banking; telephone IVR systems - if you think about it, you can name endless numbers of business processes that must have seemed like big breakthroughs at the time, yet patenting them would have left the world a much worse place. If one company owned patents over any of the above, they could essentially be holding the rest of the world to ransom today, and there's no reasonable justification for their being in a position to do so.
> That doesn't mean I don't value the > crazy-hour-worker. It just means I value the > seasoned veteran who knows how to get the job done > quickly more because he's better at the job.
My thinking is different. As a contract manager who both codes and employs coders, my perspective may be useful to some people here.
I don't value the crazy-hour-worker, because I know it's not sustainable and the chances are the point where that becomes apparent will exactly coincide with that person being on my critical path. If someone can't get their job done in ~40 hours, either they're not up to the job or we've stuffed up our estimations; I can generally work out which of those 2 it is without too much investigation. Once I've worked out which it is, I'll either have to rejig my project plan or shed the person, and I'd rather not have to do either.
There are plenty of (mostly young) people who appear to work like crazy, but are only doing productive work 40 hours/week and the rest is spent on either their own research or stuffing around and probably disturbing others. Either way, as a rule I'll boot them out after 40 hours because they can do their research or stuff around outside of work.
I value the seasoned veteran, because I know he or she will produce an outcome to a deadline that they agree to. If a task is going to take 4 weeks, they don't say "I'll do it in 2" then trash my project plan when it blows out. They also don't work like maniacs to try to finish it in 2 weeks, because that will burn them out and stuff up my plan later on. Crazy Hours Guy may say he'll do it in 2, and maybe he'll actually do so 50% of the time; give me the guy who says he'll do it in 4 weeks, and does so 99% of the time, every time.
There is nothing, NOTHING more annoying to a project manager or team leader than having to rejig a project plan at short notice because someone is working in an unsustainable manner. That one person's incompetence (and I call lack of time management skills "incompetent" in a supposed professional) is going to have a massive impact on a project schedule, and potentially cause disruption to many peoples' lives while they try to untangle the mess.
Every now and then, I wind up with Crazy Hours Guy, but if so I make a point of never relying or employing him again.
> There's a simple rule that I like: if you (as a > manager) call overtime, you will work the same > hours.
On the very rare occasions that I've had to have people work overtime, that's the rule I work to as well - I'll hang back too till the last person leaves.
As far as not being able to make a contribution goes, well I'm a coder too so I can generally help out. However, if I wasn't I'd be hauling coffee, pizza,... - whatever it took to get everyone (and me!) out the door as early as possible.
Hard to understand how the games industry survives with what seems to be a common practice of 60-80+ hours per week for extended periods. Then again, given the number of bugs in most games that get released, quality seems to have gone down the toilet anyway; most games sold are part of a "franchise" so people just buy 'em regardless of whether they're any good or not.
Don't suppose you could post either a description or code fragment, or point me to a reference site? I've got to investigate XUL socket IO in the next few days myself...
> There has been a perception that once CA purchases > a product, they run it into the ground. Has that > perception been difficult to overcome with Ingres?
> Gaughan: Personally my knowledge of CA when I > joined the company was pretty much along the lines > of what you outlined.
Gaughan then goes on to explain that things have now changed, yada, yada...
My impression of CA is certainly along the interviewer's lines; they acquire stuff and milk it to death, not upgrading it, not supplying important patches and presumably living off the support revenue.
In fact, as I write this, there's a CA technical support guy (yes, they do exist!) onsite two desks over working with one of this company's techos. CA's challenge: convince us that Harvest, a CA source management product that seems locked in the past feature-wise but is costing us $$$ for support and maintenance, has any serious compelling features over and above Subversion.
I, and I suspect many others, will find it tough to believe that CA have suddenly "seen the light" and will start actually developing, supporting and enhancing the assets they have as opposed to selling something and providing excuses from that point on.
On the Ingres topic, I've downloaded it but probably won't look at it seriously unless/until I'm convinced it offers something over Postgres (free, usually good enough) and MySQL (free, well supported, fast and good for read-only apps) on the one hand and SQL Server/Oracle/DB2 (expensive, very powerful and scalable) on the other. Last time I used Ingres was 2 years ago, but my impression then was that it hadn't progressed significantly in the preceding 10 years (i.e. it was a typical CA product).
Yes. Chatzilla is an IRC client built in XUL that does that now, but it sounds like you're probably in it as much for the challenge as anything else.
Two broad approaches are obvious to me: - use a Jabber or similar standards- and server-based solution, and just use XUL to generate, capture and display the appropriate Jabber messages. You might need an XML-RPC or SOAP front end "in front of" Jabber that you talk through, or maybe you'll be able to do it using socket IO directly from XUL to Jabber - build your own peer-to-peer solution. I've got no idea if there's standard protocols you could use, but it might be a lot of fun if that's your bag
I've had a skunkworks XUL project going on for a couple of weeks now. I'm fortunate(?) enough to have a Web guy working with me who isn't addicted to WYSIWYG tools, and he and I are busily recreating an existing production VB app in XUL.
I have to admit I went into this with the attitude of "Let's see how far we get. I know we're gonna hit a killer roadblock at some point, but it'll be interesting to see how far we get before that happens". Now, with a demonstrable if unfinished and slightly crappy looking app already built, I can say: - there doesn't appear to be a roadblock. We've managed to use both XML-RPC and SOAP (had to try them both!) to talk to backend systems, and we've used this for stuff like database and mainframe access which is one area where I thought we'd hit problems. We can do synchronous and async screen updates, which adds a sizeable usability benefit over regular browser apps. We've used JavaScript for client-side data validation, and basically reproduced all the functionality in a fairly typical business VB app circa 2000 without any compromise at all which was a big surprise to me - writing XUL code is actually a lot of fun. Small amount of effort for a big result, which is always a nice aspect - there's a lot of possibilities to use XUL "mini apps" as functional test beds for Web services development. Haven't explored this yet, but it seems like that could be an approach we look at in the near future - it's been pretty easy to get stuff working, but more time consuming to get it looking exactly the way we want. In fact, several times we've forked the code and gone separate ways trying to solve a particular UI problem, which is probably not ideal but certainly quite productive in such a small project where there's no real problem "unforking" once a solution has been identified
Whether this project actually goes the next step and gets some formal testing is another matter. It probably won't, but the app we're reproducing is ripe for replacement and maybe our skunkworks project will be the basis for that replacement.
The majority of development that goes in is company-internal applications; stuff that company X needs or wants to do its everyday business.
I'd argue that this is potentially THE area for XUL to grab; a high percentage of those stupid VB apps that have been written over the years, with their massive deployment and maintenance issues (DLL hell, anyone?), could be replaced with XUL/browser front ends and have their ongoing maintenance costs slashed.
How do you upgrade a XUL app? Tweak the.xul files on the server/s. Change it in development, run it through testing, then deploy it onto prod servers in a minute or so. Problems? Put the old.xul files back
How do you upgrade a VB app? Change the code, then redeploy it to every user. Uh, oh - that user has upgraded to XP, and deploying the VB app involves overwriting a key DLL. That user's upgraded to Visio 2003; same problem with DLL versions. Sooner or later, to actually test this thing, we have to test it with the entire suite of desktop apps that are in use at the company. Don't forget that, although they're not supported, the CEO has a thing for Palm Pilots and hates the company-standard WinCE gadgets, so we've got to test it with the Palm Desktop as well. Oh, and we have to ensure that every user gets the upgraded app that night, because it's dependent on a back-end upgrade as well... Shit, now we've done that and found a problem with the new version in production; how do we back out the new version of the VB app? What do you mean we don't have a backout plan?
OK, so I'm exaggerating slightly, but not by much; testing and deploying browser-based apps, including XUL, is much much easier than client-server apps such as exist in corporates worldwide today. XUL could take that segment of the market over very quickly, **if a user friendly IDE was to appear**.
Assume that was to happen, even in say 20% of corporates. Now they've found that they can make big big savings by moving from VB to XUL/browser platforms, do you think they'll consider VB for their new app development? Not likely; they'll go with XUL and cut MS out of the picture.
Next they'll be up for replacement desktops; what was that reason we need Windows desktops again? OK, so our 500 customer facing people who get MS Office documents need Windows, but what about the 5000 users who spend their time totally in XUL/browsers and email? Is there something other than Windows that they could use, that would be at least as reliable? What about that Linux thing, that never gets viruses - could we use that?
I wouldn't say the above outcome is likely, but I think there's a definite possibility that it could happen in a number of large corporates. XUL is absolutely the key enabler, because XAML doesn't yet exist and MS doesn't have a solution in that space.
XUL is potentially a huge advantage that Firefox (and other Mozilla-based browsers) have over IE.
Using XUL, you can develop full-blown user interfaces that aren't limited to HTML-style text boxes, radio boxes, drop-down boxes and so on. Instead, you get access to trees, grids, menus, groupboxes, SOAP and XML-RPC client access and so on; a sizeable subset of what e.g. VB has to offer. It also understands CSS, so you can make XUL interfaces visually attractive if you're unlike me and actually have the patience to do so...
It's quite easy to develop XUL code as well, if somewhat time-consuming because there isn't yet a good, stable IDE available.
MS knows there's a market for this stuff, because it was developing XAML which meets broadly the same requirements. However a solid XAML implementation is currently a few years away at least, so XUL has a window of opportunity.
In case it's not obvious, here's why you'd use XUL instead of e.g. VB to develop application front-ends: - easy to deploy to clients (i.e. install e.g. Firefox, and that's it; no mucking around with DLL versions) - easy to maintain (i.e. tweak the code on a server rather than tweak and redeploy to every client) - already cross-platform (Windows, Linux, Solaris, Mac, BSD,...) - no dependence on ActiveX or Java to give the "rich client experience" - supports CSS and works with HTML, so competent Web designers should be able to pick up XUL without great difficulty. Someone please please please create an IDE to make this easy! - works with existing Web servers (e.g. Apache, IIS) without difficulty; after all, XUL is just XML text and Web servers have been serving text since day 1
In my experience, it's really tough to find people who can work on any enterprise-level apps well.
It's one thing to write a few VB apps when you can keep referring back to books or online manuals to show you the fine details of e.g. which fonts to use, but taking that level of VB knowledge and applying it to huge VB-based apps (yes, they exist!) is a leap that most people simply can't do. There's a point where you can't just focus on the minute details of your chunk of code; trying to adhere to project- or enterprise-wide coding and design standards is a really tough thing for many people.
As an example, think of all the "professional coders" you know. Now think of how many of them would know about design patterns, and would either refer to the Gang of Four book when needed or have it memorised to the point where they don't need to. I'm betting less than 10% of "professional coders" (yes, I'm using this term loosely) actually know of the existence of design patterns, yet they're absolutely fundamental once you start working on projects over a certain size.
Finally, I've found that really good coders are really good in just about any language (and project). A top C++ programmer will become a top Perl, VB, Eiffel, Ada, Python, COBOL(!!) programmer, given a bit of training on language features and documentation standards, as the same design patterns will work relatively independent of language syntax. I don't believe there's a shortage of enterprise FOSS people that's any greater than the shortage of enterprise closed source people; they're both in big demand.
The noise (from memory - it was a couple of years ago) was from the wind. When you're standing on top of a hill with nothing else around except this giant windmill, the sound of wind moving through the vanes of the thing was amazingly loud.
Having said that, you can hear the wind, but not feel it too much from below the windmill. Imagine being inside a building with the window open on a really windy day - you can hear the wind itself, but you can't actually feel much of it. Or standing on e.g. the south side of a building when there's a big north wind blowing; you don't feel the wind yourself, but you can see and hear the effects of it all around.
What was strange was that I walked all around the base of the windmill, and from every angle there was nowhere near as much wind I could feel compared to the wind noise I could hear. I kept thinking "the winds eventually gonna whack me in the face if I just keep walking around this thing", but it didn't happen. Not sure if that's unusual - it was a reasonably normal day and the thing was spinning around, but it wasn't particularly still or windy. It may be because the wind pattern at the base of the windmill is almost non-existent by design (i.e. the windmill is very efficient at converting wind energy to rotational energy, which would hardly be a surprise), or it may be due to something like the wind direction and the angle of the vanes on that particular day.
In hindsight, I could've walked around the windmill at larger and larger radii to see at what distance the wind started to hit me a bit harder, but I really was there to check out the Big Boy Toy and not out for a hike in the wilderness.
The windmill itself was essentially silent - there's no grinding or creaking noises, which is probably a good thing since one of these things falling over in a big storm would make a bit of a dent in the landscape....Right now I'm thinking I'll have to jump in the car and drive the 4-5 hours to check these things out again.
...I was amazed by: - how big it was (huge!) - how noisy it was (I sort of thought it'd be silent; not sure why...) - how still the air was immediately below it, even though the windmill itself was turning at a moderate rate
Quite an amazing piece of gear; if you ever get the chance to get up close to one, take it.
As far as I'm concered, anything that kills off this SCO stupidity is a good thing. I don't abide by the "the enemy of my enemy is my friend" logic; that pretty much ended when I worked out that Tweety, Sylvester and the big bulldog weren't real...
If Novell is the agent of SCO's destruction, I'll be happy. However, I'll be no more or less likely to purchase or recommend Novell as a result.
Agreed - I reckon this policy will expire right after the Webmaster at e.g. Microsoft, Oracle, Hewlett-Packard, Dell takes a vacation at exactly the wrong time.
Anyone like to guess what the conversation will be like when www.microsoft.com gets taken over by someone else? I'm guessing "Sorry guy, you shouldn't have taken that time off" won't be the end of it.
Although it'd be kind of nice to see www.georgewbush.com be taken over by someone else
At the moment, I'm a contractor and I take ~12 weeks a year off to play with my kids who are 8 and 6. While I'm by no means financially set for life, lack of money isn't an issue and I enjoy being part of my kids' childhood while I've got the chance.
Taking a role with this company would reduce my annual income by about 60%, force me to juggle investments to cope with the reduced income, slash the time I spend with my kids dramatically and *maybe* in a few years would give me enough money to be able to retire comfortably and not work again. Or maybe it wouldn't. Due to the discrepancy in income, the *only* real financial carrot they've got to dangle in front of me is stock / options.
However many times I look at it, it's not a good option. As far as I'm concerned, family trumps money, and at this stage they can only talk about imaginary money anyway.
Slashdot Mirror
> And the machines will fine tune and configure
> themselves.
No they won't, but with very few exceptions big companies don't fine tune machines. Read that again slowly - BIG COMPANIES DON'T FINE TUNE THEIR MACHINES. It is cheaper to throw in more hardware than to employ someone to tune a slow machine, except in extremely unusual circumstances.
Last year, I spent time reviewing performance data from ~7000 servers (Windows, Sun, Linux, HP-UX) for one large organization. Across those 7000 machines, guess what the average CPU utilisation was. 7%! That's not a misprint - 7%. Even when you looked at (mean + 3 standard deviations) of CPU utilisation (which shows where the machine spends 99%+ of its time), hardly any got above 20%. In other words, you could replace almost all of these machines with boxes that had 20% of the CPU grunt. Sure, there were a few big spikes, but almost invariably they occurred at backup time at e.g. 2am and lasted less than 5 minutes;I don't think anyone would have noticed if those spikes went on for 5-10 times as long. Other measures of machine utilisation showed a similar story of unused capability.
Now, maybe you work at places where they're trying to squeeze the last drop of performance out of systems, but this particular company spends literally *billions* of dollars each year on their IT and they obviously don't do that. Nor do any of the other companies I work at, most of which would spend in the hundreds of millions on IT each year. Sure, there's the odd exception here and there, where there will be one or two servers for one or two specific applications that get tuned, but that's about it.
> You obviously have no idea what it costs to
> provide true contingency, even with "cheap"
> hardware.
And in the places that I work, if you proposed walking in and tuning thousands of machines, you'd be laughed off site. Similarly, building machines is something that vendors and/or outsourcers do, so that every machine is in a notionally similar configuration and nobody has to manage a hundred different scenarios of machine configuration when it comes to e.g. updating a management agent.
There is almost literally no place for individual experts in these machine rooms; they're production line, factory-floor types of environments where uptime is king.
As someone else said, consider Google - a huge computing facility running solely Linux on commodity hardware. As has been reported many times, they don't even unrack dead boxes, probably because it's considerably cheaper to just buy/rent more floor space and throw in a new rack of 43 blade servers. That's the model that the world is moving to, and which Sun doesn't service at present.
Bottom line: we obviously work in very different parts of the industry, but I'd maintain that the customers I work for used to be Sun's bread and butter customers, but now they buy from someone else.
> There's a definite market for this kind of
...
> service. Just because you're not in it doesn't
> mean it isn't there.
I'm absolutely working in that market - over the last several years I've worked for large banks, massive telcos, global car manufacturers, the Tax Office,
These companies DON'T pay for that level of service; they engage outsourcers to do it for them. The outsourcers, not Sun, are paid to provide the love.
The outsourcers are selected primarily on price, so they cut corners wherever possible. When it comes time to replace a Sun box, the outsourcer recommends that the customer replace it with MS or Linux; that way the outsourcer can reduce their payments to Sun for support by hiring MS and Linux expertise themselves. As they generally get paid at least partly on a box-by-box basis, replacing 1 Sun with 2-3 Intel boxes is very good business for the outsourcer.
If you think I'm wrong, why else is MS and Linux replacing Sun in these data centres? Why do e.g. reputable banks run their Internet Banking on Windows servers? It's not for the reliability... Sure, there's still Sun boxes around, but they're now called "legacy systems" and left running e.g. Solaris 2.6.
Is the outsourcer's Linux and MS expertise as good as Sun's support? No way, but it takes the customer some time to work this out; at that time, they renegotiate their contract with the outsourcer from a position of weakness (i.e. customer has no in-house expertise left). The brave ones churn to the next outsourcing company
Is the customer able to pass off broken gear and apps to someone else to fix? Absolutely
Does the customer still get their lovin' from someone when things break? Yes; if not from the call centre person, then the call centre supervisor. If not the supervisor, then the account manager. And so on, up the tree. Meanwhile, behind the scenes, the outsourcer (generally a big company in its own right) is engaging Sun or whoever on a one-off basis, and the problem will get fixed. What the hell; maybe they'll even get a Sun engineer onsite(!!) to get things sorted, and thus the customer feels loved even more (note: by the outsourcer, not Sun)
Am I cynical about all this? You bet
You can argue that Sun *deserves* better, courtesy of stuff like ZFS, containers, ease of setup, "Solaris does things right" and so on. I won't argue the merits of that stuff with you, because I agree that they're very nice to have.
However, I don't think Sun will *get better*; it's doomed.
Two or three years ago, companies I worked for would go out and buy ~10 E10k or E15k boxes with not a lot of financial justification required; these were banks and telcos, so they had the money and they were willing to pay the premium price because Sun stuff was that much better than their competitors. "Nobody got fired for choosing Sun's Unix hardware" was pretty much a golden rule.
Those same companies, with the same people making the decisions, now buy Dell boxes to do the same task. In many cases, the apps running on the 3yo Sun boxes are being replaced by apps running on the new Dells. Each individual Sun box is still more reliable than the corresponding Dell (as I'm sure you know), but the cost difference is no longer justified. If/when a Dell box dies, admins throw in another one; that's how cheap they are.
On that topic, IT staff are a lot cheaper now too; using MS as an example, you can employ e.g. 2-3 "paper MCSEs" today for the price of a 2000-era Sun guru. So what if the MCSEs aren't that great? 95% of their job is to use Ghost to image new Dells every few days; if they don't like it, they can leave and someone else will replace them. If you're a big IT shop, you just don't need that many guru-level people around these days to keep gear running. Apologies if that dose of harsh reality offends...
I've got no idea if the following figures are correct, but the big Suns might be up 99.999% of the time and the Dells would be up 99.9% of the time. That used to be a big deal, but throw in a second (clustered) Dell box and now you've got the same hardware uptime in terms of impact on service delivery. What the hell, throw in 4 or 5 Dells to replace one Sun and be done with it; you'll still save wads of money.
Suns were good when the competition was crap. Now the competition is "good enough" (in uptime terms, which is what CIOs understand) and a lot cheaper, so out go the Suns.
Yep, you're right on both counts. However...
Every Sun purchase I've seen has been ultimately driven by support and reliability/uptime. Sun recognised this, and focused on building hardware and software to address reliability/uptime in particular. What's changed is that, while Solaris has more features than Linux in some ways, those features are primarily related to uptime which isn't that big a deal any more.
Why not?
- for every useful feature that Sun adds in, someone in Linux-land will eventually see that feature as a good thing and work will be done to port that feature to Linux. The porting to Linux of an existing Sun feature can be done faster than Sun can think up and build new features, and as Linux pushes more and more into the enterprise, the focus will become more and more on replicating Sun's advantages in Linux. The numbers are simply against Sun managing to stay ahead
- to a very large extent, you can achieve uptime by scaling "wide" i.e. throwing more boxes at the problem. It's absolutely not a panacea to all uptime issues, but it's an approach that fits particularly well with Linux/Intel due to the low incremental cost of the hardware. Whatever "uptime smarts" Sun can add to their OS, I and many others can achieve the same results (in pure uptime terms) by bolting a bunch of new Intel boxes into a rack
Embrace Linux, then use their still-excellent support services to offer enterprise-level Linux support.
While there's players in that area today, there's certainly room for Sun to make some very big dollars. I could well see Sun becoming a very successful services company; EDS is obligingly stepping out of the way in a timely manner...
Will they do it? No - I think Sun management is arrogant, inwardly-focused and too tied to their glory days to the point that they would see such a move (i.e. switching from high-margin hardware to slow-and-steady services as their primary source of revenue) as untenable
Sun still has to address the issue that their old market seems to have gone away to a large extent. While it made sense 5 years ago to drop ~$500k on an E10k box to get reliability and support, nowadays you can get that same reliability for much less by using piles of clustered Intel hardware and a fairly-competent Linux or BSD admin.
...), so I just can't see why people would go with Solaris these days.
Outside of academia, the only reason people bought smaller Sun boxes is so they could develop for Sun's big iron with minimal migration issues at deployment or "scaling up" time. With the disappearance of Sun's big iron market, their low level market disappeared as well.
Open sourcing Solaris 10 is fine and dandy, but I think it's too little too late. There's brands of Linux and BSD (e.g. RHES, Debian, SE Linux, OpenBSD) that cover every one of Sun's old sweet spots (e.g. uptime, security, Oracle support,
Bottom line: Where is their sweet spot for selling their product? Why would I buy Sun these days?
It's a pity - Sun had a terrific product line that no-one else could match, but they didn't see the tide turning.
www.live-shot.com
Note: you get to shoot at real live SHEEP!!!
Anyone who's a subscriber and has actual pics of this thing in action, HAS to post some pic links
...that can only end in tears.
Possible scenarios that occured to me within first 30 seconds:
- Internet hunter shoots animal, some human goes out to retrieve it. Oooh, what will the next hunter that gets online fire a shot at?
- "something goes wrong" and the system becomes unreliable. Who's going to onsite to fix the thing, while it's playing up?
- it's all a big con, and when you think you're "hunting" you're actually watching a carefully prepared film
- parachute one of these things into Fallujah, then auction off rights to "The Real Deathmarch 2004, with added reality"
Anyone care to round out a top 10 list? I would, but I'm at work, about to walk into a meeting and wishing I had one of these with me right about now...
> Why, if Australians are training the Chinese
> expeditioners, are they doing it in Fremantle?
They started training them in Ballarat, but even elite Antarctic explorers can only take so much cold weather...
I'm hoping you USians stand up and actively use civial disobedience to get this sort of rubbish thrown out. To your country's credit, you've got a history of this sort of activity that effectively adds an extra level of government that is only rarely required.
If you don't do it and this type of idiotic law becomes commonplace, then your country will progressively push it out to the rest of the world via "Free Trade Agreements" and similar tautologies. Unfortunately, we don't have a strong record of using civil disobedience, or anything like a Bill Of Rights, in Australia, so chances are laws such as this will quietly be accepted here.
> So I'm writting software for buisness methods. A
> double whammy. According to a number of people on
> thee forums I shouldn't be able to make money at
> what I do...
No, I don't think anyone in Slashdot would deny you the right to earn a living at it whatever you choose, unless it's working for SCO. Or you're based in India. Or you use Microsoft products to do it...
What is regularly questioned is the right to *patent* business methods and software. What is wrong with the existing system of copyright for protecting such things? The main impact of patenting your work (vs. copyright) is that you can prevent others being able to both produce the same thing in a different way *and* coming up with the same thing independently.
One part of the argument that appears to have been turned around over the previous several years is that you (the individual) are *requesting* a patent from us (the public), on the grounds that your advancement is so good and has chewed up enough of your time and resources that the rest of us should be prepared to pay you what amounts to a tax for using your stuff. You should be convincing us how insanely great your advancement is, and that you should be compensated for it into the future so that you can go build your next insanely great advancement. That was the original intention of patents.
If you're manufacturing widgets, in this day it's quite difficult to believe that your widget is THAT much of an advancement that a patent could be justified on those grounds. Maybe if you've invented e.g. a jet engine that consumes 20% less fuel and can save airlines millions of dollars a day, you'd have an argument, but that's the kind of advancement that you'd have to come up with in this day and age.
To apply patents to software, you have to accept the following:
- *every* piece of code you're producing builds heavily on the work of others. You may be hitting databases, using HTML or XML, using C++ or Java, using queues, whatever; every one of those advances was made by someone else and you're almost always going to be adding your 1% on top to build your thing. I would argue that your incremental 1% contribution had better be pretty amazing to justify a patent
- in fact I (the public) could reasonably argue that the entire software industry as it exists today is built on tiny incremental advances over what existed yesterday, and that you'd need to invent something of the magnitude of "the database" or "the spreadsheet" to not have me laugh at your patent application and throw it back at you
You have to look back to history to see just how ridiculous the idea of patentable business processes are:
- suppose Henry Ford patented "the assembly of manufactured products via production lines". I can't conceive of another business process that is equivalent to that in terms of breakthrough, but if Ford was allowed to patent that process, where would we be now? What would our manufacturing industry be like?
- suppose Nokia patented the mobile phone (OK, it probably wasn't Nokia who invented them, so substitute in the correct company name). It too allowed a huge advance over the way business and personal communication was done, but where would the public interest component be if Nokia was granted a business process patent for mobile phones?
Double-entry accounting; offering the service of consultants to assist businesses make decisions when they don't have the expertise in house; monitoring production computer systems using software agents; online banking; telephone IVR systems - if you think about it, you can name endless numbers of business processes that must have seemed like big breakthroughs at the time, yet patenting them would have left the world a much worse place. If one company owned patents over any of the above, they could essentially be holding the rest of the world to ransom today, and there's no reasonable justification for their being in a position to do so.
So go ahead and write your business
> That doesn't mean I don't value the
> crazy-hour-worker. It just means I value the
> seasoned veteran who knows how to get the job done
> quickly more because he's better at the job.
My thinking is different. As a contract manager who both codes and employs coders, my perspective may be useful to some people here.
I don't value the crazy-hour-worker, because I know it's not sustainable and the chances are the point where that becomes apparent will exactly coincide with that person being on my critical path. If someone can't get their job done in ~40 hours, either they're not up to the job or we've stuffed up our estimations; I can generally work out which of those 2 it is without too much investigation. Once I've worked out which it is, I'll either have to rejig my project plan or shed the person, and I'd rather not have to do either.
There are plenty of (mostly young) people who appear to work like crazy, but are only doing productive work 40 hours/week and the rest is spent on either their own research or stuffing around and probably disturbing others. Either way, as a rule I'll boot them out after 40 hours because they can do their research or stuff around outside of work.
I value the seasoned veteran, because I know he or she will produce an outcome to a deadline that they agree to. If a task is going to take 4 weeks, they don't say "I'll do it in 2" then trash my project plan when it blows out. They also don't work like maniacs to try to finish it in 2 weeks, because that will burn them out and stuff up my plan later on. Crazy Hours Guy may say he'll do it in 2, and maybe he'll actually do so 50% of the time; give me the guy who says he'll do it in 4 weeks, and does so 99% of the time, every time.
There is nothing, NOTHING more annoying to a project manager or team leader than having to rejig a project plan at short notice because someone is working in an unsustainable manner. That one person's incompetence (and I call lack of time management skills "incompetent" in a supposed professional) is going to have a massive impact on a project schedule, and potentially cause disruption to many peoples' lives while they try to untangle the mess.
Every now and then, I wind up with Crazy Hours Guy, but if so I make a point of never relying or employing him again.
> There's a simple rule that I like: if you (as a
... - whatever it took to get everyone (and me!) out the door as early as possible.
> manager) call overtime, you will work the same
> hours.
On the very rare occasions that I've had to have people work overtime, that's the rule I work to as well - I'll hang back too till the last person leaves.
As far as not being able to make a contribution goes, well I'm a coder too so I can generally help out. However, if I wasn't I'd be hauling coffee, pizza,
Hard to understand how the games industry survives with what seems to be a common practice of 60-80+ hours per week for extended periods. Then again, given the number of bugs in most games that get released, quality seems to have gone down the toilet anyway; most games sold are part of a "franchise" so people just buy 'em regardless of whether they're any good or not.
Don't suppose you could post either a description or code fragment, or point me to a reference site? I've got to investigate XUL socket IO in the next few days myself...
Thanks in advance
> There has been a perception that once CA purchases
> a product, they run it into the ground. Has that
> perception been difficult to overcome with Ingres?
> Gaughan: Personally my knowledge of CA when I
> joined the company was pretty much along the lines
> of what you outlined.
Gaughan then goes on to explain that things have now changed, yada, yada...
My impression of CA is certainly along the interviewer's lines; they acquire stuff and milk it to death, not upgrading it, not supplying important patches and presumably living off the support revenue.
In fact, as I write this, there's a CA technical support guy (yes, they do exist!) onsite two desks over working with one of this company's techos. CA's challenge: convince us that Harvest, a CA source management product that seems locked in the past feature-wise but is costing us $$$ for support and maintenance, has any serious compelling features over and above Subversion.
I, and I suspect many others, will find it tough to believe that CA have suddenly "seen the light" and will start actually developing, supporting and enhancing the assets they have as opposed to selling something and providing excuses from that point on.
On the Ingres topic, I've downloaded it but probably won't look at it seriously unless/until I'm convinced it offers something over Postgres (free, usually good enough) and MySQL (free, well supported, fast and good for read-only apps) on the one hand and SQL Server/Oracle/DB2 (expensive, very powerful and scalable) on the other. Last time I used Ingres was 2 years ago, but my impression then was that it hadn't progressed significantly in the preceding 10 years (i.e. it was a typical CA product).
Yes. Chatzilla is an IRC client built in XUL that does that now, but it sounds like you're probably in it as much for the challenge as anything else.
Two broad approaches are obvious to me:
- use a Jabber or similar standards- and server-based solution, and just use XUL to generate, capture and display the appropriate Jabber messages. You might need an XML-RPC or SOAP front end "in front of" Jabber that you talk through, or maybe you'll be able to do it using socket IO directly from XUL to Jabber
- build your own peer-to-peer solution. I've got no idea if there's standard protocols you could use, but it might be a lot of fun if that's your bag
Either way, it's definitely possible
I've had a skunkworks XUL project going on for a couple of weeks now. I'm fortunate(?) enough to have a Web guy working with me who isn't addicted to WYSIWYG tools, and he and I are busily recreating an existing production VB app in XUL.
I have to admit I went into this with the attitude of "Let's see how far we get. I know we're gonna hit a killer roadblock at some point, but it'll be interesting to see how far we get before that happens". Now, with a demonstrable if unfinished and slightly crappy looking app already built, I can say:
- there doesn't appear to be a roadblock. We've managed to use both XML-RPC and SOAP (had to try them both!) to talk to backend systems, and we've used this for stuff like database and mainframe access which is one area where I thought we'd hit problems. We can do synchronous and async screen updates, which adds a sizeable usability benefit over regular browser apps. We've used JavaScript for client-side data validation, and basically reproduced all the functionality in a fairly typical business VB app circa 2000 without any compromise at all which was a big surprise to me
- writing XUL code is actually a lot of fun. Small amount of effort for a big result, which is always a nice aspect
- there's a lot of possibilities to use XUL "mini apps" as functional test beds for Web services development. Haven't explored this yet, but it seems like that could be an approach we look at in the near future
- it's been pretty easy to get stuff working, but more time consuming to get it looking exactly the way we want. In fact, several times we've forked the code and gone separate ways trying to solve a particular UI problem, which is probably not ideal but certainly quite productive in such a small project where there's no real problem "unforking" once a solution has been identified
Whether this project actually goes the next step and gets some formal testing is another matter. It probably won't, but the app we're reproducing is ripe for replacement and maybe our skunkworks project will be the basis for that replacement.
The majority of development that goes in is company-internal applications; stuff that company X needs or wants to do its everyday business.
.xul files on the server/s. Change it in development, run it through testing, then deploy it onto prod servers in a minute or so. Problems? Put the old .xul files back
I'd argue that this is potentially THE area for XUL to grab; a high percentage of those stupid VB apps that have been written over the years, with their massive deployment and maintenance issues (DLL hell, anyone?), could be replaced with XUL/browser front ends and have their ongoing maintenance costs slashed.
How do you upgrade a XUL app? Tweak the
How do you upgrade a VB app? Change the code, then redeploy it to every user. Uh, oh - that user has upgraded to XP, and deploying the VB app involves overwriting a key DLL. That user's upgraded to Visio 2003; same problem with DLL versions. Sooner or later, to actually test this thing, we have to test it with the entire suite of desktop apps that are in use at the company. Don't forget that, although they're not supported, the CEO has a thing for Palm Pilots and hates the company-standard WinCE gadgets, so we've got to test it with the Palm Desktop as well. Oh, and we have to ensure that every user gets the upgraded app that night, because it's dependent on a back-end upgrade as well... Shit, now we've done that and found a problem with the new version in production; how do we back out the new version of the VB app? What do you mean we don't have a backout plan?
OK, so I'm exaggerating slightly, but not by much; testing and deploying browser-based apps, including XUL, is much much easier than client-server apps such as exist in corporates worldwide today. XUL could take that segment of the market over very quickly, **if a user friendly IDE was to appear**.
Assume that was to happen, even in say 20% of corporates. Now they've found that they can make big big savings by moving from VB to XUL/browser platforms, do you think they'll consider VB for their new app development? Not likely; they'll go with XUL and cut MS out of the picture.
Next they'll be up for replacement desktops; what was that reason we need Windows desktops again? OK, so our 500 customer facing people who get MS Office documents need Windows, but what about the 5000 users who spend their time totally in XUL/browsers and email? Is there something other than Windows that they could use, that would be at least as reliable? What about that Linux thing, that never gets viruses - could we use that?
I wouldn't say the above outcome is likely, but I think there's a definite possibility that it could happen in a number of large corporates. XUL is absolutely the key enabler, because XAML doesn't yet exist and MS doesn't have a solution in that space.
XUL is potentially a huge advantage that Firefox (and other Mozilla-based browsers) have over IE.
...)
Using XUL, you can develop full-blown user interfaces that aren't limited to HTML-style text boxes, radio boxes, drop-down boxes and so on. Instead, you get access to trees, grids, menus, groupboxes, SOAP and XML-RPC client access and so on; a sizeable subset of what e.g. VB has to offer. It also understands CSS, so you can make XUL interfaces visually attractive if you're unlike me and actually have the patience to do so...
It's quite easy to develop XUL code as well, if somewhat time-consuming because there isn't yet a good, stable IDE available.
MS knows there's a market for this stuff, because it was developing XAML which meets broadly the same requirements. However a solid XAML implementation is currently a few years away at least, so XUL has a window of opportunity.
In case it's not obvious, here's why you'd use XUL instead of e.g. VB to develop application front-ends:
- easy to deploy to clients (i.e. install e.g. Firefox, and that's it; no mucking around with DLL versions)
- easy to maintain (i.e. tweak the code on a server rather than tweak and redeploy to every client)
- already cross-platform (Windows, Linux, Solaris, Mac, BSD,
- no dependence on ActiveX or Java to give the "rich client experience"
- supports CSS and works with HTML, so competent Web designers should be able to pick up XUL without great difficulty. Someone please please please create an IDE to make this easy!
- works with existing Web servers (e.g. Apache, IIS) without difficulty; after all, XUL is just XML text and Web servers have been serving text since day 1
In my experience, it's really tough to find people who can work on any enterprise-level apps well.
It's one thing to write a few VB apps when you can keep referring back to books or online manuals to show you the fine details of e.g. which fonts to use, but taking that level of VB knowledge and applying it to huge VB-based apps (yes, they exist!) is a leap that most people simply can't do. There's a point where you can't just focus on the minute details of your chunk of code; trying to adhere to project- or enterprise-wide coding and design standards is a really tough thing for many people.
As an example, think of all the "professional coders" you know. Now think of how many of them would know about design patterns, and would either refer to the Gang of Four book when needed or have it memorised to the point where they don't need to. I'm betting less than 10% of "professional coders" (yes, I'm using this term loosely) actually know of the existence of design patterns, yet they're absolutely fundamental once you start working on projects over a certain size.
Finally, I've found that really good coders are really good in just about any language (and project). A top C++ programmer will become a top Perl, VB, Eiffel, Ada, Python, COBOL(!!) programmer, given a bit of training on language features and documentation standards, as the same design patterns will work relatively independent of language syntax. I don't believe there's a shortage of enterprise FOSS people that's any greater than the shortage of enterprise closed source people; they're both in big demand.
I should've been more specific
...Right now I'm thinking I'll have to jump in the car and drive the 4-5 hours to check these things out again.
The noise (from memory - it was a couple of years ago) was from the wind. When you're standing on top of a hill with nothing else around except this giant windmill, the sound of wind moving through the vanes of the thing was amazingly loud.
Having said that, you can hear the wind, but not feel it too much from below the windmill. Imagine being inside a building with the window open on a really windy day - you can hear the wind itself, but you can't actually feel much of it. Or standing on e.g. the south side of a building when there's a big north wind blowing; you don't feel the wind yourself, but you can see and hear the effects of it all around.
What was strange was that I walked all around the base of the windmill, and from every angle there was nowhere near as much wind I could feel compared to the wind noise I could hear. I kept thinking "the winds eventually gonna whack me in the face if I just keep walking around this thing", but it didn't happen. Not sure if that's unusual - it was a reasonably normal day and the thing was spinning around, but it wasn't particularly still or windy. It may be because the wind pattern at the base of the windmill is almost non-existent by design (i.e. the windmill is very efficient at converting wind energy to rotational energy, which would hardly be a surprise), or it may be due to something like the wind direction and the angle of the vanes on that particular day.
In hindsight, I could've walked around the windmill at larger and larger radii to see at what distance the wind started to hit me a bit harder, but I really was there to check out the Big Boy Toy and not out for a hike in the wilderness.
The windmill itself was essentially silent - there's no grinding or creaking noises, which is probably a good thing since one of these things falling over in a big storm would make a bit of a dent in the landscape.
...I was amazed by:
- how big it was (huge!)
- how noisy it was (I sort of thought it'd be silent; not sure why...)
- how still the air was immediately below it, even though the windmill itself was turning at a moderate rate
Quite an amazing piece of gear; if you ever get the chance to get up close to one, take it.
As far as I'm concered, anything that kills off this SCO stupidity is a good thing. I don't abide by the "the enemy of my enemy is my friend" logic; that pretty much ended when I worked out that Tweety, Sylvester and the big bulldog weren't real...
If Novell is the agent of SCO's destruction, I'll be happy. However, I'll be no more or less likely to purchase or recommend Novell as a result.
Agreed - I reckon this policy will expire right after the Webmaster at e.g. Microsoft, Oracle, Hewlett-Packard, Dell takes a vacation at exactly the wrong time.
Anyone like to guess what the conversation will be like when www.microsoft.com gets taken over by someone else? I'm guessing "Sorry guy, you shouldn't have taken that time off" won't be the end of it.
Although it'd be kind of nice to see www.georgewbush.com be taken over by someone else
At the moment, I'm a contractor and I take ~12 weeks a year off to play with my kids who are 8 and 6. While I'm by no means financially set for life, lack of money isn't an issue and I enjoy being part of my kids' childhood while I've got the chance.
Taking a role with this company would reduce my annual income by about 60%, force me to juggle investments to cope with the reduced income, slash the time I spend with my kids dramatically and *maybe* in a few years would give me enough money to be able to retire comfortably and not work again. Or maybe it wouldn't. Due to the discrepancy in income, the *only* real financial carrot they've got to dangle in front of me is stock / options.
However many times I look at it, it's not a good option. As far as I'm concerned, family trumps money, and at this stage they can only talk about imaginary money anyway.