With all change there will be ills and spills. Often the acquired group will have defectors as the hierarchy above of them just got a lot higher and often there is a feeling that there is a glass ceiling thrown inbetween the two organizations.
However, often what the media/public freak out over (the ills and spills) and rarely do they go back after a (long) adjustment period and praise the benefits of such a merger. You point out one great example: HP/Compaq. Sure there were problems, and many continue today, but no one can say that HP is in a terrible place today, they are vying for first place in PC and notebook sales. Yes, there have been some major bumps in the road and much of what HP is doing today is different from their "heyday"...but where would they be today if they had only focused on printers and calculators?
World of Warcraft--you may have heard of it--has a built-in display of the memory currently being used by any extension,
Citing examples of non-features in various products doesn't make those features right. The fact that a product is popular doesn't mean it is well designed (I'm sure I could cite a few popular apps we could all agree are not well designed).
What is the functional purpose of said feature? How could that feature posssibly make for better game play?
How exactly would one market this feature? If you wouldn't market it, why build it at all?
Computers ship with Reset buttons too. Does this make them "end-user functions"? Are these there because of valid end-user use cases?
Should cars ship with booster cables? Or would it be much better to design them so that they maintain enough charge to be able to start when accessories/lights are left on? Which is the more advanced approach? Which is more "user friendly"? Which approach is the "quick and dirty"? Which is done with the end-user's interests in mind?
The reason we are talking about this at all is that in the past there have been problems with memory leaks. This new version is attempting to address many of those problems. I would rather see effort go towards reducing the application's complexity (i.e. get rid of functions not directly related to the PURPOSE of the application) and fixing those problems directly interfering with the purpose.
Is this not the right engineering approach? Does adding switches, gauges and reset-hammers actually help the end-user browse?
I use them on a regular basis, to see which application is slowing me down, to kill an unresponsive task,
I'm saying these are not end-user functions, they are development and/or system administration functions. The fact that end-users have learned to expose themselves to them doesn't mean that Microsoft (or creators of good OSes/applications) should start building use-cases around these tools to justify their existance.
I'd want to see the list of apps that Firefox is currently running and their memory usage
That "functional requirement" completely fails to meet the problem space of the application in question: being a browser.
It isn't a functional requirement; it is a technical implementation of a solution to a problem that isn't even the root problem. The root problme is "don't have ugly bugs". That can be resolved without exposing end-users to concepts of memory usage, threads, disk space, etc... I argue that none of those concepts belong in front of an end-user with the POSSIBLE exception of disk space (cache limits) in and Advanced Options dialog.
Just because a developer uses a (non-technical) application doesn't make them qualified to state end-user requirements. Often it makes them completely unqualified for such a task.
Again, I ask you to list the functional requirements for this feature.
Comparing Firefox to an OS is ridiculous. Top and Task Manager are not end-user functions, to think such is to misrepresent who "end-users" are...they are not developers (if the product is to become successful with actual end-users).
If you are asking for development tool support within the Mozilla platform, that is a different thing. But to say that an end-user application (the browser) must have monitoring, profiling and/or debugging features out of the box is preposterous. It simply says "we don't know what our product will do"...great marketing.
So that memory/resource leaks can be readily identified, reported, and fixed.
Your list of must have features are not end-user features. Why should the browser be bloated with what are debugging and profiling tools? To say that a product must have such features is to completely and utterly ignore the userbase and live in a coder-centric world.
Write a list of functional requirements that drive the above technical implementation details.
The "save active tabs" feature was added so that people could save their active tabs between invocations of the browser. It was not as a work around to memory leaks.
Are you guys implying that Zune is so crappy that people won't want it even for free?
No, they are implying that they don't want one at the price of a gift. They're saying that many younger-gens will return said gift in exchange for $$ by which they will purchase something they actually prefer to own.
I'm not making a judgment as to whether this is right, just that this is what the above "guys" are implying.
Personally I'm of the mindset that many of the "stuff" that I get as a gift is just that: stuff. I appreciate the thought, but in reality unless the person (or my sig-other) is me the item I receive is likely different from that which I will buy myself. I'm not someone who wants for much and doesn't need anything (and am thankful for that). So I ask that my friends/family spend time with me rather than scouring a mall. I am getting a lot of sighs-of-relief from others in my circle who agree with me.
Smart gifts for the kids, a visit/drink with the adults. I know it comes off sounding like Scrooge, but I honestly believe it is the Right Thing To Do.
MS has already shown that it's willing to use bribery and back-room politics to derail OLPC orders
You raise an interesting point. I know in my decade or so of enterprise IT sales, a company often doesn't mention a deal until after the contract is signed and/or project delivered. I seem to recall that many of the XO deal announcements were "deals in the works" giving their competitors a direct target on where to aim their sales bots.
Is this a failing on the OLPC project? Should they first be working out deals before making any noises about them, if for nothing else that to get a toe hold in the market, a few proof points for further sales?
docx is simply a zip of xml files / everyone can open it / editing is the problem
Editing and reading/interpreting it. Those XML files (and the wretched directory structure they fall into) are non-trivial to read. Try opening a docx containing a picture inside of a table cell.
The demographics of Facebook has changed quite dramatically in the past few months. I have met a large number of people with whom I have lost touch over the years, people I wouldn't drive many hours to go visit with for a 3 hours "reunion", but I'd gladly swap 30 second synopses of the 20 years since our last conversation. Facebook is pretty cool for that. The fact that you didn't find groups that you can associate with either means that you were there a long time ago (1/2 year ago the site was as you describe it), or that your offline network hasn't migrated to Facebook yet; check nntp:// or gopher:// instead:-)
Agreed, but this is where the good PHBs vs the bad come in. The bad will often make poor decisions regardless of the issues involved. The good ones will choose The Right Path based upon more than just the immediate view of revenues/expenses.
In the past, my PHBs were happy to select the path lesser taken because our team was able to explain, in business-oriented terminology, why the choice of software was being made (we didn't even bring up the F/OSS issue other than mentioning that the licensing fees were $0) and how this particular selection gave us the most flexible set of options for future growth (i.e. build upon it ourselves, outsource the same work to others, potentially get the work for free as the community builds the platform, etc...).
There are a thousand avenues of support for OSS, but they all lead to some jackass that says, "RTFM" and the TFM that was never completed, because coders don't give a shit about end user docs.
You are a complete troll, however for the benefit of anyone else reading, my experience with paid support for F/OSS products has been very solid. At worst, it is as good as most commercial product support. At best, I've had some of my support cases turned into direct product enhancements, some with patches available within a day or two of the case being opened (in one case I had a source patch sent to me in under 3 hours).
Just because the software is free doesn't mean that the only avenues to support have to be free. I didn't choose the software for its price (though it was a consideration point), I chose it because of its openness (flexibility within our environment) and the flexibility of the support options including the paid support we ended up going with simply because it was a cost-effective approach. We spent less on licensing & equivalent amount on support as a commercial product and ended up with a solution that met all of our requirements (something no commercial vendor would do), will grow with our requirements, and we know that the product cannot be taken away from us (cannot be bought up by a large commercial vendor, as happens in MANY commercial product scenarios...even if the purchaser is considered a "good guy").
The "free as in beer" thing really annoys me. I've NEVER seen free beer, anywhere!
Man, you are working for the wrong company and/or going to the wrong school.
Oh, and us travelling s/w folks can also write off the odd drink too. Consider a job in support, consulting, sales, product management or the executive team.:-)
The advantages you find in most GUIs:
(a) You don't have to run extra commands to find out if you screwed something up in the config - it'll tell you immediately
...as long as the developer(s) put in the proper validation rules, which they often don't beyond single-field validation. When a configuration is more complicated (e.g. a system-level setting on a multi-host configuration) then often the validation misses the fact that you've just made one of the sub-host configs invalid.
Let's face it, not many programmers like to spend time writing complex validation and error checking routines. And there is a bit of a conflict of interest for commercial apps in that less validation leads to more support calls (and more support $$$).
(b) It's a lot less likely to make a typographic error in the file it saves to, than you are hand editing.
True, though see response to (a) again. And I will make the brash statement that a system that "expects" a valid configuration likely isn't going to spit out very useful error messages when an invalid config is created. One thing you have to admit about many of the hand-edited configuration systems (http servers, ftp server, mail servers) is that they often indicate where in their configuration files they are hitting errors while loading.
(c) If you don't know the name of an option you are searching for, or the text the developer decided to associate with them, you can find it easier by exploring the GUI, since GUIs are typically organized in a theme-based hierarchy.
Yes, sometimes. But then there are countless cases where this is not true. Try configuring MS SQL Server Express to allow non-encrypted TCP client connections. Damn, if I haven't lost 2 hours on a couple of occasions be that damned boolean combo box (why a combo box for true/false??) is NOT in the TCP connections area. Oh, and don't forget that you can enable TCP, but you still have to enable each interface separately as well.
GUIs have the potential to be better organized and if the developer considers the right use cases it can even make administration more efficient, but as the GP stated there are simply things that the command-line/text-file configuration is substantially more efficient at due to a lack of effort/consideration from developers on the GUI front.
This is interesting- because a similar trick could be done with any Linux distro as well.
But here is where we get into the Catch-22: no bundleware vendor wants to build a product for a platform that has a small install base. Linux's install base cannot grow if it cannot compete. It cannot compete if people can buy a PC with MS-Windows for a "nominal price", which they can only because bundleware is made available for MS-Windows.
Comparing the cost of Software to Hardware is fundamentally flawed.
Though I understand where you are coming from, I don't agree that the comparison is a logical flaw. They are pointing out that the hidden value of a bundled component plays a significant role in the overall price of the ONE product a consumer is purchasing.
The absolute price is what should be argued about, but pointing out the current ratio of that absolute component price to the overall product price is reasonable. If the price was $100 for the component but that only played a 0.001% of the overall product price, then it would seem quite silly to be talking about saving $100. But the price of that component is more likely 10% of the price of the product so it becomes quite reasonable to discuss, especially when that component's proportion grows while the price of the ONE product has actually fallen over time. In other words, that one component's price is not staying inline with the pricing of ALL OTHER components making up that ONE product.
If it costs $x for an OEM version of a Windows OS, I can make an informed decision as to whether I want to get it or not.
But this is the genius that is the current state of MS OEM: the end user can't actually see the price of the OEM version because it is subsidized by other vendors (trialware, bundledware).
So if the OEM version is $100, but there is $89 of bundledware (that is only available on Windows), who is going to give up forking out $11 to buy an OS that they "know" and instead try that thing they've been all FUD'ed about...And trust me, if unbundling becomes forced, there will be a FUDfest like no other in history...remember the "not compatible with DOS" astroturfing wars in the 80's? But this time it will be about piracy, patent-violating, known-provider...hey haven't we heard some of this before?
In addition, if you'd care to offer more insight than "is just horrendous" you might consider the simple (and hopefully effective) GIMP UI brainstorming submission process.
- acquire technology/products
- acquire customer base
- remove competitor from landscape
- enter new markets
- enhance/improve/replace parent's base products
...
With all change there will be ills and spills. Often the acquired group will have defectors as the hierarchy above of them just got a lot higher and often there is a feeling that there is a glass ceiling thrown inbetween the two organizations.However, often what the media/public freak out over (the ills and spills) and rarely do they go back after a (long) adjustment period and praise the benefits of such a merger. You point out one great example: HP/Compaq. Sure there were problems, and many continue today, but no one can say that HP is in a terrible place today, they are vying for first place in PC and notebook sales. Yes, there have been some major bumps in the road and much of what HP is doing today is different from their "heyday"...but where would they be today if they had only focused on printers and calculators?
Citing examples of non-features in various products doesn't make those features right. The fact that a product is popular doesn't mean it is well designed (I'm sure I could cite a few popular apps we could all agree are not well designed).
What is the functional purpose of said feature? How could that feature posssibly make for better game play?
How exactly would one market this feature? If you wouldn't market it, why build it at all?
Should cars ship with booster cables? Or would it be much better to design them so that they maintain enough charge to be able to start when accessories/lights are left on? Which is the more advanced approach? Which is more "user friendly"? Which approach is the "quick and dirty"? Which is done with the end-user's interests in mind?
The reason we are talking about this at all is that in the past there have been problems with memory leaks. This new version is attempting to address many of those problems. I would rather see effort go towards reducing the application's complexity (i.e. get rid of functions not directly related to the PURPOSE of the application) and fixing those problems directly interfering with the purpose.
Is this not the right engineering approach? Does adding switches, gauges and reset-hammers actually help the end-user browse?
I'm saying these are not end-user functions, they are development and/or system administration functions. The fact that end-users have learned to expose themselves to them doesn't mean that Microsoft (or creators of good OSes/applications) should start building use-cases around these tools to justify their existance.
That "functional requirement" completely fails to meet the problem space of the application in question: being a browser.It isn't a functional requirement; it is a technical implementation of a solution to a problem that isn't even the root problem. The root problme is "don't have ugly bugs". That can be resolved without exposing end-users to concepts of memory usage, threads, disk space, etc... I argue that none of those concepts belong in front of an end-user with the POSSIBLE exception of disk space (cache limits) in and Advanced Options dialog.
Just because a developer uses a (non-technical) application doesn't make them qualified to state end-user requirements. Often it makes them completely unqualified for such a task.
Comparing Firefox to an OS is ridiculous. Top and Task Manager are not end-user functions, to think such is to misrepresent who "end-users" are...they are not developers (if the product is to become successful with actual end-users).
If you are asking for development tool support within the Mozilla platform, that is a different thing. But to say that an end-user application (the browser) must have monitoring, profiling and/or debugging features out of the box is preposterous. It simply says "we don't know what our product will do"...great marketing.
Your list of must have features are not end-user features. Why should the browser be bloated with what are debugging and profiling tools? To say that a product must have such features is to completely and utterly ignore the userbase and live in a coder-centric world.
Write a list of functional requirements that drive the above technical implementation details.
The "save active tabs" feature was added so that people could save their active tabs between invocations of the browser. It was not as a work around to memory leaks.
Oo-oo-oo! I wanna hear more about that!
No, they are implying that they don't want one at the price of a gift. They're saying that many younger-gens will return said gift in exchange for $$ by which they will purchase something they actually prefer to own.
I'm not making a judgment as to whether this is right, just that this is what the above "guys" are implying.
Personally I'm of the mindset that many of the "stuff" that I get as a gift is just that: stuff. I appreciate the thought, but in reality unless the person (or my sig-other) is me the item I receive is likely different from that which I will buy myself. I'm not someone who wants for much and doesn't need anything (and am thankful for that). So I ask that my friends/family spend time with me rather than scouring a mall. I am getting a lot of sighs-of-relief from others in my circle who agree with me.
Smart gifts for the kids, a visit/drink with the adults. I know it comes off sounding like Scrooge, but I honestly believe it is the Right Thing To Do.
You raise an interesting point. I know in my decade or so of enterprise IT sales, a company often doesn't mention a deal until after the contract is signed and/or project delivered. I seem to recall that many of the XO deal announcements were "deals in the works" giving their competitors a direct target on where to aim their sales bots.
Is this a failing on the OLPC project? Should they first be working out deals before making any noises about them, if for nothing else that to get a toe hold in the market, a few proof points for further sales?
Editing and reading/interpreting it. Those XML files (and the wretched directory structure they fall into) are non-trivial to read. Try opening a docx containing a picture inside of a table cell.
The demographics of Facebook has changed quite dramatically in the past few months. I have met a large number of people with whom I have lost touch over the years, people I wouldn't drive many hours to go visit with for a 3 hours "reunion", but I'd gladly swap 30 second synopses of the 20 years since our last conversation. Facebook is pretty cool for that. The fact that you didn't find groups that you can associate with either means that you were there a long time ago (1/2 year ago the site was as you describe it), or that your offline network hasn't migrated to Facebook yet; check nntp:// or gopher:// instead :-)
Now that's what I call bleeding edge news for nerds .
Tags: old, stale, !news, ~nothing, sigh
In the past, my PHBs were happy to select the path lesser taken because our team was able to explain, in business-oriented terminology, why the choice of software was being made (we didn't even bring up the F/OSS issue other than mentioning that the licensing fees were $0) and how this particular selection gave us the most flexible set of options for future growth (i.e. build upon it ourselves, outsource the same work to others, potentially get the work for free as the community builds the platform, etc...).
You are a complete troll, however for the benefit of anyone else reading, my experience with paid support for F/OSS products has been very solid. At worst, it is as good as most commercial product support. At best, I've had some of my support cases turned into direct product enhancements, some with patches available within a day or two of the case being opened (in one case I had a source patch sent to me in under 3 hours).
Just because the software is free doesn't mean that the only avenues to support have to be free. I didn't choose the software for its price (though it was a consideration point), I chose it because of its openness (flexibility within our environment) and the flexibility of the support options including the paid support we ended up going with simply because it was a cost-effective approach. We spent less on licensing & equivalent amount on support as a commercial product and ended up with a solution that met all of our requirements (something no commercial vendor would do), will grow with our requirements, and we know that the product cannot be taken away from us (cannot be bought up by a large commercial vendor, as happens in MANY commercial product scenarios...even if the purchaser is considered a "good guy").
Man, you are working for the wrong company and/or going to the wrong school.
Oh, and us travelling s/w folks can also write off the odd drink too. Consider a job in support, consulting, sales, product management or the executive team. :-)
Let's face it, not many programmers like to spend time writing complex validation and error checking routines. And there is a bit of a conflict of interest for commercial apps in that less validation leads to more support calls (and more support $$$).
(b) It's a lot less likely to make a typographic error in the file it saves to, than you are hand editing.
True, though see response to (a) again. And I will make the brash statement that a system that "expects" a valid configuration likely isn't going to spit out very useful error messages when an invalid config is created. One thing you have to admit about many of the hand-edited configuration systems (http servers, ftp server, mail servers) is that they often indicate where in their configuration files they are hitting errors while loading.
(c) If you don't know the name of an option you are searching for, or the text the developer decided to associate with them, you can find it easier by exploring the GUI, since GUIs are typically organized in a theme-based hierarchy.
Yes, sometimes. But then there are countless cases where this is not true. Try configuring MS SQL Server Express to allow non-encrypted TCP client connections. Damn, if I haven't lost 2 hours on a couple of occasions be that damned boolean combo box (why a combo box for true/false??) is NOT in the TCP connections area. Oh, and don't forget that you can enable TCP, but you still have to enable each interface separately as well.
GUIs have the potential to be better organized and if the developer considers the right use cases it can even make administration more efficient, but as the GP stated there are simply things that the command-line/text-file configuration is substantially more efficient at due to a lack of effort/consideration from developers on the GUI front.
I don't understand your point. They don't mention Exchange once in this article.
When it comes to Canada, 50 Cent is already screwed
But here is where we get into the Catch-22: no bundleware vendor wants to build a product for a platform that has a small install base. Linux's install base cannot grow if it cannot compete. It cannot compete if people can buy a PC with MS-Windows for a "nominal price", which they can only because bundleware is made available for MS-Windows.
Though I understand where you are coming from, I don't agree that the comparison is a logical flaw. They are pointing out that the hidden value of a bundled component plays a significant role in the overall price of the ONE product a consumer is purchasing.
The absolute price is what should be argued about, but pointing out the current ratio of that absolute component price to the overall product price is reasonable. If the price was $100 for the component but that only played a 0.001% of the overall product price, then it would seem quite silly to be talking about saving $100. But the price of that component is more likely 10% of the price of the product so it becomes quite reasonable to discuss, especially when that component's proportion grows while the price of the ONE product has actually fallen over time. In other words, that one component's price is not staying inline with the pricing of ALL OTHER components making up that ONE product.
But this is the genius that is the current state of MS OEM: the end user can't actually see the price of the OEM version because it is subsidized by other vendors (trialware, bundledware).
So if the OEM version is $100, but there is $89 of bundledware (that is only available on Windows), who is going to give up forking out $11 to buy an OS that they "know" and instead try that thing they've been all FUD'ed about...And trust me, if unbundling becomes forced, there will be a FUDfest like no other in history...remember the "not compatible with DOS" astroturfing wars in the 80's? But this time it will be about piracy, patent-violating, known-provider...hey haven't we heard some of this before?
You must be new around here...or just plain new.
Wouldn't that make running the system on Windows illegal? I mean, surely the potential of suicide bombing would violate the rules too.
In addition, if you'd care to offer more insight than "is just horrendous" you might consider the simple (and hopefully effective) GIMP UI brainstorming submission process.
Here's a pretty good list of alternate Window managers. You'll have to upgrade your XP though.
</karma action="whoring">