I agreed to the deployment of timely security and software updates, not to the arbitrary removal and resulting breakage of my systems. If Canonical proceeds with removing the sun-java packages from my machine instead of merely removing them from their distribution repositories, I'll be removing Canonical and going with a distro that understands the importance of not breaking user's machines.
However, I seriously doubt either Oracle or Ubuntu would be so stupid as to break production systems around the world in such a fashion.
I don't blame Oracle for dropping Canonical's distribution. Historically they've always provided their own installers. But they really need to start providing.deb installers as well as.rpm. Using "alien" may work, but it's rather distasteful for production systems to do so. Application and server producers don't want to be in the business of packaging software for installation. And Oracle should really reconsider the benefits of having an automatic distribution engine like Ubuntu's repositories, or start up their own repository server that can be trivially added to the set that Ubuntu queries every time it runs, the same way you can add repositories to Eclipse.
My bigger beef is not the screen size, but the keyboard size. I've yet to try a netbook with a usable keyboard, and if I can't use the keyboard, I may as well not have one at all and go with a tablet device.
However, in reality I'm more inclined to look at 14 inch and 15.6 inch laptops. Most of my computer use involves typing, not consuming. I'll be choosing a unit based on input devices, not size. I need a usable keyboard. I need enough memory to run things. I need one of the old IBM style eraser-nub "mice" instead of a trackpad.
As far as I know, that means I'll be buying a Lenovo. I've never seen anyone else use the erase nub inputs, and I hate, hate, hate, hate HATE trackpads!
And when I'm producing, I want a screen that shows me a reasonable amount of what I'm producing. I can't see that happening with a 10 inch screen or even smaller.
I can see the utility of a tablet, but netbooks have never and will never make sense to me.
KDE is not a full GUI. Qt is the GUI toolkit; KDE is the applications built with the toolkit.
The term "desktop" has become synonymous with "window manager". The general public thinks GUI means Windows or Mac already; let's not get too pedantic.
I did download and play around with Kubuntu for 10.04.1 out of curiosity. It's much slower to load than Gnome 2, and seems to be a rather cluttered metaphor for my tastes. LIttle boxes and lists of stuff all over my desktop, which I don't like. Show my desktop icons; don't give me a window of desktop icons. If I wanted them grouped or hidden, I wouldn't put them on the desktop in the first place, now would I?
I liked their take on the start/launcher concept, in particular stitching some of the configuration into tab panes of the launcher. I'd rather see the second tab with the "traditional" menu as my initial tab, though, or be able to configure my own list of "main menu" launcher apps to provide functionality equivalent to my littered Gnome toolbar (Firefox, Thunderbird, Eclipse, Mono, pgAdmin, Pidgin, Rhythmbox, Terminal, Opera, Chrome, Vuze, Filezilla, K3B, DVD Styler, Open Office, and GNU Cash.) I don't like to have to futz with menus to get at the stuff I use the most.
One thing going for KDE -- it's very responsive once it starts up. Gnome feels almost sluggish in comparison on this box. But there's a price to pay for that: an absolutely obscene startup time. WTF are they loading that takes so damned long -- over 20 seconds to boot a WM? WTF? I haven't seen boot times that slow since Win2K, and KDE was not fighting with PostgreSQL, Oracle, and DB/2 for startup memory and processor time like Gnome usually is (I'm impatient and log in long before the box is done it's startups and recoveries.) Gnome 2 startup is like lightning in comparison to KDE.
I've also been reviewing the widget hierarchies and APIs for Gnome and KDE. I hate to say it, but the organization of the Gnome 2 widget hierarchy is NOT what I'd call intuitive. I think the KDE team has done a much better job of things, but as they started with an abstraction kit that was designed to abstract the GUI as a whole, not just the parts needed to implement Gimp, it only stands to reason that KDE ended up being a better designed widget hierarchy.
I'm very uncomfortable with looking any further at Gnome's programming APIs. Qt is far cleaner and richer, and as I'm not interested in KDE specifically, but Qt's portability, I think I've decided which I'll be doing my future native Linux GUI work with. The fact that I get Windows support as well with the one code set is a huge added bonus.
I'd previously evaluated the two toolkits with an eye towards how good they did on the Windows application side, and came to the same conclusion.
So that's 1 to Gnome 2 for usability and clean desktop metaphor, but 2 to KDE/Qt for portable programming sanity.
And I think every UI that's taking the candy-coated single-task with big launch buttons metaphor approach is spending too much time telling themselves how neat their cell phone or tablet device is, and not enough to how people USE A COMPUTER!
First, my pet peeve about the new frontiers of user interface design:
Apple apparently has a huge legal team of people with nothing better to do than patent things which should have been published as standards for use by anyone, the same as IBM did with the Common User Access style guides that drive virtually every computer GUI on the planet to date. It's what allows one fanboy to sit down at another fanboy's machine and still get something done because it all works largely the same.
The KDE, Gnome, and Unity teams would be well advised not to ignore decades of research and practical use by the entire computing industry and user community when designing their GUIs. Start with the CUA and go from there. Any divergence from the CUA defaults should require user configuration at either the desktop or application level.
Their ideal on what should be configurable and what should follow the defaults is one area where they'd diverge.
Another area is the practical implementation of the widgets used by the GUIs. CUA is in desperate need of a widget catalogue refresh, along with standards for how the user interacts with that conceptual data. Things like calendar pickers and colour pickers should be part of a new CUA that deals with GUI and Web metaphors; CUA itself was adaptable to early GUIs, but we've got a richer set of presentation standards to add now.
Imagine having a common XML format that defines an abstract GUI, implemented by the desktop designers as a translation of that general XML description to the platform-specific widget toolkit and behaviour standards. I know I could do that with any older UI thanks to the core CUA concepts, but what else should be part of such a new CUA?
IBM did a good job coordinating the original CUA. Maybe someone can convince them to work with the desktop teams to come up with CUA2.
I think we're talking about a philosophical difference of what a "hardware manufacturer" is vs. a "hardware design house." Apple is the latter, and used to be the former. They've farmed out all the production, and are no longer a hardware manufacturing company, but exist only as a hardware design company with a supporting software division.
And, apparently, a huge legal team of people with nothing better to do than patent things which should have been published as standards for use by anyone, the same as IBM did with the Commun User Access styleguides that drive virtually every computer GUI on the planet to date. It's what allows one fanboy to sit down at another fanboy's machine and still get something done because it all works largely the same.
And on that note, the KDE, Gnome, and Unity teams would be well advised not to ignore decades of research and practical use by the entire computing industry when designing their GUIs. Start with the CUA and go from there. Any divergence from the CUA defaults should require user configuration at either the desktop or application level.
In Saskatchewan, we have a Crown Corporation that is responsible for maintaining, updating, and distributing that map data for the province. It's accurate data -- collected using actual transits and GPS systems. Google can not improve on the data quality by reading street signs with AI at all.
I suspect it has a lot more to do with licensing issues for Google wanting to republish the data to the general public, something that I'm sure our crown corp would frown upon as it would cut out their geodata sales market. Google wants a royalty-free data source, not better data quality.
I disagree completely. KDE's configurability is asinine. When KDE apps run under another WM, they use their own KDE defaults like click-to-activate vs. click-to-select, double-click-to-activate. It's annoying as hell to run K3B under Gnome 2, because it does not behave like anything else on my desktop. The only reason I put up with it is that they did the best job of a burning utility I've seen since Nero, and maybe even better than Nero (note I'm talking the old "advanced" Nero tools, not the shiny crapware wrappers they install be default with the new releases.)
With the way KDE is structured on top of Qt, it should be possible for a KDE app running under Gnome to detect that fact and "import" it's settings and defaults from Gnome's environment. The reverse should also be true.
It's almost to the point of frustration that I prefer applications that just ignore any standards at all and do their own thing entirely. At least they're consistently screwed up, following their programmer's diabolical visions of UI hell imposed on the user community.:p
You mean there are still people naive enough to think that "secrecy" will protect their idea?
Guess what -- ideas aren't new in 99.999% of cases. They were originated by science fiction authors and science journal pundits/researchers decades or even centuries ago. We still haven't implemented some of the ideas that creative minds like Newton or Jules Verne came up with, much less dealt with the practical side of the philosophical issues around artificial intelligence vs. "human" rights raised by Dr. Asimov.
This is the main reason I feel nothing but contempt for the entire concept of the patent system. Only an implementation of something should be patentable, and in the case of software, copyright and licensing already provide that protection. The idea of patenting business ideas and processes, user interface standards such as touch screen gestures or Bezos' "1-click" are absolutely asinine, laughable, ludicrous, and criminally negligent of paying attention to reality.
The best defense is a good offense -- get your source code out there under a protective license so that when the inevitable patent lawsuit troll shows up, you can point to umpteen years of public development and say "You should have known about this before filing for your patent. I have prior art. Publicly accessible prior art. You didn't even Google to see if someone already came up with the idea. Now Eff Off with your lawsuit!"
The netbook has always struck me as the stupidest computing idea I'd ever heard of. A "machine" with a screen too small to see, a keyboard too small for my fingers, and too little memory or power for anything more complex than browsing a website.
The pad is a far more effective form factor for serving that ultra-portable not-a-real-machine market.
The netbook was the mutant offspring of low power CPUs and the evil dreams of a wanna-be marketing overlord, not sound engineering or impressive technology.
You can't survive on what some immigrant workers accept for pay, either. High living cost areas in the US and Canada are notorious for painting their wages as "high", and they are, relative to the poorer areas some immigrant labour comes from. I mean economic immigrant to a "high pay" area, not necessarily a foreigner.
But when they get there, they find themselves forced to room with several people to get by, living in conditions no better than they did at home in order to send a significant chunk of their pay home. It's the tech equivalent of the "Alberta Oilsands Lifestyle" -- long hours, brutal living expenses, and relatively high pay for short periods followed by trips home to survive unemployment while looking for the next contract.
However, they already get paid less than a "local" worker with a house, family, tuition expenses, healthcare expenses, etc. at the high local costs can afford to. The "immigrants" come from areas where most of their costs of living are lower.
I've lost count of how many times I've had to abandon a market because the cheap immigrant labour companies swamped the market at cut-throat rates. Then along came actual overseas outsourcing, and even those jobs disappeared entirely.
It may be supply and demand, but the cheap supply markets show no mercy on the countries with the demand. The only saving grace we have is that many of the cheap overseas sweatshops produce crap, or pad their bills through incompetence and low productivity. Unfortunately it takes management getting burned a few times before they realize that you get what you pay for and start hiring local talent at decent rates again. And the growth of the local talent market is a lot slower than the growth of the doomed project farmed out to the lowest bidder.
Automation will make the grunt coder obsolete soon enough, the same as it's done to every other low-skilled labourer for millenia. "I'm a programmer" doesn't mean what it used to -- the tools are a lot easier to work with nowadays, and there is a lot more experience that's been documented and reproducible than there used to be 20 years ago.
No one gets paid to read core dumps any more, and I can't say that I miss that aspect of old style computing at all. Live code editing during a breakpoint rocks for productivity. Similarly, manufactured code is simply more cost effective than manually produced source. It may not be as "elegant", but it works, and works well enough to get the job done. In the end, that's all that matters -- getting the job done.
It's what everyone gets paid for.
Except for bank executives and CEOs who rake in bonuses for gutting companies and losing money. I don't know why we pay those people anything at all. They're incompetent and greedy, and bad for the future of any business.
Which is what I like about it. The GPL lets you get code out there for sharing and development, but blocks businesses from integrating it with their technology unless they pay for a license agreement. For my needs, GPLv3 is a near ideal publication license, supplemented by proprietary commercial licenses.
Any time I've wanted to share code without hope of revenue, I've released it under LGPL instead.
But as my wallet remains empty and the donation counter is $0, I have NO interest in letting any leeches use it anymore freely than is permitted by the GPLv3. Screw the freetards.
Poor phrasing on my part. The big numbers don't actually leap into the next level beyond trillions. But they still are mind boggling. They're the kind of numbers that get hockey stick business planners thinking "if I can only get a fraction of a percentage point of that..."
Buddy, if you can look at numbers that exceed trillions and claim they honestly seem like reasonable and rational values compared to a sub-six-figure income, you're either a mathematical genius or a liar.
As to the idiot who claimed I was "one of those responsible", is there anyone who actually thinks the peon hordes who work at banks or big corporations are collecting the fat-cat bonuses? We took pay cuts in 2000 after the big push for Y2K was over; we did not get bonuses for helping the bank ride out the paranoia.
And the systems programmers are not responsible for designing risk analysis algorithms, only implementing them.
I'm proud of the work I did for JPMC. We delivered a critical system in record time after the project was put at risk by two years of fiddling around accomplishing nothing. We improved it's reliability and speed over it's predecessor. And we did get bonuses for that one, just not for the Y2K work.
We deployed a new version of a third-party product, and came up with migration scripts to get the data over from the old mainframe version. The vendor had contracted to do the same with Citibank's copy of the software, spent two years of vendor consulting time and a 20 person team, and failed.
Our competent team of four not only did the job the product vendor themselves could not, but we automated the process, and we did so in under a year. It just goes to show what happens when you get four good programmers working on something instead of a horde of average incompetents paid for by a virtually unlimited budget.
So, was I "one of those responsible"? Not in the sense of making decisions, but in providing successful deployments of software supporting the decisions of management. I feel no shame for being good at my job, and rather pissed off that management obviously ignored what was reported by the systems my cohorts worked on.
I'm not speaking to JPMC specifically because I had no contact with the Citibank branch of the merger that had the consumer loans and mortgages, but to banking in general. It's not the risk analysis engines that produced the bad loans, but the individual loan managers who had the option of ignoring the risk reports and apparently did so.
Exactly. It's management and the risk analysis team that decides what gets considered by the algorithms, not the programmers who have to implement the algorithms and systems.
Do you think a properly implemented set of risk analysis points would have allowed loans to sub-prime mortgage holders in the first place? It wasn't risk analysis that did that; it would have been overriding management-imposed company policy. It didn't take a genius to realize that people who couldn't come up with their downpayments in the first place probably wouldn't be able to afford the interest increases after the initial term.
The people who signed those mortgages should have thought about whether they could afford market rate mortgages, not whether they could afford the "low, low introductory price" of a few year's subprime mortgage to start. Sure the banks raped them by bumping interest rates, but only a complete moron would have expected the banks to continue to leverage loans at a loss!
Dirty pool by the banks? Yes. But no more so than when anyone else uses a "loss leader" product to "buy" the high-value add-on sales that follow.
The problems the risk analysis team faced even in the 2000 era was such a tough nut to crack that they had to limit the complexity of the algorithms they used just because there wasn't hardware powerful enough.
All the things you mentioned have only added to that complexity, making the calculations that much worse and that much more expensive.
So instead of making me change my mind, you just made me realize how much more impressive their achievement was than I first thought.
Spreadsheets back then did not have arbitrary precision decimal or integer values -- they used floating point. I have no idea whether newer spreadsheets have shifted to arbitrary precision values or not, but if they haven't the spreadsheets blow up.
Remember: little companies like GE, GM, and Exxon are the kind of customers who have deposits with an investment bank. As a result, numbers like total deposits held blow floating point values out of the water by a significant margin. The amount of money floating around the world really does generate some stunning sequences of digits, they're almost magically long numbers like the nth digit of Pi. They just don't register as "billions" or "trillions" automatically, you have to count the digits and think a moment about what that number is supposed to be called.:D
I spent two great years working for J. P. Morgan Chase, starting in 1999, followed by a year with the merged JPMC, so I have some knowledge of how this new system will be used and how it fits into the business process of running a bank. I can't discuss details about that, but I just wanted to share my congratulations with the JPMC team for tackling that thorny issue.
You have to understand that investments can't be made until those risk analyses are done, so cutting 7-8 hours off the run time will earn the company millions over the course of a year. We're talking about the kind of investment loans where even a 4-5 hour overnight "float" of capital to help someone seal a bigger deal can be worth a significant amount of interest and profit.
Remember: the big investment banks are dealing with numbers that cause spreadsheets to overflow. You can't even visualize the data with standard desktop tools. You wouldn't believe the totals I saw come out of some reports, and I wish I could forget them. Such numbers are not meant for the grasp of mere humans living on a working wage.
I agree with your comments -- for traditional programming.
But I worked my but off for 15 years of research, development, and experimentation and changed the coding and maintenance game rules.
I just finished off some major updates to the project website for MSS Code Factory. Take the time to do a bit of reading, then check out some of the manufactured code for 1.9 or 2.0 in the Subversion repository.
Yep, it's big.
Over 1,000,000 lines for 2.0 so far, and that's just the manufactured code.
But it runs like a bat out of hell, and thanks to automation, maintenance is trivial. Bug fixes implemented in the rules can be applied to the entire code base in minutes -- it takes 5-10 times as long to check in the changes as it does to write them.
Be warned: my example is way off topic, but a pet statistic I keep track of.
There is no such things as bad statistics, only bad layman statisticians who don't understand what the numbers actually measure.
Take lines of code, for example. Some people hate it because you can bloat the numbers by adding comments, neglecting to consider how useful those comments are for future maintenance, and thereby a useful application of a developer's time. If you use a consistent formatting style for two projects, you can get a fair grasp of their complexity from the line count, though that will gloss over details about how the code actually works.
The most interesting pattern I've notice in line counts over the years is that the use of templates and other code abstraction facilities really hasn't decreased the size of code much at all, though it's improved readability, maintainability, and programmer API usability substantially. So line counts only give you an approximation of complexity with a language like Java, but do nothing to measure the quality of the code.
One other thing I've found is that complex code looks fat and heavy from it's sheer size, but often compiles to very reasonable executable size and runs rings around supposedly "tight" code that makes heavy use of dynamic techniques like introspection. As only one image of an executable is loaded by a reasonably competent OS, a fat binary does not mean a fat application at runtime.
Big code is only scary if it's not following recognizable patterns and is instead a mishmash of different developer's pet syntax, algorithms, style conventions, naming conventions, and even preferred APIs. If you manufacture it predictably, fat source code becomes a joy to maintain, enhance, and use.
But back to the core topic: help desk performance.
The only help desk stat I care about is a low number on customer complaint reports about the quality of information and assistance provided by the tech team. If it's my company and my budget, I'd rather hire more technicians to handle the load and produce happy customers in the end than I would saving money by overworking and burning them out by even thinking about useless numbers like "calls handled per week."
In the end, if you care about your business, the only thing that truly matters are happy customers who want more services or products in the future, and who will gladly tell others about their good experiences in dealing with you.
There is no substitute for a good word-of-mouth reputation and repeat business. No one ever got fired for buying IBM not because they're perfect, but because their people will go the extra mile to make things work.
Mozilla has millions of users on pre-XP SP2 platforms
If there really are people out there running Pre-XP SP2 systems at home or in production, they clearly don't give a damn about performance and usability for the people stuck using such old crap. I would never dream of running anything less than XP-SP3, and even that is old enough that I woudn't expect a vendor to be releasing their latest and greatest software for such an old machine!
It may be a big user base, but I'm betting the majority of such people are using locked-down corporate images that won't let them install the latest builds of Firefox whenever they want to anyhow, so the loss of being at the forefront of the build queue priorities will not affect that community significantly.
Anyone running anything older than XP-SP2 is either a dedicated hobbyist or a criminally negligent system administrator. Even if they mean SP2c, that was released in 2007 -- surely any environment where the sys admin has not rolled out an update in 4 YEARS is criminally negligent and not giving a damn about Firefox performance.
Slashdot Mirror
I agreed to the deployment of timely security and software updates, not to the arbitrary removal and resulting breakage of my systems. If Canonical proceeds with removing the sun-java packages from my machine instead of merely removing them from their distribution repositories, I'll be removing Canonical and going with a distro that understands the importance of not breaking user's machines.
However, I seriously doubt either Oracle or Ubuntu would be so stupid as to break production systems around the world in such a fashion.
I don't blame Oracle for dropping Canonical's distribution. Historically they've always provided their own installers. But they really need to start providing .deb installers as well as .rpm. Using "alien" may work, but it's rather distasteful for production systems to do so. Application and server producers don't want to be in the business of packaging software for installation. And Oracle should really reconsider the benefits of having an automatic distribution engine like Ubuntu's repositories, or start up their own repository server that can be trivially added to the set that Ubuntu queries every time it runs, the same way you can add repositories to Eclipse.
My bigger beef is not the screen size, but the keyboard size. I've yet to try a netbook with a usable keyboard, and if I can't use the keyboard, I may as well not have one at all and go with a tablet device.
However, in reality I'm more inclined to look at 14 inch and 15.6 inch laptops. Most of my computer use involves typing, not consuming. I'll be choosing a unit based on input devices, not size. I need a usable keyboard. I need enough memory to run things. I need one of the old IBM style eraser-nub "mice" instead of a trackpad.
As far as I know, that means I'll be buying a Lenovo. I've never seen anyone else use the erase nub inputs, and I hate, hate, hate, hate HATE trackpads!
And when I'm producing, I want a screen that shows me a reasonable amount of what I'm producing. I can't see that happening with a 10 inch screen or even smaller.
I can see the utility of a tablet, but netbooks have never and will never make sense to me.
There's one big reason I'll pay attention to this one:
Patent trolls file in Texas; serious patent holders file in Delaware.
KDE is not a full GUI. Qt is the GUI toolkit; KDE is the applications built with the toolkit.
The term "desktop" has become synonymous with "window manager". The general public thinks GUI means Windows or Mac already; let's not get too pedantic.
I did download and play around with Kubuntu for 10.04.1 out of curiosity. It's much slower to load than Gnome 2, and seems to be a rather cluttered metaphor for my tastes. LIttle boxes and lists of stuff all over my desktop, which I don't like. Show my desktop icons; don't give me a window of desktop icons. If I wanted them grouped or hidden, I wouldn't put them on the desktop in the first place, now would I?
I liked their take on the start/launcher concept, in particular stitching some of the configuration into tab panes of the launcher. I'd rather see the second tab with the "traditional" menu as my initial tab, though, or be able to configure my own list of "main menu" launcher apps to provide functionality equivalent to my littered Gnome toolbar (Firefox, Thunderbird, Eclipse, Mono, pgAdmin, Pidgin, Rhythmbox, Terminal, Opera, Chrome, Vuze, Filezilla, K3B, DVD Styler, Open Office, and GNU Cash.) I don't like to have to futz with menus to get at the stuff I use the most.
One thing going for KDE -- it's very responsive once it starts up. Gnome feels almost sluggish in comparison on this box. But there's a price to pay for that: an absolutely obscene startup time. WTF are they loading that takes so damned long -- over 20 seconds to boot a WM? WTF? I haven't seen boot times that slow since Win2K, and KDE was not fighting with PostgreSQL, Oracle, and DB/2 for startup memory and processor time like Gnome usually is (I'm impatient and log in long before the box is done it's startups and recoveries.) Gnome 2 startup is like lightning in comparison to KDE.
I've also been reviewing the widget hierarchies and APIs for Gnome and KDE. I hate to say it, but the organization of the Gnome 2 widget hierarchy is NOT what I'd call intuitive. I think the KDE team has done a much better job of things, but as they started with an abstraction kit that was designed to abstract the GUI as a whole, not just the parts needed to implement Gimp, it only stands to reason that KDE ended up being a better designed widget hierarchy.
I'm very uncomfortable with looking any further at Gnome's programming APIs. Qt is far cleaner and richer, and as I'm not interested in KDE specifically, but Qt's portability, I think I've decided which I'll be doing my future native Linux GUI work with. The fact that I get Windows support as well with the one code set is a huge added bonus.
I'd previously evaluated the two toolkits with an eye towards how good they did on the Windows application side, and came to the same conclusion.
So that's 1 to Gnome 2 for usability and clean desktop metaphor, but 2 to KDE/Qt for portable programming sanity.
And I think every UI that's taking the candy-coated single-task with big launch buttons metaphor approach is spending too much time telling themselves how neat their cell phone or tablet device is, and not enough to how people USE A COMPUTER!
IN THIS CORNER: Facebook. Google. Slashdot. Forums. Blogs. MSN. Yahoo. Groups. Lists. Sharing. Publishing. Broadcasting.
And in this corner: privacy.
Seriously, if it's private, WTF are you posting it to a web service for?
I hope for unification and rebirth for the Koreas as we haven't seen since the Germanies.
First, my pet peeve about the new frontiers of user interface design:
Apple apparently has a huge legal team of people with nothing better to do than patent things which should have been published as standards for use by anyone, the same as IBM did with the Common User Access style guides that drive virtually every computer GUI on the planet to date. It's what allows one fanboy to sit down at another fanboy's machine and still get something done because it all works largely the same.
The KDE, Gnome, and Unity teams would be well advised not to ignore decades of research and practical use by the entire computing industry and user community when designing their GUIs. Start with the CUA and go from there. Any divergence from the CUA defaults should require user configuration at either the desktop or application level.
Their ideal on what should be configurable and what should follow the defaults is one area where they'd diverge.
Another area is the practical implementation of the widgets used by the GUIs. CUA is in desperate need of a widget catalogue refresh, along with standards for how the user interacts with that conceptual data. Things like calendar pickers and colour pickers should be part of a new CUA that deals with GUI and Web metaphors; CUA itself was adaptable to early GUIs, but we've got a richer set of presentation standards to add now.
Imagine having a common XML format that defines an abstract GUI, implemented by the desktop designers as a translation of that general XML description to the platform-specific widget toolkit and behaviour standards. I know I could do that with any older UI thanks to the core CUA concepts, but what else should be part of such a new CUA?
IBM did a good job coordinating the original CUA. Maybe someone can convince them to work with the desktop teams to come up with CUA2.
I think we're talking about a philosophical difference of what a "hardware manufacturer" is vs. a "hardware design house." Apple is the latter, and used to be the former. They've farmed out all the production, and are no longer a hardware manufacturing company, but exist only as a hardware design company with a supporting software division.
And, apparently, a huge legal team of people with nothing better to do than patent things which should have been published as standards for use by anyone, the same as IBM did with the Commun User Access styleguides that drive virtually every computer GUI on the planet to date. It's what allows one fanboy to sit down at another fanboy's machine and still get something done because it all works largely the same.
And on that note, the KDE, Gnome, and Unity teams would be well advised not to ignore decades of research and practical use by the entire computing industry when designing their GUIs. Start with the CUA and go from there. Any divergence from the CUA defaults should require user configuration at either the desktop or application level.
Screw that! The kids should be toiling in the fields... :p
In Saskatchewan, we have a Crown Corporation that is responsible for maintaining, updating, and distributing that map data for the province. It's accurate data -- collected using actual transits and GPS systems. Google can not improve on the data quality by reading street signs with AI at all.
I suspect it has a lot more to do with licensing issues for Google wanting to republish the data to the general public, something that I'm sure our crown corp would frown upon as it would cut out their geodata sales market. Google wants a royalty-free data source, not better data quality.
I disagree completely. KDE's configurability is asinine. When KDE apps run under another WM, they use their own KDE defaults like click-to-activate vs. click-to-select, double-click-to-activate. It's annoying as hell to run K3B under Gnome 2, because it does not behave like anything else on my desktop. The only reason I put up with it is that they did the best job of a burning utility I've seen since Nero, and maybe even better than Nero (note I'm talking the old "advanced" Nero tools, not the shiny crapware wrappers they install be default with the new releases.)
With the way KDE is structured on top of Qt, it should be possible for a KDE app running under Gnome to detect that fact and "import" it's settings and defaults from Gnome's environment. The reverse should also be true.
It's almost to the point of frustration that I prefer applications that just ignore any standards at all and do their own thing entirely. At least they're consistently screwed up, following their programmer's diabolical visions of UI hell imposed on the user community. :p
You mean there are still people naive enough to think that "secrecy" will protect their idea?
Guess what -- ideas aren't new in 99.999% of cases. They were originated by science fiction authors and science journal pundits/researchers decades or even centuries ago. We still haven't implemented some of the ideas that creative minds like Newton or Jules Verne came up with, much less dealt with the practical side of the philosophical issues around artificial intelligence vs. "human" rights raised by Dr. Asimov.
This is the main reason I feel nothing but contempt for the entire concept of the patent system. Only an implementation of something should be patentable, and in the case of software, copyright and licensing already provide that protection. The idea of patenting business ideas and processes, user interface standards such as touch screen gestures or Bezos' "1-click" are absolutely asinine, laughable, ludicrous, and criminally negligent of paying attention to reality.
The best defense is a good offense -- get your source code out there under a protective license so that when the inevitable patent lawsuit troll shows up, you can point to umpteen years of public development and say "You should have known about this before filing for your patent. I have prior art. Publicly accessible prior art. You didn't even Google to see if someone already came up with the idea. Now Eff Off with your lawsuit!"
The netbook has always struck me as the stupidest computing idea I'd ever heard of. A "machine" with a screen too small to see, a keyboard too small for my fingers, and too little memory or power for anything more complex than browsing a website.
The pad is a far more effective form factor for serving that ultra-portable not-a-real-machine market.
The netbook was the mutant offspring of low power CPUs and the evil dreams of a wanna-be marketing overlord, not sound engineering or impressive technology.
You can't survive on what some immigrant workers accept for pay, either. High living cost areas in the US and Canada are notorious for painting their wages as "high", and they are, relative to the poorer areas some immigrant labour comes from. I mean economic immigrant to a "high pay" area, not necessarily a foreigner.
But when they get there, they find themselves forced to room with several people to get by, living in conditions no better than they did at home in order to send a significant chunk of their pay home. It's the tech equivalent of the "Alberta Oilsands Lifestyle" -- long hours, brutal living expenses, and relatively high pay for short periods followed by trips home to survive unemployment while looking for the next contract.
However, they already get paid less than a "local" worker with a house, family, tuition expenses, healthcare expenses, etc. at the high local costs can afford to. The "immigrants" come from areas where most of their costs of living are lower.
I've lost count of how many times I've had to abandon a market because the cheap immigrant labour companies swamped the market at cut-throat rates. Then along came actual overseas outsourcing, and even those jobs disappeared entirely.
It may be supply and demand, but the cheap supply markets show no mercy on the countries with the demand. The only saving grace we have is that many of the cheap overseas sweatshops produce crap, or pad their bills through incompetence and low productivity. Unfortunately it takes management getting burned a few times before they realize that you get what you pay for and start hiring local talent at decent rates again. And the growth of the local talent market is a lot slower than the growth of the doomed project farmed out to the lowest bidder.
Automation will make the grunt coder obsolete soon enough, the same as it's done to every other low-skilled labourer for millenia. "I'm a programmer" doesn't mean what it used to -- the tools are a lot easier to work with nowadays, and there is a lot more experience that's been documented and reproducible than there used to be 20 years ago.
No one gets paid to read core dumps any more, and I can't say that I miss that aspect of old style computing at all. Live code editing during a breakpoint rocks for productivity. Similarly, manufactured code is simply more cost effective than manually produced source. It may not be as "elegant", but it works, and works well enough to get the job done. In the end, that's all that matters -- getting the job done.
It's what everyone gets paid for.
Except for bank executives and CEOs who rake in bonuses for gutting companies and losing money. I don't know why we pay those people anything at all. They're incompetent and greedy, and bad for the future of any business.
Which is what I like about it. The GPL lets you get code out there for sharing and development, but blocks businesses from integrating it with their technology unless they pay for a license agreement. For my needs, GPLv3 is a near ideal publication license, supplemented by proprietary commercial licenses.
Any time I've wanted to share code without hope of revenue, I've released it under LGPL instead.
But as my wallet remains empty and the donation counter is $0, I have NO interest in letting any leeches use it anymore freely than is permitted by the GPLv3. Screw the freetards.
Nonsense. You always have the option of paying your ISP for a static IP address and registering a normal DNS entry.
Poor phrasing on my part. The big numbers don't actually leap into the next level beyond trillions. But they still are mind boggling. They're the kind of numbers that get hockey stick business planners thinking "if I can only get a fraction of a percentage point of that..."
Buddy, if you can look at numbers that exceed trillions and claim they honestly seem like reasonable and rational values compared to a sub-six-figure income, you're either a mathematical genius or a liar.
As to the idiot who claimed I was "one of those responsible", is there anyone who actually thinks the peon hordes who work at banks or big corporations are collecting the fat-cat bonuses? We took pay cuts in 2000 after the big push for Y2K was over; we did not get bonuses for helping the bank ride out the paranoia.
And the systems programmers are not responsible for designing risk analysis algorithms, only implementing them.
I'm proud of the work I did for JPMC. We delivered a critical system in record time after the project was put at risk by two years of fiddling around accomplishing nothing. We improved it's reliability and speed over it's predecessor. And we did get bonuses for that one, just not for the Y2K work.
We deployed a new version of a third-party product, and came up with migration scripts to get the data over from the old mainframe version. The vendor had contracted to do the same with Citibank's copy of the software, spent two years of vendor consulting time and a 20 person team, and failed.
Our competent team of four not only did the job the product vendor themselves could not, but we automated the process, and we did so in under a year. It just goes to show what happens when you get four good programmers working on something instead of a horde of average incompetents paid for by a virtually unlimited budget.
So, was I "one of those responsible"? Not in the sense of making decisions, but in providing successful deployments of software supporting the decisions of management. I feel no shame for being good at my job, and rather pissed off that management obviously ignored what was reported by the systems my cohorts worked on.
I'm not speaking to JPMC specifically because I had no contact with the Citibank branch of the merger that had the consumer loans and mortgages, but to banking in general. It's not the risk analysis engines that produced the bad loans, but the individual loan managers who had the option of ignoring the risk reports and apparently did so.
Exactly. It's management and the risk analysis team that decides what gets considered by the algorithms, not the programmers who have to implement the algorithms and systems.
Do you think a properly implemented set of risk analysis points would have allowed loans to sub-prime mortgage holders in the first place? It wasn't risk analysis that did that; it would have been overriding management-imposed company policy. It didn't take a genius to realize that people who couldn't come up with their downpayments in the first place probably wouldn't be able to afford the interest increases after the initial term.
The people who signed those mortgages should have thought about whether they could afford market rate mortgages, not whether they could afford the "low, low introductory price" of a few year's subprime mortgage to start. Sure the banks raped them by bumping interest rates, but only a complete moron would have expected the banks to continue to leverage loans at a loss!
Dirty pool by the banks? Yes. But no more so than when anyone else uses a "loss leader" product to "buy" the high-value add-on sales that follow.
*sigh*
The problems the risk analysis team faced even in the 2000 era was such a tough nut to crack that they had to limit the complexity of the algorithms they used just because there wasn't hardware powerful enough.
All the things you mentioned have only added to that complexity, making the calculations that much worse and that much more expensive.
So instead of making me change my mind, you just made me realize how much more impressive their achievement was than I first thought.
Spreadsheets back then did not have arbitrary precision decimal or integer values -- they used floating point. I have no idea whether newer spreadsheets have shifted to arbitrary precision values or not, but if they haven't the spreadsheets blow up.
Remember: little companies like GE, GM, and Exxon are the kind of customers who have deposits with an investment bank. As a result, numbers like total deposits held blow floating point values out of the water by a significant margin. The amount of money floating around the world really does generate some stunning sequences of digits, they're almost magically long numbers like the nth digit of Pi. They just don't register as "billions" or "trillions" automatically, you have to count the digits and think a moment about what that number is supposed to be called. :D
I spent two great years working for J. P. Morgan Chase, starting in 1999, followed by a year with the merged JPMC, so I have some knowledge of how this new system will be used and how it fits into the business process of running a bank. I can't discuss details about that, but I just wanted to share my congratulations with the JPMC team for tackling that thorny issue.
You have to understand that investments can't be made until those risk analyses are done, so cutting 7-8 hours off the run time will earn the company millions over the course of a year. We're talking about the kind of investment loans where even a 4-5 hour overnight "float" of capital to help someone seal a bigger deal can be worth a significant amount of interest and profit.
Remember: the big investment banks are dealing with numbers that cause spreadsheets to overflow. You can't even visualize the data with standard desktop tools. You wouldn't believe the totals I saw come out of some reports, and I wish I could forget them. Such numbers are not meant for the grasp of mere humans living on a working wage.
I agree with your comments -- for traditional programming.
But I worked my but off for 15 years of research, development, and experimentation and changed the coding and maintenance game rules.
I just finished off some major updates to the project website for MSS Code Factory. Take the time to do a bit of reading, then check out some of the manufactured code for 1.9 or 2.0 in the Subversion repository.
Yep, it's big.
Over 1,000,000 lines for 2.0 so far, and that's just the manufactured code.
But it runs like a bat out of hell, and thanks to automation, maintenance is trivial. Bug fixes implemented in the rules can be applied to the entire code base in minutes -- it takes 5-10 times as long to check in the changes as it does to write them.
"Am I evil? Yes, I AM!"
Be warned: my example is way off topic, but a pet statistic I keep track of.
There is no such things as bad statistics, only bad layman statisticians who don't understand what the numbers actually measure.
Take lines of code, for example. Some people hate it because you can bloat the numbers by adding comments, neglecting to consider how useful those comments are for future maintenance, and thereby a useful application of a developer's time. If you use a consistent formatting style for two projects, you can get a fair grasp of their complexity from the line count, though that will gloss over details about how the code actually works.
The most interesting pattern I've notice in line counts over the years is that the use of templates and other code abstraction facilities really hasn't decreased the size of code much at all, though it's improved readability, maintainability, and programmer API usability substantially. So line counts only give you an approximation of complexity with a language like Java, but do nothing to measure the quality of the code.
One other thing I've found is that complex code looks fat and heavy from it's sheer size, but often compiles to very reasonable executable size and runs rings around supposedly "tight" code that makes heavy use of dynamic techniques like introspection. As only one image of an executable is loaded by a reasonably competent OS, a fat binary does not mean a fat application at runtime.
Big code is only scary if it's not following recognizable patterns and is instead a mishmash of different developer's pet syntax, algorithms, style conventions, naming conventions, and even preferred APIs. If you manufacture it predictably, fat source code becomes a joy to maintain, enhance, and use.
But back to the core topic: help desk performance.
The only help desk stat I care about is a low number on customer complaint reports about the quality of information and assistance provided by the tech team. If it's my company and my budget, I'd rather hire more technicians to handle the load and produce happy customers in the end than I would saving money by overworking and burning them out by even thinking about useless numbers like "calls handled per week."
In the end, if you care about your business, the only thing that truly matters are happy customers who want more services or products in the future, and who will gladly tell others about their good experiences in dealing with you.
There is no substitute for a good word-of-mouth reputation and repeat business. No one ever got fired for buying IBM not because they're perfect, but because their people will go the extra mile to make things work.
If there really are people out there running Pre-XP SP2 systems at home or in production, they clearly don't give a damn about performance and usability for the people stuck using such old crap. I would never dream of running anything less than XP-SP3, and even that is old enough that I woudn't expect a vendor to be releasing their latest and greatest software for such an old machine!
It may be a big user base, but I'm betting the majority of such people are using locked-down corporate images that won't let them install the latest builds of Firefox whenever they want to anyhow, so the loss of being at the forefront of the build queue priorities will not affect that community significantly.
Anyone running anything older than XP-SP2 is either a dedicated hobbyist or a criminally negligent system administrator. Even if they mean SP2c, that was released in 2007 -- surely any environment where the sys admin has not rolled out an update in 4 YEARS is criminally negligent and not giving a damn about Firefox performance.