Anyone that claims either vi or emacs is a useful editor hasn't used a modern Windows IDE. Just the amount of context aware help that is available about the platform is amazing.
That just shows that you haven't used a version of Emacs since the GNU - Lucid split. Lets see - I have language aware parsing (including context-aware tooltips) and completion (ala intellisense), automatic indexes into each file, class browser, helper wizards, version control awareness and integration, fully programmable interaction with the editing buffer to cope with work-specific stuff, electric expansion (and fully modifiable expansion tables), dynamic completion and the ability to work seamlessly with remote files.
And that doesn't touch on all the other features that I use day-to-day, like highlighting, source code comparison and patching, recursive directory comparison and debugger integration.
Anyway who claims that Emacs isn't a useful editor hasn't learned how to use it.
It's true that Firefox has typically been playing catch up throughout its lifespan. However, in the last 18 months, it has been seriously lagging behind other browsers (IE aside). Process separation, general speed, stability, memory fragmentation, etc.
This meme about Firefox memory fragmentation just won't die! Firefox 3.0.x you could still claim that Firefox was sucking down more and more memory as pages got visited. With 3.5.x, you can kiss that problem pretty much goodbye - Firefox returns more memory back to the system than any competing browser.
And Firefox isn't the largest memory consumer here either - that prize probably goes to Chrome, simply because one-tab-per-process is inevitably a heavier memory requirement.
Firefox stability is still a minor issue. However, it's stable enough that I get about 1 crash every three days, which is well within my tolerance level (14 extensions, 11 plugins). Tools like abrt provide a decent mechanism for informing the necessary bug trackers.
Speed-wise, Firefox devs know they are in a race with Chrome. 3.6.x looks like it will be faster than 3.5.x by a fair margin. Project Electrolysis stands to improve matters further. I'm all for competition - keeps everyone working on the issue.
Give me a plugin sandbox so that Flash trapping doesn't take out the page and I'll be content.
... you have will have to break through that wall at some point.
Maths is not a memory-based subject - you have to build the manipulation skills that Math requires. The only way to acquire that ability is to keep doing the maths problems until they start to click. You need to build a set of tricks to change problems from ones you don't recognize into ones you do. Be prepared to grind it out. Find a set of problems that increase in difficulty and hack at them until they make complete sense. Don't rush and don't attempt to do them all at once.
You also need to find some Math tasks that are fun or interest you. If you are learning about complex numbers, go look up some fractals and look at the formulas. Picks some starting values and play with the numbers. Get a sense of how the numbers move around and a firm underpinning about what is going on. If you are doing calculus, play with the equations of motion and work out what a canon ball does under constant acceleration. Try modelling a N-body system of planets moving around in 2D on a computer. All the time, you will be building an internal model about the way that all this hangs together.
Maths can be extremely rewarding once you grok it. But if you don't get past the struggle phase, it will never give you any pleasure and you'll miss out.
I didn't mention it, but I sign and date a lot of my comments, especially when I'm helping someone else. That way, when they go in later to see what I changed.
# -jws 01/02/2009 - changes to trace xyz bug.
[code]
# -jws 01/02/2009 - end changes
That looks awfully like something I would expect your version control repository to tell you. For ages we used to labouriously indicate the problem being fixed and included the "blessed" initials of the developer doing the work. Then we got a real VC and this practice stopped. Life got better.
(...) I'm guessing that at best, 128 bit IEEE 754r performs about half the speed of 64bit IEEE 754, purely because of the data width.
According to Douglas Crockford "...it's literally hundreds of times slower than the current format.".
I don't doubt that the software implementations are "hundreds of times slower". I've had my hands deep into several implementations of decimal arithmetic and none of them are even remotely close to IEEE 754 in hardware. IEEE 754r is better than some of the predecessors because a software implementation can map the internal representation to integer maths. However, IEEE 754r does exist in hardware and I was guessing that the hardware IEEE 754r is still half the speed of hardware IEEE 754.
One other thing that IEEE 754 has going for it is the emerging GPU-as-co-processor field. The latest GPUs can do full 64bit IEEE 754 in the stream processors, making massive parallel floating point processing incredibly speedy.
Why do processors need decimal number support? 10 is just an arbitrary number humans picked because they happen to have 10 fingers. There's no connection between that and computers.
Clearly you've never dealt with an irate customer who has spent $$$ on your software product, has created a table using "REAL" (4-byte floating point) types and then wonders why the sums are screwing up. IEEE754 can't accurately represent most fractions in the way that humans do and this means that computers using IEEE 754 floating point give different answers to a human sitting down with pen and pencil and doing the same sums. As humans are often the consumer of the information that the computer spits out, making computers produce the correct results is important.
There are plenty of infinite precision computing libraries out there for software developers to use. However, they are all a lot slower than the 4, 8 or 10 byte floating point IEEE 754 calculations which are supported directly by the hardware. Implementing the IEEE 754r calculations directly on the CPU means that you can get close to the same performance levels. I'm guessing that at best, 128 bit IEEE 754r performs about half the speed of 64bit IEEE 754, purely because of the data width.
The debate over floating point numbers in ECMAScript is interesting. IEEE 754 has plenty of pitfalls for the unwary but it has one big advantage - it is directly supported by the Intel-compatible hardware that 99+% of desktop users are running. Switching to the IEEE 754r in ECMA Script would have meant a speed hit to the language on the Intel platform until Intel supports it in hardware. This is an area where IBM already has a hardware implementation of IEEE 754r - its available on the POWER6 platform and I believe that the z-Series also has a hardware implementation. I suspect that IBM will continue to push for IEEE 754r in ECMAScript, I wonder whether Intel is considering adding IEEE 754r support to its processors in the future.
Disclaimer: I have no contact with the IBM ECMAScript folks.
Perl is one of those languages that most people meet in passing because someone else has hacked up a script to get something out of some file. Which is sad, because understanding what makes Perl different from other languages and why it is often a better choice for wrangling data isn't going to be obvious in one lousy foreach search-and-replace hack. And most people exposed to perl scripts in this manner fall over on the difference between scalar and list context and never discover why perl expressions like $lookup{$term}++ will save them years of work, while making their analysis scripts go faster.
I write Perl modules day in, day out to cope with processing DB2 internals in an attempt to model and improve them. Object-oriented Perl makes this easy, fast and effective. Closures (which I'm sure aren't understood by 90% of the Slashdot community) back this up being able to create anonymous subroutines with data attached which can be processed later. Perl is also effective for parallel task analysis - I have modules for jobserving many tasks across multiple machines and Perl threads make it easy to fire a task off while something else is done.
Perl is an essential part of data analysis for any serious volume of unstructured data. However, I'm not unhappy that it is little understood. Perl makes in the impossible merely hard. If everyone knew how to leverage Perl, I wouldn't have so much fun.
Man pages are not tutorials. They are not help pages. They are reference material, designed to quickly and briefly inform the experienced user about the usage of a command and any related files.
Info pages are the next step up. They are often more detailed (witness the Emacs pages) but they are generally written for a technical audience and quite frankly, the average user isn't going to find them anyway or be able to do anything with them if they can find them,
Man pages and Info pages will, if you are very very lucky, be written by the authors of the software who speak the same language you do and are used to writing technical information. They stand some chance of being updated as the software is updated.
Next up on the list of information resources is wikis, hosted at the site where the development is done. These will generally provide more accessible information for new users, will be community driven and hopefully will reflect the state of the code in the last two years. Keeping wikis up to date is a huge task for large projects.
Beyond that, proper documentation requires constant community involvement. Most projects don't have someone looking after the docs - the software is the focus. Even teams like GNOME and KDE struggle to keep their docs even vaguely up to date - witness the dearth of information on the latest release of gdm (2.28.1) for example. And these teams do have volunteers who are trying to keep up with the changes.
Forums actually give the best location for problem solving because they quickly acquire a list of problem reports that are the things that 90% of people hit. These show up clearly in google and will, hopefully, get solutions posted or FAQs written.
Until the non-technical users of Free software step up to volunteer to write and maintain documentation for software projects, there will always be a lack of current, complete and easily accessible documentation. However, good documentation is hard to write and I often find that commercial software projects are distinctly lacking when it comes to good writing, so I don't think this is an issue which is restricted to open source software.
That is hardly "Which you could 'install' by just sticking them in ~/.fonts." and while upon closer inspection it turns out i wasn't compiling running rpmbuild, i still think that is far more work than anybody should have to do to get a some essential fonts.
No - what was pointed to you was a way you could get all the Microsoft Core Web fonts installed under the control of the package management system. That is one way.
If you happened to have all the MS fonts on a USB key, you could have just plugged it into your Linux box and copied it into your ~/.fonts directory. This too would have worked for your user, but would not have allowed another user on the same machine to use the same fonts.
Then the electrician fucked up. He is supposed to know that breaker should not allow higher currents than the line and outlet can handle.
The electrician has no control on how many devices you hook up to the circuit. A circuit probably has 5 - 12 outlets/lights on it. The circuit breaker is protecting the entire circuit against current exceeding the safe range for the wiring. Per-plug fuses allow the manufacturer to place a lower limit per appliance - no reason why a TV would need more than a 5A fuse, whereas a kettle or microwave is probably pushing 10A+. Also, a light appliance (say a radio) probably has wiring that only copes with Cheers,
Toby Haynes
No - the RC is usually nearly identical to the actual release. Only if there is something totally disastrous (eats your data, leaves dirty socks in the hall, sleeps with your girlfriend/boyfriend/cat/dog) would the final release be delayed.
Lotus Notes isn't an email program. It's an application development platform with multiple backend databases, networking interfaces plus a scripting language, a plugin system and a ton of other stuff. That it reads and writes email is just proof of JWZ's assertion.
If you've moved up from Notes 7 to Notes 8.5, you've just changed from the native Windows client to the Eclipse client. Folks like me who got our first taste of the Eclipse client at the Notes 7 native Linux release still shudder with horror (although it did allow for an extended coffee break at the start of the day). Certainly Linux Notes 7 -> 8 -> 8.5 has been a journey of performance improvements.
Now I hear colleagues in the corridors moving from Notes 7 to Notes 8 on Windows XP. They aren't too happy right now.
Two simple examples:
- we just "upgraded" to v8.5. It takes 127 seconds to start up. It takes 38 seconds more to show me my inbox. It takes 47 seconds to bring up the editor to reply to the first mail of the day. This is all on a fairly new Dell D630 laptop.
You're kidding me, right? Or you're making up numbers. Or you are running the Windows version amid the antivirus scans...
Linux box, Fedora 11, T60p, 5400rpm drive - hardly a world beater laptop these days. Times are all intervals.
Time to password screen - 3 seconds
Time to interactivity with the welcome screen (the one that displays all the mail, calendar and to-dos) - 10 seconds
Time to display Mail window after clicking mail tab - 2 seconds
Time to show contents of the top mail message - 1 second.
Release 8.5 Revision 20081211.1925 (Release 8.5) Standard Configuration
So either you've got the CPU clocked down or something is eating your cycles. I hardly hold Lotus Notes in high regard but its improved performance significantly in recent releases.
What I think Microsoft will continue to dominate at is Office apps. MS Office has always beat Google Docs for usability and with the introduction of web-based MS Office products I think Microsoft is already preparing to capitalize on its strengths.
The EOL for Microsoft Office 2007 is 2015 I believe. What killer features is Microsoft going to offer in that time frame? Why upgrade at all? Products like KnowledgeTree already provide the needed document management features around existing documents and even if Microsoft moves further in that direction (Sharepoint) the space is already well catered for. Microsoft Office has some insane utilization figures in the Fortune 500 companies - it's effectively 100%.
We're at the point where we don't need to upgrade our hardware every two years to remain current. Companies are moving to 3/4/5 year replacement cycles on hardware and may even push beyond that. Each year extra on existing hardware reduces the MS Windows income. Some companies have started to investigate OpenOffice.org/Symphony/Google Docs instead and ANY that move in that direction are depriving MS of future revenue.
Besides Office, (and windows which as mentioned I think has a limited lifespan left), they also are prime supplies of development tools (Visual Studio) and SQL Server. In the future I see ports of SQL Server to non-Windows platforms, as well as more shifts in Visual Studio towards developing web-based applications.
Porting SQL Server to a non-Windows platform would be interesting because that would almost certainly involve a Linux port. What are the alternatives? Mac OS X server farms are few and far between. The principle database platforms these days are Linux, AIX, Solaris, z/OS and p-series. Oracle and IBM both have heavy and extensive presence on these platforms. It's tough to see how SQL Server could displace enough entrenched customers to make the port plus support actually make a profit.
Visual Studio is an interesting issue but again, that would be entering a crowded marketplace. Also the number of developers is considerably less than the number of people who need an office suite, so even if the profit margins are high, it's not going to be a massive cash cow.
Now, I don't think that Microsoft is going to shut its doors in the next ten years. However, I doubt the company will be wielding anything like the influence it does today.
My Awesomeness is soo great that Not only have I installed it; evaluated it and sent out my reviews to various magazines; I have also configured it to make me coffee and raise my kids.
I need that perl script on my desk NOW! Hang on - if it raises kids, it's probably in Lisp.
And it is already out-of-box extended too much, up to the point where 99% of its users do not understand how Emacs actually works.
Nothing is too extensible.. that's like saying that a language can only have so many features. However, Emacs can be hard to configure for someone who is new to the platform (and yes I use the term platform for the emacs environment). If you are lucky enough to have a Emacs Guru around when you have questions, then you stand a better chance of surviving first contact with the Emacs underbelly. It also helps if you are comfortable with lisp and the hook concept that Emacs makes extensive use of.
Assembling your environment by accreting bits of configuration is a highway to Problemville. You probably just needed to add a local-set-key sexp for the appropriate major or minor mode hook to override TAB. Knowing which key map is current is the trick.
On side of "Emacs" one has to accept that some workflows would be impossible, since there might be no ready button for it. Side of "vi" is flexibility. Side of "Emacs" is conservatism.
I'm in danger of fanning the flames here but I really think you are way off target on the above statement.
If you lift the lid on what Emacs can do (as in, you grok Emacs lisp), then Emacs offers a level of flexibility that can't be matched by vi. I've written utilities built into Emacs to crawl through custom traces looking for specific patterns and summarizing them on the fly as you move through files. View-linkage routines to allow you to navigate two related files (not two similar files - we're not talking about ediff-buffers here) in lock-step. Idle timers allow you to keep internal structures reasonably current without causing the interactive performance of Emacs to suffer. The list goes on.
The others are open source projects, and can look at each other's code. MS can't, or they'd have to open source their code.
This is a completely misleading statement and totally misses the point. Well done!
You don't need to look at the source code to see what other products do. You just need to look at the ODF files they produce. Indeed, given the licenses of the products that implement ODF, you can obtain the copies you need for testing FOR FREE.
Similarly, while your legal department might bar you from reading competitors code for fear of copyright co-mingling, there is nothing to stop you employing a third party to go look on your behalf and write a report on what was done. So you can have your cake and eat it.
The big advantage of Microsoft is that you can buy it on a disk.
The big advantage of Ubuntu is that Canonical will send you, free of charge, an entire Operating System, complete with application stacks, on a DVD if you ask.
Slashdot Mirror
It's part of Semantic. http://cedet.sourceforge.net/semantic.shtml
Anyone that claims either vi or emacs is a useful editor hasn't used a modern Windows IDE. Just the amount of context aware help that is available about the platform is amazing.
That just shows that you haven't used a version of Emacs since the GNU - Lucid split. Lets see - I have language aware parsing (including context-aware tooltips) and completion (ala intellisense), automatic indexes into each file, class browser, helper wizards, version control awareness and integration, fully programmable interaction with the editing buffer to cope with work-specific stuff, electric expansion (and fully modifiable expansion tables), dynamic completion and the ability to work seamlessly with remote files.
And that doesn't touch on all the other features that I use day-to-day, like highlighting, source code comparison and patching, recursive directory comparison and debugger integration.
Anyway who claims that Emacs isn't a useful editor hasn't learned how to use it.
Cheers,
Toby Haynes
It's true that Firefox has typically been playing catch up throughout its lifespan. However, in the last 18 months, it has been seriously lagging behind other browsers (IE aside). Process separation, general speed, stability, memory fragmentation, etc.
This meme about Firefox memory fragmentation just won't die! Firefox 3.0.x you could still claim that Firefox was sucking down more and more memory as pages got visited. With 3.5.x, you can kiss that problem pretty much goodbye - Firefox returns more memory back to the system than any competing browser.
And Firefox isn't the largest memory consumer here either - that prize probably goes to Chrome, simply because one-tab-per-process is inevitably a heavier memory requirement.
Firefox stability is still a minor issue. However, it's stable enough that I get about 1 crash every three days, which is well within my tolerance level (14 extensions, 11 plugins). Tools like abrt provide a decent mechanism for informing the necessary bug trackers.
Speed-wise, Firefox devs know they are in a race with Chrome. 3.6.x looks like it will be faster than 3.5.x by a fair margin. Project Electrolysis stands to improve matters further. I'm all for competition - keeps everyone working on the issue.
Give me a plugin sandbox so that Flash trapping doesn't take out the page and I'll be content.
Cheers,
Toby Haynes
... you have will have to break through that wall at some point.
Maths is not a memory-based subject - you have to build the manipulation skills that Math requires. The only way to acquire that ability is to keep doing the maths problems until they start to click. You need to build a set of tricks to change problems from ones you don't recognize into ones you do. Be prepared to grind it out. Find a set of problems that increase in difficulty and hack at them until they make complete sense. Don't rush and don't attempt to do them all at once.
You also need to find some Math tasks that are fun or interest you. If you are learning about complex numbers, go look up some fractals and look at the formulas. Picks some starting values and play with the numbers. Get a sense of how the numbers move around and a firm underpinning about what is going on. If you are doing calculus, play with the equations of motion and work out what a canon ball does under constant acceleration. Try modelling a N-body system of planets moving around in 2D on a computer. All the time, you will be building an internal model about the way that all this hangs together.
Maths can be extremely rewarding once you grok it. But if you don't get past the struggle phase, it will never give you any pleasure and you'll miss out.
Cheers,
Toby Haynes
Firefox's only major issues in my opinion: Memory consumption
If you think Firefox uses a lot of memory, don't use Chromium.
With an identical set of 9 tabs open, the total Resident memory:
And that's not really a fair comparison - Firefox has 15 extensions and a 12 plugins installed.
Cheers,
Toby Haynes
I didn't mention it, but I sign and date a lot of my comments, especially when I'm helping someone else. That way, when they go in later to see what I changed.
# -jws 01/02/2009 - changes to trace xyz bug. [code] # -jws 01/02/2009 - end changes
That looks awfully like something I would expect your version control repository to tell you. For ages we used to labouriously indicate the problem being fixed and included the "blessed" initials of the developer doing the work. Then we got a real VC and this practice stopped. Life got better.
Cheers,
Toby Haynes
(...) I'm guessing that at best, 128 bit IEEE 754r performs about half the speed of 64bit IEEE 754, purely because of the data width.
According to Douglas Crockford "...it's literally hundreds of times slower than the current format.".
I don't doubt that the software implementations are "hundreds of times slower". I've had my hands deep into several implementations of decimal arithmetic and none of them are even remotely close to IEEE 754 in hardware. IEEE 754r is better than some of the predecessors because a software implementation can map the internal representation to integer maths. However, IEEE 754r does exist in hardware and I was guessing that the hardware IEEE 754r is still half the speed of hardware IEEE 754.
One other thing that IEEE 754 has going for it is the emerging GPU-as-co-processor field. The latest GPUs can do full 64bit IEEE 754 in the stream processors, making massive parallel floating point processing incredibly speedy.
Cheers,
Toby Haynes
Why do processors need decimal number support? 10 is just an arbitrary number humans picked because they happen to have 10 fingers. There's no connection between that and computers.
Clearly you've never dealt with an irate customer who has spent $$$ on your software product, has created a table using "REAL" (4-byte floating point) types and then wonders why the sums are screwing up. IEEE754 can't accurately represent most fractions in the way that humans do and this means that computers using IEEE 754 floating point give different answers to a human sitting down with pen and pencil and doing the same sums. As humans are often the consumer of the information that the computer spits out, making computers produce the correct results is important.
There are plenty of infinite precision computing libraries out there for software developers to use. However, they are all a lot slower than the 4, 8 or 10 byte floating point IEEE 754 calculations which are supported directly by the hardware. Implementing the IEEE 754r calculations directly on the CPU means that you can get close to the same performance levels. I'm guessing that at best, 128 bit IEEE 754r performs about half the speed of 64bit IEEE 754, purely because of the data width.
Cheers,
Toby Haynes
The debate over floating point numbers in ECMAScript is interesting. IEEE 754 has plenty of pitfalls for the unwary but it has one big advantage - it is directly supported by the Intel-compatible hardware that 99+% of desktop users are running. Switching to the IEEE 754r in ECMA Script would have meant a speed hit to the language on the Intel platform until Intel supports it in hardware. This is an area where IBM already has a hardware implementation of IEEE 754r - its available on the POWER6 platform and I believe that the z-Series also has a hardware implementation. I suspect that IBM will continue to push for IEEE 754r in ECMAScript, I wonder whether Intel is considering adding IEEE 754r support to its processors in the future.
Disclaimer: I have no contact with the IBM ECMAScript folks.
Cheers,
Toby Haynes
Perl is one of those languages that most people meet in passing because someone else has hacked up a script to get something out of some file. Which is sad, because understanding what makes Perl different from other languages and why it is often a better choice for wrangling data isn't going to be obvious in one lousy foreach search-and-replace hack. And most people exposed to perl scripts in this manner fall over on the difference between scalar and list context and never discover why perl expressions like $lookup{$term}++ will save them years of work, while making their analysis scripts go faster.
I write Perl modules day in, day out to cope with processing DB2 internals in an attempt to model and improve them. Object-oriented Perl makes this easy, fast and effective. Closures (which I'm sure aren't understood by 90% of the Slashdot community) back this up being able to create anonymous subroutines with data attached which can be processed later. Perl is also effective for parallel task analysis - I have modules for jobserving many tasks across multiple machines and Perl threads make it easy to fire a task off while something else is done.
Perl is an essential part of data analysis for any serious volume of unstructured data. However, I'm not unhappy that it is little understood. Perl makes in the impossible merely hard. If everyone knew how to leverage Perl, I wouldn't have so much fun.
Cheers,
Toby Haynes
Man pages are not tutorials. They are not help pages. They are reference material, designed to quickly and briefly inform the experienced user about the usage of a command and any related files.
Info pages are the next step up. They are often more detailed (witness the Emacs pages) but they are generally written for a technical audience and quite frankly, the average user isn't going to find them anyway or be able to do anything with them if they can find them,
Man pages and Info pages will, if you are very very lucky, be written by the authors of the software who speak the same language you do and are used to writing technical information. They stand some chance of being updated as the software is updated.
Next up on the list of information resources is wikis, hosted at the site where the development is done. These will generally provide more accessible information for new users, will be community driven and hopefully will reflect the state of the code in the last two years. Keeping wikis up to date is a huge task for large projects.
Beyond that, proper documentation requires constant community involvement. Most projects don't have someone looking after the docs - the software is the focus. Even teams like GNOME and KDE struggle to keep their docs even vaguely up to date - witness the dearth of information on the latest release of gdm (2.28.1) for example. And these teams do have volunteers who are trying to keep up with the changes.
Forums actually give the best location for problem solving because they quickly acquire a list of problem reports that are the things that 90% of people hit. These show up clearly in google and will, hopefully, get solutions posted or FAQs written.
Until the non-technical users of Free software step up to volunteer to write and maintain documentation for software projects, there will always be a lack of current, complete and easily accessible documentation. However, good documentation is hard to write and I often find that commercial software projects are distinctly lacking when it comes to good writing, so I don't think this is an issue which is restricted to open source software.
Cheers,
Toby Haynes
That is hardly "Which you could 'install' by just sticking them in ~/.fonts ." and while upon closer inspection it turns out i wasn't compiling running rpmbuild, i still think that is far more work than anybody should have to do to get a some essential fonts.
No - what was pointed to you was a way you could get all the Microsoft Core Web fonts installed under the control of the package management system. That is one way.
If you happened to have all the MS fonts on a USB key, you could have just plugged it into your Linux box and copied it into your ~/.fonts directory. This too would have worked for your user, but would not have allowed another user on the same machine to use the same fonts.
Cheers,
Toby Haynes
Where are my mod points Slashdot? Where are they?
Then the electrician fucked up. He is supposed to know that breaker should not allow higher currents than the line and outlet can handle.
The electrician has no control on how many devices you hook up to the circuit. A circuit probably has 5 - 12 outlets/lights on it. The circuit breaker is protecting the entire circuit against current exceeding the safe range for the wiring. Per-plug fuses allow the manufacturer to place a lower limit per appliance - no reason why a TV would need more than a 5A fuse, whereas a kettle or microwave is probably pushing 10A+. Also, a light appliance (say a radio) probably has wiring that only copes with Cheers,
Toby Haynes
That bug 452518 is already committed for the actual release.
No - the RC is usually nearly identical to the actual release. Only if there is something totally disastrous (eats your data, leaves dirty socks in the hall, sleeps with your girlfriend/boyfriend/cat/dog) would the final release be delayed.
Lotus Notes isn't an email program. It's an application development platform with multiple backend databases, networking interfaces plus a scripting language, a plugin system and a ton of other stuff. That it reads and writes email is just proof of JWZ's assertion.
Cheers,
Toby Haynes
If you've moved up from Notes 7 to Notes 8.5, you've just changed from the native Windows client to the Eclipse client. Folks like me who got our first taste of the Eclipse client at the Notes 7 native Linux release still shudder with horror (although it did allow for an extended coffee break at the start of the day). Certainly Linux Notes 7 -> 8 -> 8.5 has been a journey of performance improvements.
Now I hear colleagues in the corridors moving from Notes 7 to Notes 8 on Windows XP. They aren't too happy right now.
Cheers,
Toby Haynes
Two simple examples: - we just "upgraded" to v8.5. It takes 127 seconds to start up. It takes 38 seconds more to show me my inbox. It takes 47 seconds to bring up the editor to reply to the first mail of the day. This is all on a fairly new Dell D630 laptop.
You're kidding me, right? Or you're making up numbers. Or you are running the Windows version amid the antivirus scans...
Linux box, Fedora 11, T60p, 5400rpm drive - hardly a world beater laptop these days. Times are all intervals.
Release 8.5 Revision 20081211.1925 (Release 8.5) Standard Configuration
So either you've got the CPU clocked down or something is eating your cycles. I hardly hold Lotus Notes in high regard but its improved performance significantly in recent releases.
Cheers,
Toby Haynes
What I think Microsoft will continue to dominate at is Office apps. MS Office has always beat Google Docs for usability and with the introduction of web-based MS Office products I think Microsoft is already preparing to capitalize on its strengths.
The EOL for Microsoft Office 2007 is 2015 I believe. What killer features is Microsoft going to offer in that time frame? Why upgrade at all? Products like KnowledgeTree already provide the needed document management features around existing documents and even if Microsoft moves further in that direction (Sharepoint) the space is already well catered for. Microsoft Office has some insane utilization figures in the Fortune 500 companies - it's effectively 100%.
We're at the point where we don't need to upgrade our hardware every two years to remain current. Companies are moving to 3/4/5 year replacement cycles on hardware and may even push beyond that. Each year extra on existing hardware reduces the MS Windows income. Some companies have started to investigate OpenOffice.org/Symphony/Google Docs instead and ANY that move in that direction are depriving MS of future revenue.
Besides Office, (and windows which as mentioned I think has a limited lifespan left), they also are prime supplies of development tools (Visual Studio) and SQL Server. In the future I see ports of SQL Server to non-Windows platforms, as well as more shifts in Visual Studio towards developing web-based applications.
Porting SQL Server to a non-Windows platform would be interesting because that would almost certainly involve a Linux port. What are the alternatives? Mac OS X server farms are few and far between. The principle database platforms these days are Linux, AIX, Solaris, z/OS and p-series. Oracle and IBM both have heavy and extensive presence on these platforms. It's tough to see how SQL Server could displace enough entrenched customers to make the port plus support actually make a profit.
Visual Studio is an interesting issue but again, that would be entering a crowded marketplace. Also the number of developers is considerably less than the number of people who need an office suite, so even if the profit margins are high, it's not going to be a massive cash cow.
Now, I don't think that Microsoft is going to shut its doors in the next ten years. However, I doubt the company will be wielding anything like the influence it does today.
Cheers,
Toby Haynes
My Awesomeness is soo great that Not only have I installed it; evaluated it and sent out my reviews to various magazines; I have also configured it to make me coffee and raise my kids.
I need that perl script on my desk NOW! Hang on - if it raises kids, it's probably in Lisp.
The problem is that Emacs is *too* extensible.
...snip...
And it is already out-of-box extended too much, up to the point where 99% of its users do not understand how Emacs actually works.
Nothing is too extensible .. that's like saying that a language can only have so many features. However, Emacs can be hard to configure for someone who is new to the platform (and yes I use the term platform for the emacs environment). If you are lucky enough to have a Emacs Guru around when you have questions, then you stand a better chance of surviving first contact with the Emacs underbelly. It also helps if you are comfortable with lisp and the hook concept that Emacs makes extensive use of.
Assembling your environment by accreting bits of configuration is a highway to Problemville. You probably just needed to add a local-set-key sexp for the appropriate major or minor mode hook to override TAB. Knowing which key map is current is the trick.
Cheers,
Toby Haynes
On side of "Emacs" one has to accept that some workflows would be impossible, since there might be no ready button for it. Side of "vi" is flexibility. Side of "Emacs" is conservatism.
I'm in danger of fanning the flames here but I really think you are way off target on the above statement.
If you lift the lid on what Emacs can do (as in, you grok Emacs lisp), then Emacs offers a level of flexibility that can't be matched by vi. I've written utilities built into Emacs to crawl through custom traces looking for specific patterns and summarizing them on the fly as you move through files. View-linkage routines to allow you to navigate two related files (not two similar files - we're not talking about ediff-buffers here) in lock-step. Idle timers allow you to keep internal structures reasonably current without causing the interactive performance of Emacs to suffer. The list goes on.
Vi is extensible. Emacs is more extensible.
Cheers,
Toby Haynes
The others are open source projects, and can look at each other's code. MS can't, or they'd have to open source their code.
This is a completely misleading statement and totally misses the point. Well done!
You don't need to look at the source code to see what other products do. You just need to look at the ODF files they produce. Indeed, given the licenses of the products that implement ODF, you can obtain the copies you need for testing FOR FREE.
Similarly, while your legal department might bar you from reading competitors code for fear of copyright co-mingling, there is nothing to stop you employing a third party to go look on your behalf and write a report on what was done. So you can have your cake and eat it.
Cheers,
Toby Haynes
The big advantage of Microsoft is that you can buy it on a disk.
The big advantage of Ubuntu is that Canonical will send you, free of charge, an entire Operating System, complete with application stacks, on a DVD if you ask.
Cheers,
Toby Haynes