If everyone is using Office 2010, then you don't have to worry about some weird.doc format screwing stuff up.
Have no experience with Office 2010, but document formatting never was its forte. WinWord encourages bad formatting practices by making proper formatting a chore. Ribbon doesn't help. But both WinWord and Writer, as reliable formatting goes, ages behind WYSIWYM editors like LyX (though the latter lacks embedded/embeddable graphics editor).
Not to mention how much better Excel is than any Open Source spreadsheet program.
In my experience, OO is better than Excel in many aspects. Both have bunch of problems, but at least for OO workarounds are plenty, while in Excel it is generally "it is a feature, not bug."
They'd rather have things work, instead of pander to some zealots on the internet.
That is precisely my sentiment against M$O. In OO, albeit it is oftentimes is slower than M$O, document editing is much smoother. Add here the lack of ribbon - and you have the winner.
In past when I was working for start-ups, we often needed the 10-12-more hours coding runs. My highest personal record is somewhere at 20 hours of effective coding without long breaks. But after that I needed at least one day off.
If work and work environment are all set properly, even the 8 hours a day is too much. In heavy coding runs, e.g. I'm burning my daily brains' capacity in about 5-6 hours.
If work is a dumb typing then, yeah, 8 hours is piece of cake. But more than 8 hours... I have never seen a company with sustainable working schedule of more than 8 hours. Less than 8 - yes. More than 8 - not once.
Are there more sweeping yet practical solutions out there for avoiding the weakness of a singular empowered superuser?
Give the responsibility back to the users.
By removing the responsibility from users, one keeps them oblivious to the infrastructure problems. That perpetuates arrogance and the "not my responsibility" mentality.
By moving the responsibility to admins, to the people who do not use (for their primary purpose) the services and infrastructure they are responsible for, make them oblivious to the actual user needs. And self servingly often make the infrastructure more complex than it really needs to be - feeding off the "not my responsibility" mentality.
I'm strong believer that people should know their tools. It is either one wastes time in the extra bureaucracy which IT brings with itself - or spends time learning what actually is going on and how to manage it. Learning > bureaucracy.
Neither takes more effort to maintain for Intel or the project that uses them. The binary blob method simply allows hiding methods.
Nice idea. Yes, one can see the whole situation as a ploy on part of Intel to expose the problems of the actual graphics stack development on the Linux. What I personally think is good.
And let's not forget that binary drivers generally require particular versions of software they depend upon. That is to minimize maintenance overhead to support multitude of possible software configurations. Even if the blob becomes open sources, it doesn't solve the immediate problem that supporting several X.org/Mesa/etc versions (and all their possible combinations) at once is going to be a major waste of time. The problem of a blob driver also has another negative impact: upstream projects can't innovate at sufficient pace since they try to maintain backward compatibility with the blob drivers (surely nobody needs an X.org or Mesa which are not compatible with available drivers). IOW IMO this is a still bad idea.
I personally see that only solution could be synchronization of release schedule between all the involved projects: kernel, X.org, Mesa and libdrm. But that again will not work as kernel folks proved to be incapable of synchronizing with anybody nor maintaining somewhat stable release schedule. And as kernel API isn't stable, spinning off the relevant parts into a standalone project might too prove to be a dead end. Solution is obvious, yet unachievable: too many involved parties without any central coordination.
"The challenge" being issued here is to start contributing working code to the relevant projects as soon as possible and well in advance of D-day, so that drivers for the hardware are already available and inccluded in mainstream, current distros on launch day.
This is a pretty normal business practices in a highly competitive market like GPUs: final list of features is often not finalized until the very late date. H/W might be already in production, but drivers are still tweaked and tuned till the last moment possible. Often list of advertised features isn't even finalized.
Pushing drivers as soon as possible into upstream projects also makes very little sense since nobody can test them and thus the drivers are of unknown quality.
For a nice contrast, look at how IA64 and USB3 were supported in the Linux kernel before commercial products became available.
Comparison of GPUs with technologies which change once in about 5-10 years totally makes sense.
Yes, they did and tested quite a lot. Helped only in a sense that latency spikes now happen rarely but more prolonged and the process eats 4GB RAM all the time.
P.S. I'm responsible for the C module, Java one is supposed to replace. Java's not precisely my field of expertise. N.B. The C module is pretty crappy and I would be happy to drop in favor of Java one, but testers give no green light yet. It's not a flamewar against Java: the Android's Dalvik problems (which I have also seen too) somehow resonate with the problems I have seen recently with the vanilla JVM. Both are about latencies vs. GC.
Though when I see that heap growth of "java" process (belonging to a network server) is literally proportional to the amount of incoming traffic, and as soon as the heap limit is hit I clearly see how GC affects latencies, I know that it is either still not implemented or implemented poorly. Not much of a consolation.
We did recently long term latency-centric tests and we clearly have seen that Sun's Java 6 doesn't do it. The stateless network server literally halts for 500ms/more every time GC runs - while the server is supposed to run with latencies >100ms. Memory allocation is also OK as (1) there is no global state/data/etc and (2) the work of the server is to essentially dump to disk some of the incoming traffic and send a response back.
On embedded platforms there are no cheap resources.
I once was asked, as a software developer, by my friend how it could be that iPhone with its measly CPU/GPU has smoother UI animation than the monster of a phone which is the HTC Desire HD. And I have reminded him that long long time ago, in ages when 640K of RAM was a lot and high-end CPUs were 25MHz, animation in games was too smooth. It does depend more on the software developer's skills than on hardware. Apple takes time to polish it to perfection - Google doesn't.
I've never really liked garbage collection [...]
I have accepted the GC after I have realized that Perl has it and thus it can be implemented effectively. And yes, not once I have seen the rare cases of how GC affects Perl's performance, but even that was possible to fix by properly situated 'undef'. Yet, in the remaining 99.9% of the cases the single-threaded Perl doesn't even give away the fact that it is GCed.
and cite more powerful hardware and an avoidance of temporary objects as a solution to the collection pauses
LOL.
Java is pretty much only GC language I'm aware of where temp objects are passed to GC. Perl (and I'm sure myriad of other GC languages) at compile time takes note what objects are not used outside of the context and destroys them immediately. IIRC Java is the only language where they blankly send all stuff to GC, regardless. Obviously that that in long term hurts latencies: GC has to recycle them eventually and if there is no spare CPU/core, then it has to take the time from other threads.
Meanwhile, Intel is requiring at least FIVE different base operating system components to be changed for their drivers to be updated?
I have understood the case made by the RTFA differently. (Or was the RTFA simply dumping the raw facts? Never mind.)
Supplying a binary driver works at the moment, and that what nVidia and AMD/ATI do. But that's bad because not OSS-friendly.
Yet, if a company (Intel in the case) decides to go full open source, properly and timely submits all the changes to the corresponding OSS projects as our God Linus intended, delivery of technology to the end user becomes a nightmare because of (1) all the inter-dependencies which exist between the projects AND (2) lack of central coordination.
IMO the story here is not per se that Intel f****ed it up - but about the fact that the particular area of OSS ecosystem is f****ed up (and easily alienates both vendors and users).
Generally, in short term testing doesn't save money. Though in long term, there are some benefits.
0. Software testing doesn't save money to the software developer itself - it generally saves money to the customer. Having software being tested, allows customers to cut the time and the effort in the critical phases of the larger project deployments. Some companies I know sell testing separately. You can buy their product and test the particular configuration yourself - or the ISV can do it for you. (Feature bloat is the main reason why the bogosity exists.)
1. Customer relationships. There is nothing worse than a minor design defect requiring coming up before (and causes delays of) deployment.
2. Long term software development generally builds on previous enhancements. If the enhancements were not tested properly beforehand, later development might come to the unpleasant surprise, when it would come to the light that the foundation for the new work wasn't as stable as people did tend to believe (or the foundation wasn't really satisfying the requirements it was presumed to). And it is a well known fact that software developers are poor at spotting problems in their own code. Testers having a different angle on the software complement well the development process.
Also, I would generally recommend to retrain software developers to be testers. Though not obvious to many, any effective testing requires knowledge of the source code. I had seen lots of wasted effort due to the fact that testers were not aware of the implementation peculiarities.
For smaller companies I would advise a simpler scheme: rotate primary focus of developers between coding and testing (and support). Idea is that developer should have enough time to learn particularities of each of the development phases and bring the new experience back into the other development phases.
and I can only assume it's because we don't have a formal test suite.
For internal applications, make sure that you have requirement specification. Testing is impossible if the expectations are not spelled out formally.
If you do not have a requirement specification, then try to create one before advocating for testing. It might turn out that the software has too many interested parties and finalizing requirements would prove impossible. Then testing might cause more harm than good, by breaking the unwritten unspoken balance. By becoming a tester you should be ready to make an enemy out of better half of the company.
One important lesson to be learned is this: many users do not update their software if they don’t have to. Skype had a newer version in place, without the triggering bug, but most users had the buggy one.
Yeah. Right. Because all recent Skype updates (staring with version 3(?)) were known to contain mostly only one of this: more ads or more UI bloat. And occasional breakages.
So why they expect that users would be updating it regularly?
except there was never a time when software or music piracy was actually legal, unless you reach back to before copyright existed.
And that wasn't that long ago. Traditional business model of artists was to profit from live performances. Middle men appeared much later than entertainment itself.
however, i do agree that it is disturbing that in so many aspects of everyday life a person will find it easier to break the law than to abide by it.
And that's the point. If all people are doing it, then why not.
The criminalization has quite ominous side-effect. It is a well know fact that if a person crossed the line once, they would have much less reluctance crossing it again. Criminalizing many people over minor offenses also inadvertently leads to growth of number of major offenses. Thus laws are generally kept to necessary minimum, so that state doesn't need to turn whole country into a one huge jail.
To me, it doesn't matter where in the implementation the bug is, since it has to be rewritten anyway for readability reasons.
It also BTW would trigger another alarm in the eyes of seasoned code reviewers: in the "isdigit() == true" branch it looses the read character, printing '0' instead.
The goal of the contest is to write a chunk of code that does something, well, underhanded that is difficult to detect even upon close examination of the code.
First two examples on the front page haven't passed even through my shallow code review.
The third sample failed at readability (ambiguous operator precedence) and I would have immediately subjected it to re-factoring.
It is not that difficult to detect the problems.
My first, the most generic rule of code review: code works much like the way it looks. And I know for a fact that OpenBSD folks use that rule too.
P.S. The 3 samples I looked at are the winners from the year 2008.
Slashdot Mirror
Steven Vaughan-Nichols is calling it "no longer as important as it once was". See http://www.zdnet.com/blog/open-source/the-new-debian-linux-irrelevant/8218
Taken out of context.
Debian as a user visible distro: less relevant.
Debian as a foundation for other distros: more relevant.
But yeah, article written in quite a trolling fashion. Probably Steven had too much of Ubuntu and now can't think anything but "ooh! shiny!!".
If everyone is using Office 2010, then you don't have to worry about some weird .doc format screwing stuff up.
Have no experience with Office 2010, but document formatting never was its forte. WinWord encourages bad formatting practices by making proper formatting a chore. Ribbon doesn't help. But both WinWord and Writer, as reliable formatting goes, ages behind WYSIWYM editors like LyX (though the latter lacks embedded/embeddable graphics editor).
Not to mention how much better Excel is than any Open Source spreadsheet program.
In my experience, OO is better than Excel in many aspects. Both have bunch of problems, but at least for OO workarounds are plenty, while in Excel it is generally "it is a feature, not bug."
They'd rather have things work, instead of pander to some zealots on the internet.
That is precisely my sentiment against M$O. In OO, albeit it is oftentimes is slower than M$O, document editing is much smoother. Add here the lack of ribbon - and you have the winner.
That was a good start, but we think now that all the people should be allowed to vote.
What at some point of time stroke me as idiotic: why somebody who e.g. pays no taxes should have a say in how my tax money are managed?
... for paying the "Microsoft Tax" in addition to their own taxes, to prop up the US economy at their expense.
I wouldn't be that optimistic.
I can't imagine why they'd do it; but the US sure could use the money to pay off some of it's debt.
Lobbies and money funneling come to my mind first. The business as usual for MS and the likes. And the gov't officials.
[...] Teaching Linux [...]
Best thing is to not "teach Linux," but to "teach on Linux."
Next on news: memory bits are too easy on computer's CPUs.
In past when I was working for start-ups, we often needed the 10-12-more hours coding runs. My highest personal record is somewhere at 20 hours of effective coding without long breaks. But after that I needed at least one day off.
If work and work environment are all set properly, even the 8 hours a day is too much. In heavy coding runs, e.g. I'm burning my daily brains' capacity in about 5-6 hours.
If work is a dumb typing then, yeah, 8 hours is piece of cake. But more than 8 hours ... I have never seen a company with sustainable working schedule of more than 8 hours. Less than 8 - yes. More than 8 - not once.
Are there more sweeping yet practical solutions out there for avoiding the weakness of a singular empowered superuser?
Give the responsibility back to the users.
By removing the responsibility from users, one keeps them oblivious to the infrastructure problems. That perpetuates arrogance and the "not my responsibility" mentality.
By moving the responsibility to admins, to the people who do not use (for their primary purpose) the services and infrastructure they are responsible for, make them oblivious to the actual user needs. And self servingly often make the infrastructure more complex than it really needs to be - feeding off the "not my responsibility" mentality.
I'm strong believer that people should know their tools. It is either one wastes time in the extra bureaucracy which IT brings with itself - or spends time learning what actually is going on and how to manage it. Learning > bureaucracy.
My 0,02€.
Neither takes more effort to maintain for Intel or the project that uses them. The binary blob method simply allows hiding methods.
Nice idea. Yes, one can see the whole situation as a ploy on part of Intel to expose the problems of the actual graphics stack development on the Linux. What I personally think is good.
And let's not forget that binary drivers generally require particular versions of software they depend upon. That is to minimize maintenance overhead to support multitude of possible software configurations. Even if the blob becomes open sources, it doesn't solve the immediate problem that supporting several X.org/Mesa/etc versions (and all their possible combinations) at once is going to be a major waste of time. The problem of a blob driver also has another negative impact: upstream projects can't innovate at sufficient pace since they try to maintain backward compatibility with the blob drivers (surely nobody needs an X.org or Mesa which are not compatible with available drivers). IOW IMO this is a still bad idea.
I personally see that only solution could be synchronization of release schedule between all the involved projects: kernel, X.org, Mesa and libdrm. But that again will not work as kernel folks proved to be incapable of synchronizing with anybody nor maintaining somewhat stable release schedule. And as kernel API isn't stable, spinning off the relevant parts into a standalone project might too prove to be a dead end. Solution is obvious, yet unachievable: too many involved parties without any central coordination.
"The challenge" being issued here is to start contributing working code to the relevant projects as soon as possible and well in advance of D-day, so that drivers for the hardware are already available and inccluded in mainstream, current distros on launch day.
This is a pretty normal business practices in a highly competitive market like GPUs: final list of features is often not finalized until the very late date. H/W might be already in production, but drivers are still tweaked and tuned till the last moment possible. Often list of advertised features isn't even finalized.
Pushing drivers as soon as possible into upstream projects also makes very little sense since nobody can test them and thus the drivers are of unknown quality.
For a nice contrast, look at how IA64 and USB3 were supported in the Linux kernel before commercial products became available.
Comparison of GPUs with technologies which change once in about 5-10 years totally makes sense.
Yes, they did and tested quite a lot. Helped only in a sense that latency spikes now happen rarely but more prolonged and the process eats 4GB RAM all the time.
P.S. I'm responsible for the C module, Java one is supposed to replace. Java's not precisely my field of expertise. N.B. The C module is pretty crappy and I would be happy to drop in favor of Java one, but testers give no green light yet. It's not a flamewar against Java: the Android's Dalvik problems (which I have also seen too) somehow resonate with the problems I have seen recently with the vanilla JVM. Both are about latencies vs. GC.
I raised the point because I had very similar problem recently in Java.
Thus your advice should be also applicable to Android too ;)
Java is pretty much only GC language I'm aware of where temp objects are passed to GC.
You can reduce your ignorance on this topic by putting "generational garbage collection" into your favorite search engine.
Done.
Though when I see that heap growth of "java" process (belonging to a network server) is literally proportional to the amount of incoming traffic, and as soon as the heap limit is hit I clearly see how GC affects latencies, I know that it is either still not implemented or implemented poorly. Not much of a consolation.
Any pointers to the Java specific information?
We did recently long term latency-centric tests and we clearly have seen that Sun's Java 6 doesn't do it. The stateless network server literally halts for 500ms/more every time GC runs - while the server is supposed to run with latencies >100ms. Memory allocation is also OK as (1) there is no global state/data/etc and (2) the work of the server is to essentially dump to disk some of the incoming traffic and send a response back.
[...] but memory is dirt cheap these days.
On embedded platforms there are no cheap resources.
I once was asked, as a software developer, by my friend how it could be that iPhone with its measly CPU/GPU has smoother UI animation than the monster of a phone which is the HTC Desire HD. And I have reminded him that long long time ago, in ages when 640K of RAM was a lot and high-end CPUs were 25MHz, animation in games was too smooth. It does depend more on the software developer's skills than on hardware. Apple takes time to polish it to perfection - Google doesn't.
I've never really liked garbage collection [...]
I have accepted the GC after I have realized that Perl has it and thus it can be implemented effectively. And yes, not once I have seen the rare cases of how GC affects Perl's performance, but even that was possible to fix by properly situated 'undef'. Yet, in the remaining 99.9% of the cases the single-threaded Perl doesn't even give away the fact that it is GCed.
and cite more powerful hardware and an avoidance of temporary objects as a solution to the collection pauses
LOL.
Java is pretty much only GC language I'm aware of where temp objects are passed to GC. Perl (and I'm sure myriad of other GC languages) at compile time takes note what objects are not used outside of the context and destroys them immediately. IIRC Java is the only language where they blankly send all stuff to GC, regardless. Obviously that that in long term hurts latencies: GC has to recycle them eventually and if there is no spare CPU/core, then it has to take the time from other threads.
Meanwhile, Intel is requiring at least FIVE different base operating system components to be changed for their drivers to be updated?
I have understood the case made by the RTFA differently. (Or was the RTFA simply dumping the raw facts? Never mind.)
Supplying a binary driver works at the moment, and that what nVidia and AMD/ATI do. But that's bad because not OSS-friendly.
Yet, if a company (Intel in the case) decides to go full open source, properly and timely submits all the changes to the corresponding OSS projects as our God Linus intended, delivery of technology to the end user becomes a nightmare because of (1) all the inter-dependencies which exist between the projects AND (2) lack of central coordination.
IMO the story here is not per se that Intel f****ed it up - but about the fact that the particular area of OSS ecosystem is f****ed up (and easily alienates both vendors and users).
How Do You Prove Software Testing Saves Money?
Generally, in short term testing doesn't save money. Though in long term, there are some benefits.
0. Software testing doesn't save money to the software developer itself - it generally saves money to the customer. Having software being tested, allows customers to cut the time and the effort in the critical phases of the larger project deployments. Some companies I know sell testing separately. You can buy their product and test the particular configuration yourself - or the ISV can do it for you. (Feature bloat is the main reason why the bogosity exists.)
1. Customer relationships. There is nothing worse than a minor design defect requiring coming up before (and causes delays of) deployment.
2. Long term software development generally builds on previous enhancements. If the enhancements were not tested properly beforehand, later development might come to the unpleasant surprise, when it would come to the light that the foundation for the new work wasn't as stable as people did tend to believe (or the foundation wasn't really satisfying the requirements it was presumed to). And it is a well known fact that software developers are poor at spotting problems in their own code. Testers having a different angle on the software complement well the development process.
Also, I would generally recommend to retrain software developers to be testers. Though not obvious to many, any effective testing requires knowledge of the source code. I had seen lots of wasted effort due to the fact that testers were not aware of the implementation peculiarities.
For smaller companies I would advise a simpler scheme: rotate primary focus of developers between coding and testing (and support). Idea is that developer should have enough time to learn particularities of each of the development phases and bring the new experience back into the other development phases.
and I can only assume it's because we don't have a formal test suite.
For internal applications, make sure that you have requirement specification. Testing is impossible if the expectations are not spelled out formally.
If you do not have a requirement specification, then try to create one before advocating for testing. It might turn out that the software has too many interested parties and finalizing requirements would prove impossible. Then testing might cause more harm than good, by breaking the unwritten unspoken balance. By becoming a tester you should be ready to make an enemy out of better half of the company.
One important lesson to be learned is this: many users do not update their software if they don’t have to. Skype had a newer version in place, without the triggering bug, but most users had the buggy one.
Yeah. Right. Because all recent Skype updates (staring with version 3(?)) were known to contain mostly only one of this: more ads or more UI bloat. And occasional breakages.
So why they expect that users would be updating it regularly?
except there was never a time when software or music piracy was actually legal, unless you reach back to before copyright existed.
And that wasn't that long ago. Traditional business model of artists was to profit from live performances. Middle men appeared much later than entertainment itself.
however, i do agree that it is disturbing that in so many aspects of everyday life a person will find it easier to break the law than to abide by it.
And that's the point. If all people are doing it, then why not.
The criminalization has quite ominous side-effect. It is a well know fact that if a person crossed the line once, they would have much less reluctance crossing it again. Criminalizing many people over minor offenses also inadvertently leads to growth of number of major offenses. Thus laws are generally kept to necessary minimum, so that state doesn't need to turn whole country into a one huge jail.
This. I don't begrudge anyone pirating anymore.
This effect has a name - Criminalization of Society.
To me, it doesn't matter where in the implementation the bug is, since it has to be rewritten anyway for readability reasons.
It also BTW would trigger another alarm in the eyes of seasoned code reviewers: in the "isdigit() == true" branch it looses the read character, printing '0' instead.
Check out the Underhanded C Contest
I have checked it and yes all the code there has trivial coding bugs which are very easy to spot to professional coders.
You obviously have not seen things like this http://underhanded.xcott.com/
I have just seen them, and they all fail simple shallow code review or code readability test.
The goal of the contest is to write a chunk of code that does something, well, underhanded that is difficult to detect even upon close examination of the code.
First two examples on the front page haven't passed even through my shallow code review.
The third sample failed at readability (ambiguous operator precedence) and I would have immediately subjected it to re-factoring.
It is not that difficult to detect the problems.
My first, the most generic rule of code review: code works much like the way it looks. And I know for a fact that OpenBSD folks use that rule too.
P.S. The 3 samples I looked at are the winners from the year 2008.