Below is a VM with a "reduced instruction set", illustrating what I meant with low-resolution threads. The VM has full threading capability. (The code actually works.)
bool execute (PackArray<int>& code, List<Thread*>& threads) { printf ("Thread %d, instruction %05d: %03d\n", mThreadId, mInstruction, code[mInstruction]); switch (code[mInstruction]) { case VMBC_BRK:// Break; exit the thread. if (mpParent) mpParent->mChildCount--; return true; case VMBC_NOP:// Do nothing mInstruction++; break; case VMBC_FORK:// Create a thread threads.add (new Thread (this, code[mInstruction+1])); mInstruction += 2; break; case VMBC_JOIN:// Join all child threads if (mChildCount == 0) mInstruction++; break; } return false;// Do not exit the thread.
} }; int Thread::smThreadCounter = 0;
Main () {
PackArray<int> instructions (20);
instructions[0] = VMBC_FORK;// Fork to instruction 5
instructions[1] = 5;
instructions[2] = VMBC_FORK;// Fork to instruction 8
instructions[3] = 8;
instructions[4] = VMBC_JOIN;// Wait for the threads to exit.
instructions[5] = VMBC_NOP;// Thread 1; do nothing.
instructions[6] = VMBC_NOP;// Thread 1; do nothing.
instructions[7] = VMBC_BRK;// Thread 1; exit thread.
instructions[8] = VMBC_NOP;// Thread 2; do nothing.
instructions[9] = VMBC_BRK;// Thread 2; exit thread.
// Add the main thread.
List<Thread*> threadpool;
threadpool.add (new Thread ());
// Run VM
int threadCount;
do { threadCount = 0; for (ListIter<Thread*> i (threadpool); !i.exhausted (); i.next (), threadCount++) if (i.get()->execute (instructions, threadpool)) i.deleteCurrent ();// The thread exited
} while (threadCount > 0); }
Well, yes, I think it's a rather safe assumption if the threading is implemented in the VM; formatting and printing a buffer would probably be implemented with an efficient native function, which would be atomic.
But, yes, if we use native threading, the context switch could occur anywhere, and the output would be a mess, just as you describe. As noted in other messages in this thread (ummm...this discussion thread), using native threading would probably be the wisest choise.
I don't know Occam really at all, but I don't quite like the normal Java or Posix ways of threading either. The PAR statement in Occam might make threading so much easier.
While I'm sure someone could write a VM that did that, I don't think anyone would want to use it. On an x86, a context switch costs enough that one instruction per context switch would give you a bit more than 95% overhead lost on context switching.
You're right, assuming that the VM uses native threads. I was thinking of having the threading implemented in the VM; I guess it would be kind of trivial and it would have very little (if any) overhead because of context switching, although there might be some other costs.
But of course, without native threads, we would lose the possibility to use multiple processors easily, which wouldn't be very nice.
Then why have this low resolution? A friend of mine has a home-brewn VM for an ad-hoc language for embedded programming that handles concurrent execution one instruction at a time. He says it's very important for his embedded application. I don't know his specific reasons, but I'd imagine it has something to do with controlling multiple embedded devices and interfaces.
Anyhow, low-resolution concurrency just sounds cool.;-)
Don't you pay by the MB for GPRS? Isn't that like a $1 email?
Nope, I have a flat rate GPRS connection, 16 euros ($20) a month. Well, it's a special offer; the typical GPRS cost here in Finland is around 2 euros/MB ($2,5/MB). Well, yeah, that would be a bit too much for emailing MPEG clips...
Cramming a small camera in a cell phone results only in useless crappy quality pictures. Not a good idea.
Putting a cell phone - or network connection - to digital cameras is a much nicer idea.
Yesterday, I purchased Sony TRV50E digital video camera that has Bluetooth connection. By chance, I happen to own a Nokia 6310i cell phone, which has Bluetooth and GPRS.
TRV50E has a built-in web browser and mail client in the camera and 3,5 inch touch-screen. I can now take 1300x1024 stills with the video camera, or 320x240 MPEG-2s, and write normal e-mails and attach the stills or video clips as email attachments, using the cell phone as a modem. It's also nice to surf the web using a "large" screen and a stylus, much nicer than with any WAP crap.
Rather nice web-pad...ehm...web-brick, eh?
Well, in theory; the video camera connects just fine with the cell phone, and makes a PPP connection, but the GPRS connection fails for some reason. I'm investigating the problem, but unfortunately these cameras and cell phones are not yet too common even here in Finland...
One reason that I've very often seen lead to failed projects is assigning them to people who simply can't do them. Not necessarily because they don't know anything about programming, but because they don't know the tools they have to use.
Years ago I was assigned a UNIX - MS Access integration project where I had to translate EDI messages to Access tables. I had never worked with Access before. I told my boss that I can't do it in reasonable time, but there wasn't anyone else free at the moment, so I was forced to do it. The result was that after three months of coding, $100/hour from the customer, I had learned to program with MS Access - by learning how not to do it. I burned out and quit. The horrible software was probably rewritten from scratch.
I have seen many really horrible examples of similar situations with other programmers, often with people dabbling with C++, lately with people who simply don't know how to program with C. Oh, what incredible examples I could give you! The result has been indescribable garbage. The garbage often works in the planned test cases, barely, but bleeds memory like a pierced pig and crashes from a slightest variation.
Many of these catastrophies occur because the programmers do not honestly admit: "I can't do this." And even if the programmers would admit, their managers won't when dealing with the customers.
All tools require learning. Some have a soft learning curve, some steep as a mountain. It doesn't matter much how professional one is, when it comes to learning new, conceptionally very different tools. Managers don't often understand this.
Just as often, programmers are assigned to projects of which they do not have a clear vision, usually because of too superficial specifications. Without proper vision, they can't find the right attitude to write beautiful, perfectionist code. They need inspiration, and finding it often takes time.
Yeah, seeing what also the other people have said about MainActor, I'd probably be better off with Cinelerra.
I tried Cinelerra a few days ago, but didn't manage to capture anything with it, although it seemed to control my TV card interface just fine. The UI is not too good. Oh well, I'll keep trying.
The article mentioned a few developments in Finland.
There's also a newer one, made by a member of Finnish parliament Kyösti Karjula (Center Party):
"Member of Parliament Kyösti Karjula and three other members have made an initiative for the government to take practical measures towards to adopt the Linux operating system in public administration. According to the members, the advantages of Linux are financial savings and better security than in Windows.
'There is also a significant technology political reason for changing over to Linux, because a system based on open source makes it possible to advance [Finnish] know-how....' " (references to German decision, etc.)
In December 2001, the IT Department of City of Turku published their final report on adopting OpenOffice and Linux for the city computer systems. The report takes a "negative" approach, listing the problems encountered, so it's rather interesting read. In the conclusions, they recommended the adoption of OpenOffice and Linux, and to proceed with an extended study and a pilot period.
Turku (my home city) has a population of about 160,000 and the city has about 3000 computers. However, if Turku adopts Linux, dozens of the surrounding small (and large) munincipalities will follow.
German company MainConcept makes a video editing software for Linux and Windows platforms. Check out MainActor.
The cross-platform compatibility is done with Qt, so the basic user-interface quality is very good. Some strangeness in some video editing UI concepts, but otherwise excellent.
I've tried the Linux demo version abt two years ago. It was rather nice even then.
For more than 10 years, practically all university students have gotten a UNIX login, and universities have been full of public terminals for students in labs and in hallways. In some richer universities, they have even had *oooh* X-terminals.
The machines have usually been Sun, but I don't think Linux would be overwhelmingly different from them...
So forgive me if I don't quite understand the question. UNIX has been a feasible solution for all students for years, and there's little reason to believe Linux wouldn't be.
Many of the headlines are quite revealing about their intentions. Many are about the importance of MCSE:
Inc. 500 Shops Value Certification Most (MCSE vs college degrees)
Familiarity Breeds Respect "Recruiters tend to hire MCSEs just as often, if not more so, than those with a four-year college degree."
Technology Trends: Program Provides Information For New Age
"Eighty-seven percent of human resource managers surveyed believed that MCSE's are equally or more successful than college students."
The Impact of Technology Training Programs Case Study: MCSE Training
And then there are numerous anti-trust criticism articles:
Break up Microsoft? Rest of world pooh-poohs the notion
Press Release: Japan, Switzerland, and the EU do NOT insist on breakup of Microsoft, unlike the U.S.
Fine Microsoft, use funds for new competition (anti-breakup)
Fine Microsoft and use funds to catalize new competition (anti-breakup)
Break-up Remedy for Microsoft Not Supported by Key Democrats
Technology and The Congressional Black Caucus (Microsoft anti-trust)
Breaking Windows Over Antitrust Dogma
Pause the Microsoft Case and Examine U.S. Anti-trust Policy
Punishing Winners Hurts the Marketplace
Suit Threatens U.S. Computer Dominance
Taking a Byte Out of Microsoft
Etc. Also lots of articles about the precious intellectual property rights, although not specifically in relation to Microsloth.
Views on software patents
on
Fair IP Laws?
·
· Score: 2
To my understanding. there is an essential difference in the European
and American concepts of software with regards to patents.
In the "European" concept of software, software is a
specification or a design; it is information that can be used to
control a machine, i.e., a computer to perform in a particular way.
In the "American" concept of software, the software itself is a
machine, even when it's just written on a paper (or a CD) and can't
actually do anything without a computer.
Now, the purpose of patents is same in both European and American
systems: you can patent a method of doing something, i.e., a design or
specification of a machine.
However, the patent laws only apply to producers, i.e.,
commercial entities that manufacture machines for consumers. They
don't apply to consumers who build a machine just for
themselves. Patents also do not restrict the distribution of the
specification of the patented method.
Now, when you combine the European concept of software with the
purpose of patents, you get a situation where a typical software
product is never a machine, i.e., an implementation, by the
definition of patent laws. The software producer only provides a
"specification" of a patented method, which can be distributed freely
(even for profit), and the consumer can combine the specification
with a generic machine to produce a specific machine that
implements the patented method.
This leads into many funny things; also the registered patent
description is a specification of the method. Usually, if you want to
implement it in a program, you need to make it much more detailed and
make the implementation in a particular language. But if the patent
specification is detailed enough, you could, in principle, translate
it automatically to run it in a computer. Therefore, merely publishing
the patented method means implementing the "software product".
However, this interpretation leaves room for one case where patents do
apply to software: when the software is integrated with the hardware
by a producer. Hence, most embedded software stuff falls under patent
laws, if the software is integrated in the produced machine. For
example, PDAs and cell phones.
You might also think that this applies also to software bundled with a
computer. I don't think it does, because *bundled* software is not an
*integral* part of the computer and can be replaced by the
consumer. Of course, this argument applies to much of the embedded
software too, if it can be replaced by the consumer.
I think this is why you can patent software related methods in Europe,
but also why they are not really useful except in the embedded market.
The "software is a machine" interpretation may, to some degree, be
sensible with closed source proprietary software, as there the
software is no longer a human-readable form, and can no longer be seen
as merely a specification of the patented method. With this metaphor, closed software is a "virtual" machine (obs - not in the normal sense of "VMs").
Interestingly, from this viewpoint, there is exactly one licencing
model under which the software can not be interpreted as as a
"machine". It's GNU General Public License (and LGPL too). Only in
this license, the source code of the software must always be made
available. Hence, with GPL'ed software, the specification of the
patented method is always human readable, and is merely just that, a
specification.
It's very interesting to arrive at GPL as a solution in the topic of software patents, instead of the normal arguments of software freedom. With this approach, GPL might one day even be written in laws!
Nevertheless, I believe the "American" concept of software is
contradictory. I can imagine that you could, in principle, crush
American software patents (or more exactly their applicability) merely
by argumenting with this conceptual framework. Even laws can be proved
contradictory in court, I guess.
The problem, of course, is that if you can patent, in United States, a
method of swinging in a children's swing, a method of excercising your
cat with a laser pointer, or "business methods", the patent laws must
already be so absurdly arbitrary that no rational arguments can ever
defeat them.
See Nokia 5510, it has a largeish split keyboard. Haven't tried it, but I'd imagine it's at least some good.
And of course, the Communicator has a normal QWERTY keyboard.
Other Nokia (and most other makers too) have a predictive system. In my 6310i, it seems to work pretty well, although it's not very useful where you need it most often, inputting text in WAP pages. For example, it can't predict your usernames or passwords for wap sites very well...
Not that I ever send SMSs. Well, maybe one or two per cell phone I've owned, just to see how it works.
BTW, WAP version of/. would really be cool, you could read all new things on your cell phone (with GPRS of course). The WAP/HTTP gateways don't seem to convert large html pages to wml very well.
Remember how annoyed you get every time you get a Word doc from someone, and you need to switch to Windows for opening that doc?
Make a friendly "quasi-revenge" with OpenOffice attachments. But unlike Word docs, the receiver can open the documents in any operating system, and the application doesn't even cost anything for him or her. There is no excuse.
After the installation, the receiver has excellent office tools which he or she can use freely without MS Tax, and can send everyone documents in *really* universal open format, unlike Word.
I completely agree on your points, especially these:
Over-communicate and formalize communication
QA at home.
Having managed a few small software outsourcing projects (as a technical auditor of the client), I must say you can't understate the importance of communication. In the projects I was involved in, the communication was not entirely adequate, which resulted in lower quality. I don't think it's relevant that they're in India, the issues are much the same if their office is just next door. Or even in the same door.
As in all software projects, specify everything in minute detail and don't hesitate to be redundant. If they don't have a faintest idea of what you're talking about, they'll just nod like they do understand. That's what we all do. Don't assume that they understand everything "because they're professionals". Don't throw at them overly abstract marketing-crap material, that'll just confuse them. Try to take many approaches in explaining them what you really want.
Most important thing with outsourcing, I believe, is transferring the contractors the vision and right attitude for coding for the project and your company. All good code comes from enthusiastic attitude, but the programmer can't be enthusiastic if he doesn't have a clear vision of the objectives or doesn't understand what's really cool about them.
As you noted, QA is extremely important. If the programmers haven't gotten the exactly correct vision about the project or don't have the right attitude, QA is the only way to find out about it.
Code reviews are of course the butter and bread of outsourcing QA. Try to make them systematic, possibly automated to some degree. After complaining about a problem, really check that it is fixed (I haven't done this always and I've often regretted afterwards). Very often coders "forget" some requirements or feedback issues which really are important. For example, maintain a shell/python/perl script for checking problems in the sources, and if you at one point complain, for example, that the program allocates a lot of memory but never frees it, just add a "grep" line in your script to check that they'll really add at least some free's, so you can be certain that they've done at least something because of your feedback. "rgrep -r" is really useful for this kind of tasks.
Some of the problems in outsourcing are inherent, for example that the contractors don't always have enough information about the overall systems because it is confidential. A similar problem is that they aren't at home with the conventions and working protocols of your company, which takes their attention away from their real work, coding.
And of course, if you don't trust cheap Indian labour, you can always opt for cheap Finnish programmers! (We really don't get paid very well here.)
The description doesn't seem very different from OpenOffice(.org!!!11). It makes me think if the "partly based on OpenOffice.org" actually means everything but the name and graphics...
Not that there's anything wrong in repackaging GPL'ed software, as long as you give the credit where credit is due, and the source of course. Which they seem to do.
At least the last 0.9.9 RPM packages were rubbish; Mozilla threw Segmentation fault immediately at startup. Same both with my home comp (i586 with Mdk Linux) and my work laptop (i686 with RH 7.1), so this can't be just a random problem.
Amazingly, the nightly build RPMs seem to work just fine.
This is definitely not the first time this happens. I don't know who compiles Mozilla for packaging, but it's obviously not done very well. Problems this obvious (Segfault at startup) don't give a very fancy image of Mozilla.
All packages should be tested at least somehow before distribution.
Why hasn't Debian project adopted the Corel Linux (nowadays Xandros Linux) installer? It's absolutely best Linux installer there is; much better than Red Hat, Mandrake, or SuSE.
Is the installer non-free software or what is the reason?
IMHO, using the Corel installer would give Debian a big jump forward. Debian's installation, especially the awkward dselect, is definitely its weakest point.
In Finnish news yesterday, an ex-minister was charged of debt fraud. He had taken loans from various sources to pay for his losses in Nigerian letter scams. He estimates that he lost about $350,000 in the scams.
Olavi J. Mattila was previously Finnish Foreign Minister, Minister of Trade and Industry, and Minister of Foreign Trade. That is, a major political figure. He was also the CEO of some large Finnish multi-billion-dollar companies (such as Valmet, a world-known machinery company) and a presidential councellor. His education was a Master of Engineering and Master of Economic Science. He retired in 1982.
So he wasn't just a dabbler in business. Perhaps he was getting senile at his current age of 84.
Having good MS Office filters would be enormously important for OpenOffice and StarOffice.
Word file format is the de facto standard in most companies and institutions. Most internal and external communication and documentation is done with Word and Excel, and you need to import , edit, and then export MS Office documents. Without perfect, 100% compatible filters, you simply can't use OpenOffice in such an environment. If even one word wraps differently, a table can go useless. Not that MS Office itself is totally free of these problems, but they are much worse with OO/SO.
OpenOffice export filter to MS Word breaks very easily. Sometimes even basic formatting is lost. Some images disappear. Bullets turn into strange symbols. Tables of Contents and Indexes break. Pages with complex headers or footers simply cause Word to crash.
Even really simple things such as WMF, JPEG, or GIF export filters are faulty in sdraw. GIF doesn't seem to work at all, and WMF and JPEG lose objects under certain conditions.
The filters are OO's definitely weakest point at the moment. I hope they get the problems solved, as it's otherwise such a great software.
Slashdot Mirror
"Ooooooh" and "aaaaaah", that's how it always starts. But then later comes the running and screaming. I mean, life will find a way.
-- Ian Malcolm
You're assuming print is atomic.
Well, yes, I think it's a rather safe assumption if the threading is implemented in the VM; formatting and printing a buffer would probably be implemented with an efficient native function, which would be atomic.
But, yes, if we use native threading, the context switch could occur anywhere, and the output would be a mess, just as you describe. As noted in other messages in this thread (ummm...this discussion thread), using native threading would probably be the wisest choise.
I don't know Occam really at all, but I don't quite like the normal Java or Posix ways of threading either. The PAR statement in Occam might make threading so much easier.
While I'm sure someone could write a VM that did that, I don't think anyone would want to use it. On an x86, a context switch costs enough that one instruction per context switch would give you a bit more than 95% overhead lost on context switching.
;-)
You're right, assuming that the VM uses native threads. I was thinking of having the threading implemented in the VM; I guess it would be kind of trivial and it would have very little (if any) overhead because of context switching, although there might be some other costs.
But of course, without native threads, we would lose the possibility to use multiple processors easily, which wouldn't be very nice.
Then why have this low resolution? A friend of mine has a home-brewn VM for an ad-hoc language for embedded programming that handles concurrent execution one instruction at a time. He says it's very important for his embedded application. I don't know his specific reasons, but I'd imagine it has something to do with controlling multiple embedded devices and interfaces.
Anyhow, low-resolution concurrency just sounds cool.
It would also be nice to have language-level support for parallel processing, like in Occam.
For example, in a Python implementation, the following code would execute the two for-statements in the "par"-block in parallel:
As the two threads would be executed exactly at the same speed, the output would be:
Don't you pay by the MB for GPRS? Isn't that like a $1 email?
Nope, I have a flat rate GPRS connection, 16 euros ($20) a month. Well, it's a special offer; the typical GPRS cost here in Finland is around 2 euros/MB ($2,5/MB). Well, yeah, that would be a bit too much for emailing MPEG clips...
Cramming a small camera in a cell phone results only in useless crappy quality pictures. Not a good idea.
Putting a cell phone - or network connection - to digital cameras is a much nicer idea.
Yesterday, I purchased Sony TRV50E digital video camera that has Bluetooth connection. By chance, I happen to own a Nokia 6310i cell phone, which has Bluetooth and GPRS.
TRV50E has a built-in web browser and mail client in the camera and 3,5 inch touch-screen. I can now take 1300x1024 stills with the video camera, or 320x240 MPEG-2s, and write normal e-mails and attach the stills or video clips as email attachments, using the cell phone as a modem. It's also nice to surf the web using a "large" screen and a stylus, much nicer than with any WAP crap.
Rather nice web-pad...ehm...web-brick, eh?
Well, in theory; the video camera connects just fine with the cell phone, and makes a PPP connection, but the GPRS connection fails for some reason. I'm investigating the problem, but unfortunately these cameras and cell phones are not yet too common even here in Finland...
One reason that I've very often seen lead to failed projects is assigning them to people who simply can't do them. Not necessarily because they don't know anything about programming, but because they don't know the tools they have to use.
Years ago I was assigned a UNIX - MS Access integration project where I had to translate EDI messages to Access tables. I had never worked with Access before. I told my boss that I can't do it in reasonable time, but there wasn't anyone else free at the moment, so I was forced to do it. The result was that after three months of coding, $100/hour from the customer, I had learned to program with MS Access - by learning how not to do it. I burned out and quit. The horrible software was probably rewritten from scratch.
I have seen many really horrible examples of similar situations with other programmers, often with people dabbling with C++, lately with people who simply don't know how to program with C. Oh, what incredible examples I could give you! The result has been indescribable garbage. The garbage often works in the planned test cases, barely, but bleeds memory like a pierced pig and crashes from a slightest variation.
Many of these catastrophies occur because the programmers do not honestly admit: "I can't do this." And even if the programmers would admit, their managers won't when dealing with the customers.
All tools require learning. Some have a soft learning curve, some steep as a mountain. It doesn't matter much how professional one is, when it comes to learning new, conceptionally very different tools. Managers don't often understand this.
Just as often, programmers are assigned to projects of which they do not have a clear vision, usually because of too superficial specifications. Without proper vision, they can't find the right attitude to write beautiful, perfectionist code. They need inspiration, and finding it often takes time.
Thanks for the advice.
Yeah, seeing what also the other people have said about MainActor, I'd probably be better off with Cinelerra.
I tried Cinelerra a few days ago, but didn't manage to capture anything with it, although it seemed to control my TV card interface just fine. The UI is not too good. Oh well, I'll keep trying.
The article mentioned a few developments in Finland.
...' " (references to German decision, etc.)
There's also a newer one, made by a member of Finnish parliament Kyösti Karjula (Center Party):
"Member of Parliament Kyösti Karjula and three other members have made an initiative for the government to take practical measures towards to adopt the Linux operating system in public administration. According to the members, the advantages of Linux are financial savings and better security than in Windows.
'There is also a significant technology political reason for changing over to Linux, because a system based on open source makes it possible to advance [Finnish] know-how.
In December 2001, the IT Department of City of Turku published their final report on adopting OpenOffice and Linux for the city computer systems. The report takes a "negative" approach, listing the problems encountered, so it's rather interesting read. In the conclusions, they recommended the adoption of OpenOffice and Linux, and to proceed with an extended study and a pilot period.
Turku (my home city) has a population of about 160,000 and the city has about 3000 computers. However, if Turku adopts Linux, dozens of the surrounding small (and large) munincipalities will follow.
German company MainConcept makes a video editing software for Linux and Windows platforms. Check out MainActor.
The cross-platform compatibility is done with Qt, so the basic user-interface quality is very good. Some strangeness in some video editing UI concepts, but otherwise excellent.
I've tried the Linux demo version abt two years ago. It was rather nice even then.
Price $99.
Many of the headlines are quite revealing about their intentions. Many are about the importance of MCSE:
- Inc. 500 Shops Value Certification Most (MCSE vs college degrees)
- Familiarity Breeds Respect
- Technology Trends: Program Provides Information For New Age
- The Impact of Technology Training Programs Case Study: MCSE Training
And then there are numerous anti-trust criticism articles:"Recruiters tend to hire MCSEs just as often, if not more so, than those with a four-year college degree."
"Eighty-seven percent of human resource managers surveyed believed that MCSE's are equally or more successful than college students."
- Break up Microsoft? Rest of world pooh-poohs the notion
- Press Release: Japan, Switzerland, and the EU do NOT insist on breakup of Microsoft, unlike the U.S.
- Fine Microsoft, use funds for new competition (anti-breakup)
- Fine Microsoft and use funds to catalize new competition (anti-breakup)
- Break-up Remedy for Microsoft Not Supported by Key Democrats
- Technology and The Congressional Black Caucus (Microsoft anti-trust)
- Breaking Windows Over Antitrust Dogma
- Pause the Microsoft Case and Examine U.S. Anti-trust Policy
- Punishing Winners Hurts the Marketplace
- Suit Threatens U.S. Computer Dominance
- Taking a Byte Out of Microsoft
Etc. Also lots of articles about the precious intellectual property rights, although not specifically in relation to Microsoft.Make your own conclusions freely.
For more than 10 years, practically all university students have gotten a UNIX login, and universities have been full of public terminals for students in labs and in hallways. In some richer universities, they have even had *oooh* X-terminals.
The machines have usually been Sun, but I don't think Linux would be overwhelmingly different from them...
So forgive me if I don't quite understand the question. UNIX has been a feasible solution for all students for years, and there's little reason to believe Linux wouldn't be.
Many of the headlines are quite revealing about their intentions. Many are about the importance of MCSE:
- Inc. 500 Shops Value Certification Most (MCSE vs college degrees)
- Familiarity Breeds Respect
- Technology Trends: Program Provides Information For New Age
- The Impact of Technology Training Programs Case Study: MCSE Training
And then there are numerous anti-trust criticism articles:"Recruiters tend to hire MCSEs just as often, if not more so, than those with a four-year college degree."
"Eighty-seven percent of human resource managers surveyed believed that MCSE's are equally or more successful than college students."
Etc. Also lots of articles about the precious intellectual property rights, although not specifically in relation to Microsloth.
In the "European" concept of software, software is a specification or a design; it is information that can be used to control a machine, i.e., a computer to perform in a particular way.
In the "American" concept of software, the software itself is a machine, even when it's just written on a paper (or a CD) and can't actually do anything without a computer.
Now, the purpose of patents is same in both European and American systems: you can patent a method of doing something, i.e., a design or specification of a machine.
However, the patent laws only apply to producers, i.e., commercial entities that manufacture machines for consumers. They don't apply to consumers who build a machine just for themselves. Patents also do not restrict the distribution of the specification of the patented method.
Now, when you combine the European concept of software with the purpose of patents, you get a situation where a typical software product is never a machine, i.e., an implementation, by the definition of patent laws. The software producer only provides a "specification" of a patented method, which can be distributed freely (even for profit), and the consumer can combine the specification with a generic machine to produce a specific machine that implements the patented method.
This leads into many funny things; also the registered patent description is a specification of the method. Usually, if you want to implement it in a program, you need to make it much more detailed and make the implementation in a particular language. But if the patent specification is detailed enough, you could, in principle, translate it automatically to run it in a computer. Therefore, merely publishing the patented method means implementing the "software product". However, this interpretation leaves room for one case where patents do apply to software: when the software is integrated with the hardware by a producer. Hence, most embedded software stuff falls under patent laws, if the software is integrated in the produced machine. For example, PDAs and cell phones.
You might also think that this applies also to software bundled with a computer. I don't think it does, because *bundled* software is not an *integral* part of the computer and can be replaced by the consumer. Of course, this argument applies to much of the embedded software too, if it can be replaced by the consumer.
I think this is why you can patent software related methods in Europe, but also why they are not really useful except in the embedded market.
The "software is a machine" interpretation may, to some degree, be sensible with closed source proprietary software, as there the software is no longer a human-readable form, and can no longer be seen as merely a specification of the patented method. With this metaphor, closed software is a "virtual" machine (obs - not in the normal sense of "VMs").
Interestingly, from this viewpoint, there is exactly one licencing model under which the software can not be interpreted as as a "machine". It's GNU General Public License (and LGPL too). Only in this license, the source code of the software must always be made available. Hence, with GPL'ed software, the specification of the patented method is always human readable, and is merely just that, a specification.
It's very interesting to arrive at GPL as a solution in the topic of software patents, instead of the normal arguments of software freedom. With this approach, GPL might one day even be written in laws!
Nevertheless, I believe the "American" concept of software is contradictory. I can imagine that you could, in principle, crush American software patents (or more exactly their applicability) merely by argumenting with this conceptual framework. Even laws can be proved contradictory in court, I guess.
The problem, of course, is that if you can patent, in United States, a method of swinging in a children's swing, a method of excercising your cat with a laser pointer, or "business methods", the patent laws must already be so absurdly arbitrary that no rational arguments can ever defeat them.
See Nokia 5510, it has a largeish split keyboard. Haven't tried it, but I'd imagine it's at least some good.
/. would really be cool, you could read all new things on your cell phone (with GPRS of course). The WAP/HTTP gateways don't seem to convert large html pages to wml very well.
And of course, the Communicator has a normal QWERTY keyboard.
Other Nokia (and most other makers too) have a predictive system. In my 6310i, it seems to work pretty well, although it's not very useful where you need it most often, inputting text in WAP pages. For example, it can't predict your usernames or passwords for wap sites very well...
Not that I ever send SMSs. Well, maybe one or two per cell phone I've owned, just to see how it works.
BTW, WAP version of
Start emailing stuff as OpenOffice attachments.
Remember how annoyed you get every time you get a Word doc from someone, and you need to switch to Windows for opening that doc?
Make a friendly "quasi-revenge" with OpenOffice attachments. But unlike Word docs, the receiver can open the documents in any operating system, and the application doesn't even cost anything for him or her. There is no excuse.
After the installation, the receiver has excellent office tools which he or she can use freely without MS Tax, and can send everyone documents in *really* universal open format, unlike Word.
Yes, OpenOffice can be viral.
- Over-communicate and formalize communication
- QA at home.
Having managed a few small software outsourcing projects (as a technical auditor of the client), I must say you can't understate the importance of communication. In the projects I was involved in, the communication was not entirely adequate, which resulted in lower quality. I don't think it's relevant that they're in India, the issues are much the same if their office is just next door. Or even in the same door.As in all software projects, specify everything in minute detail and don't hesitate to be redundant. If they don't have a faintest idea of what you're talking about, they'll just nod like they do understand. That's what we all do. Don't assume that they understand everything "because they're professionals". Don't throw at them overly abstract marketing-crap material, that'll just confuse them. Try to take many approaches in explaining them what you really want.
Most important thing with outsourcing, I believe, is transferring the contractors the vision and right attitude for coding for the project and your company. All good code comes from enthusiastic attitude, but the programmer can't be enthusiastic if he doesn't have a clear vision of the objectives or doesn't understand what's really cool about them.
As you noted, QA is extremely important. If the programmers haven't gotten the exactly correct vision about the project or don't have the right attitude, QA is the only way to find out about it.
Code reviews are of course the butter and bread of outsourcing QA. Try to make them systematic, possibly automated to some degree. After complaining about a problem, really check that it is fixed (I haven't done this always and I've often regretted afterwards). Very often coders "forget" some requirements or feedback issues which really are important. For example, maintain a shell/python/perl script for checking problems in the sources, and if you at one point complain, for example, that the program allocates a lot of memory but never frees it, just add a "grep" line in your script to check that they'll really add at least some free's, so you can be certain that they've done at least something because of your feedback. "rgrep -r" is really useful for this kind of tasks.
Some of the problems in outsourcing are inherent, for example that the contractors don't always have enough information about the overall systems because it is confidential. A similar problem is that they aren't at home with the conventions and working protocols of your company, which takes their attention away from their real work, coding.
And of course, if you don't trust cheap Indian labour, you can always opt for cheap Finnish programmers! (We really don't get paid very well here.)
The description doesn't seem very different from OpenOffice(.org!!!11). It makes me think if the "partly based on OpenOffice.org" actually means everything but the name and graphics...
Not that there's anything wrong in repackaging GPL'ed software, as long as you give the credit where credit is due, and the source of course. Which they seem to do.
I still have some deep-rooted sticker marks on my old tv to mark the positions of resources.
At least the last 0.9.9 RPM packages were rubbish; Mozilla threw Segmentation fault immediately at startup. Same both with my home comp (i586 with Mdk Linux) and my work laptop (i686 with RH 7.1), so this can't be just a random problem.
Amazingly, the nightly build RPMs seem to work just fine.
This is definitely not the first time this happens. I don't know who compiles Mozilla for packaging, but it's obviously not done very well. Problems this obvious (Segfault at startup) don't give a very fancy image of Mozilla.
All packages should be tested at least somehow before distribution.
Why hasn't Debian project adopted the Corel Linux (nowadays Xandros Linux) installer? It's absolutely best Linux installer there is; much better than Red Hat, Mandrake, or SuSE.
Is the installer non-free software or what is the reason?
IMHO, using the Corel installer would give Debian a big jump forward. Debian's installation, especially the awkward dselect, is definitely its weakest point.
In Finnish news yesterday, an ex-minister was charged of debt fraud. He had taken loans from various sources to pay for his losses in Nigerian letter scams. He estimates that he lost about $350,000 in the scams.
Olavi J. Mattila was previously Finnish Foreign Minister, Minister of Trade and Industry, and Minister of Foreign Trade. That is, a major political figure. He was also the CEO of some large Finnish multi-billion-dollar companies (such as Valmet, a world-known machinery company) and a presidential councellor. His education was a Master of Engineering and Master of Economic Science. He retired in 1982.
So he wasn't just a dabbler in business. Perhaps he was getting senile at his current age of 84.
So no wonder people fall for the scams...
Having good MS Office filters would be enormously important for OpenOffice and StarOffice.
Word file format is the de facto standard in most companies and institutions. Most internal and external communication and documentation is done with Word and Excel, and you need to import , edit, and then export MS Office documents. Without perfect, 100% compatible filters, you simply can't use OpenOffice in such an environment. If even one word wraps differently, a table can go useless. Not that MS Office itself is totally free of these problems, but they are much worse with OO/SO.
OpenOffice export filter to MS Word breaks very easily. Sometimes even basic formatting is lost. Some images disappear. Bullets turn into strange symbols. Tables of Contents and Indexes break. Pages with complex headers or footers simply cause Word to crash.
Even really simple things such as WMF, JPEG, or GIF export filters are faulty in sdraw. GIF doesn't seem to work at all, and WMF and JPEG lose objects under certain conditions.
The filters are OO's definitely weakest point at the moment. I hope they get the problems solved, as it's otherwise such a great software.